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.
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
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
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
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.
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