The Bitcoin Optech newsletter provides readers with a top-level summary of the most important technical news happening in Bitcoin, along with resources that help them learn more. To help our readers stay up-to-date with Bitcoin, we’re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.
This week’s newsletter summarizes two proposed BIPs related to wallet support for taproot and includes our regular sections describing selected questions and answers on the Bitcoin Stack Exchange, how to prepare for taproot, and notable changes to popular Bitcoin infrastructure projects.
News
- PSBT extensions for taproot: Andrew Chow posted a proposed BIP to the Bitcoin-Dev mailing list that defines new fields for PSBTs to use when either spending or creating taproot outputs. The fields extend both the original version 0 PSBTs and the proposed version 2 PSBTs (see Newsletter #128). Both keypath and scriptpath spends are supported.
The proposed BIP also recommends that P2TR inputs in a PSBT can omit copies of previous transactions because taproot fixes the fee overpayment attack against v0 segwit inputs (see Newsletter #101). - Key derivation path for single-sig P2TR: Andrew Chow also posted a second proposed BIP to the Bitcoin-Dev mailing list suggesting a BIP32 derivation path to use for wallets creating single-sig taproot addresses. Chow notes that the BIP is very similar to BIP49 for P2SH-wrapped P2WPKH addresses and BIP84 for native P2WPKH addresses.
Selected Q&A from Bitcoin Stack Exchange
Bitcoin Stack Exchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments 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.
Preparing for taproot #2: is taproot even worth it for single-sig?
A weekly series about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.
Using Optech’s transaction size calculator, we can compare the sizes of different types of single-sig transactions. As expected, transactions using P2WPKH inputs and outputs are much smaller than those using P2PKH inputs and outputs—but, perhaps surprisingly, P2TR transactions are slightly larger than equivalent P2WPKH transactions.
| P2PKH (legacy) | P2WPKH (segwit v0) | P2TR (taproot/segwit v1) | |
|---|---|---|---|
|
Output |
34 |
31 |
43 |
|
Input |
148 |
68 |
57.5 |
|
2-in, 2-out tx |
374 |
208.5 |
211.5 |
That may make it seem counterproductive for single-sig wallets to implement taproot spending in preparation for block 709,632, but a closer look reveals that there are a number of advantages to using P2TR for single-sigs, both for wallet users and for the network as a whole.
- Cheaper to spend: it costs about 15% less at the input level to spend a single-sig P2TR UTXO than it does to spend a P2WPKH UTXO. An overly simple analysis like the table above hides the detail that the spender can’t choose which addresses they’re asked to pay, so if you stay on P2WPKH and everyone else upgrades to P2TR, the actual typical size of your 2-in-2-out transactions will be 232.5 vbytes—while all-P2TR transactions will still only be 211.5 vbytes.
- Privacy: although some privacy is lost when early adopters change to a new script format, users switching to taproot also immediately receive a privacy boost. Your transactions will be able to look indistinguishable from people working on new LN channels, more efficient DLCs, secure multisignatures, various clever wallet backup recovery schemes, or a hundred other pioneering developments.
Using P2TR for single-sig now also allows your wallet to upgrade to multisignatures, tapscripts, LN support, or other features later on without affecting the privacy of your existing users. It won’t matter whether a UTXO was received to an old version or a new version of your software—both UTXOs will look the same onchain. - More convenient for hardware signing devices: since the rediscovery of the fee overpayment attack, several hardware signing devices have refused to sign a transaction unless each UTXO spent in that transaction is accompanied by metadata containing a copy of significant parts of the entire transaction which created that UTXO. This greatly increases the worst-case processing that hardware signers need to perform and is especially problematic for hardware signers using limited-size QR codes as their primary communication medium. Taproot eliminates the vulnerability underlying the fee overpayment attack and so can significantly improve the performance of hardware signers.
- More predictable feerates: ECDSA signatures for P2PKH and P2WPKH UTXOs can vary in size (see Newsletter #3). Since wallets need to choose a transaction’s feerate before creating the signature, most wallets just assume the worst case signature size and accept that they’ll slightly overpay the feerate when a smaller signature is generated. For P2TR, the exact size of the signature is known in advance, allowing the wallet to reliably choose a precise feerate.
- Help full nodes: the overall security of the Bitcoin system depends on a significant percentage of Bitcoin users verifying every confirmed transaction with their own nodes. That includes verifying the transactions your wallet creates. Taproot’s schnorr signatures can be efficiently batch verified, reducing by about 1/2 the number of CPU cycles nodes need to expend when verifying signatures during the process of catching up on previous blocks. Even if you rejected every other point on this list, consider preparing to use taproot for the benefit of people running full nodes.
Notable code and documentation changes
Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.
- Bitcoin Core #22154 adds code that will allow the user to generate bech32m addresses for P2TR scripts after taproot activates in block 709,632, e.g. by calling getnewaddress “” bech32m. If a transaction includes any bech32m addresses after taproot activation, the descriptor wallet will also use a P2TR change output. The feature only applies to wallets with taproot descriptors (see Newsletter #152).
- Bitcoin Core #22166 adds support for inferring taproot tr() descriptors from outputs, completing basic taproot descriptor support. Descriptor inference is used to provide more accurate information in responses to RPC calls such as listunspent.
- Bitcoin Core #20966 changes the name and format of the saved banlist file from banlist.dat (based on serialized P2P protocol addr messages) to banlist.json. The file format update allows the new list to store ban entries for peers on Tor v3 and peers on other networks with addresses more than 128 bits wide—the maximum width that original addr messages can contain.
- Bitcoin Core #21056 adds a new -rpcwaittimeout parameter to bitcoin-cli. The existing -rpcwait parameter will delay sending a command (RPC call) until the bitcoind server has started. The new parameter stops the waiting after the indicated number of seconds, returning an error.
- C-Lightning #4606 allows creating invoices over about 0.043 BTC, following a similar change in LND (see Newsletter #93) and the change to the specification described in the next item.
- BOLTs #877 removes the protocol-level per-payment amount limit originally introduced to avoid significant losses arising out of implementation bugs. This follows the widespread implementation of option_support_large_channel in 2020, which (when enabled) removed the per-channel amount limit. See the topic on large channels for more details on these two limits.
Find the original post here.
Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month.