This week’s newsletter requests feedback on not allowing P2SH-wrapped addresses for taproot, describes proposed changes to script resource limits in tapscript, and mentions a discussion about watchtower storage costs. Also included are a selection of popular questions and answers from the Bitcoin StackExchange and a short list of notable changes to popular Bitcoin infrastructure projects.

Action items

  • Comment if you expect to need P2SH-wrapped taproot addresses: recent discussion on the Bitcoin-Dev mailing list indicates that the bip-taproot proposal may be amended to disallow creating taproot inputs by paying P2SH outputs (the way you can currently use P2WPKH and P2WSH inputs created from P2SH outputs). Anyone who expects to need P2SH-wrapped taproot should describe their planned use case on the mailing list or by contacting the bip-taproot author privately.


  • Tapscript resource limits: the bip-tapscript proposal limits transactions to one signature-checking operation (sigop) for every 12.5 vbytes the witness data adds to the size of the transaction (plus one free sigop per input). Because signatures are expected to be 16.0 vbytes, this limit prevents abuse without affecting normal users. Compared to earlier abuse-prevention solutions, it means any valid taproot transaction can be included in a block regardless of how many sigops it contains—keeping miner transaction code simple and fast.

    In a mailing list post, bip-tapscript author Pieter Wuille notes that he and Andrew Poelstra examined other resource limits on scripts that were put in place to prevent nodes from using an excessive amount of CPU or memory during verification. He describes some of their findings and advocates the following rule changes:

    • Replace the separate sigops counter with a “executed sigops must not exceed (witness size / [12.5 vbytes]) + 1” rule (already in the BIP).
    • Drop the 10,000 byte limit for script size (and 3,600 byte standardness limit)
    • Drop the 201 non-push ops limit per script.
    • Drop the 100 input stack elements standardness limit and replace with a (consensus) 1,000 limit.

    The removal of unneeded rules would simplify the construction of advanced Bitcoin scripts and the tools necessary to work with them.

  • Watchtower storage costs: a discussion on the Lightning-Dev mailing list examined the storage requirements for current watchtowers as well as watchtowers for proposed eltoo-based payment channels. In the thread, Christian Decker notes that both current watchtowers (as implemented by LND) and future watchtowers for eltoo can have essentially O(1) costs (fixed costs) per user by having each person use a session key to update their latest state information on the watchtower.

Selected Q&A from Bitcoin StackExchange

Bitcoin StackExchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments of time to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, LND, C-Lightning, Eclair, libsecp256k1, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • Bitcoin Core #16400 refactors part of the mempool transaction acceptance code. We don’t usually cover refactors, but this one has a tantalizing comment: “this is in preparation for re-using these validation components for a new version of AcceptToMemoryPool() that can operate on multiple transactions (‘package relay’).” Package relay could allow nodes to accept a transaction below the node’s minimum feerate if the transaction came bundled with a child transaction whose fee was high enough to pay the minimum feerate for both it and its parent. If widely deployed, package relay would allow users who create transactions a long time before broadcasting them (e.g. timelocked transactions or LN commitment transactions) to safely pay the minimum possible fee. When it came time to broadcast the transaction, they could use Child-Pays-For-Parent (CPFP) fee bumping to set an appropriate fee for the current network conditions.

  • BOLTs #557 updates BOLT7 to allow for “extended queries” which allow nodes to request that they only receive gossip updates that are newer than a specified date or which differ from a specified hash.