The Bitcoin Optech newsletter provides readers with a summary of the most important technical news about Bitcoin, as well as resources to help them learn more. To help our readers stay up to date on Bitcoin, we are posting the latest edition of this newsletter below. Remember to subscribe to get this content straight to your inbox.
This week’s newsletter celebrates the locking of the Taproot soft fork, describes a draft BIP to improve transaction privacy by varying the fields used to implement anti-fee sniping, and includes an article on the challenges of combining of transaction substitution with payment stacking. Also included are our regular sections with announcements of new software releases and release candidates, as well as notable changes to the popular Bitcoin infrastructure software.
- Taproot Locked-in: The Taproot soft fork and the associated changes that are specified in BIPs 340, 341 and 342 were locked by signaling miners last weekend. Taproot is safe to use after block 709.632 expected in early or mid-November. The delay gives users time to upgrade their nodes to a version (like Bitcoin Core 0.21.1 or higher) that enforces Taproot’s rules to ensure that funds received after block 709.632 to Taproot scripts are safe, too when there is a problem with miners.
Developers are encouraged to start implementing taproot so that once activation is complete, they are ready to benefit from greater efficiency, data protection and fungibility.
Readers celebrating taproot’s lock-in may also want to read a short thread about the origins and history of taproot by developer Pieter Wuille.
- For wallets, BIP suggested setting nSequence by default on taproot transactions: Chris Belcher has posted a draft BIP to the Bitcoin Dev mailing list suggesting an alternative way for wallets to implement anti-fee sniping. The alternative method would improve the privacy and fungibility of transactions made by single-sig users, multi-signature users, and users of certain contract protocols such as Taproot-enabled LN or Advanced CoinSwaps.
Anti-fee sniping is a technique some wallets implement to deter miners from stealing fees from one another, which would reduce the burden of proof of work for securing Bitcoin and limit users’ ability to rely on confirmation results. All wallets that implement anti-fee sniping today use nLockTime altitude locks, but it is also possible to implement the same protection with BIP68 nSequence altitude locks. This wouldn’t be more effective at preventing fee sniping, but it would be a good reason for regular wallets to set their nSequence values to the same values required for transactions in certain multi-signature-based contract protocols, z and taproot-enabled LN. This helps make regular wallet transactions look like contract log transactions and vice versa.
Belcher’s proposal suggests that wallets choose randomly between using nLockTime or nSequence with a 50% probability when both options are available. Overall, the proposal, if implemented, will allow users of regular single sig transactions or straightforward multiple signatures to partner with users of contract logs to improve each other’s privacy and fungibility.
Experience report: Using RBF and Additive Batching
Additive batching is a scheme in which additional expenditure is added to unconfirmed transactions in the mempool. This field report outlines the efforts CardsCoins has taken over the introduction of a reorg- and DoS-safe implementation of such a scheme in its customer payment workflow.
Replace with Fee (RBF, BIP125) and batching are two important tools for any company that interacts directly with Bitcoin’s mempool. Fees go up, fees go down, but the company must always struggle to be efficient.
Each tool, while powerful, has its own complexities and nuances. For example, pooling customer withdrawals can save fees for the company, but is likely to make Parental Child Payments (CPFP) inefficient for a customer looking to expedite the transaction. Similarly, RBF is useful to a company that has a fee undercutting strategy (their initial transaction transfer starts with a low fee and is bid up slowly), but it exposes its customers to potential confusion when their withdrawal transaction is updated in their wallet . It would also be messy for the customer to spend on this transaction while it remains unconfirmed, as the company will have to pay for those expenses from the child when trying to replace the parent. Worse, the company may have pinned a payout through another service that received the customer’s payout.
By combining these two tools, a service provider opens up new functionalities, but is similarly exposed to novel forms of complexity. In the base case, the combination of RBF and a single, static batch carries a simple combination of the complexities that RBF and batching carry separately. However, if you combine RBF and “Additive Batching”, emerging borderline cases and dangerous failure scenarios arise.
With additive RBF batching, the service provider introduces new expenses (and confirmed entries) into a transaction in the mempool in order to include new customer withdrawals in an unconfirmed transaction. This enables the service provider to provide users with the instant withdrawal experience while retaining much of the fee savings from large amounts of customer withdrawals at once. When each customer requests a withdrawal, an expense is added to the transaction in the mempool. This transaction will continue to be updated until it is confirmed or reached another local optimum.
There are many strategies for this type of RBF additive dosing. At CardCoins we took a security approach to our implementation (with the help of Matthew Zipkin), the details of which we described in a blog post, RBF Batching at CardCoins: Diving into the Mempool’s Dark Reorg Forest.
Releases and release candidates
New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or help test release candidates.
- Rust Bitcoin 0.26.2 is the latest minor version of the project. Compared to the previous major version, it contains several API improvements and bug fixes. See the changelog for details.
- Rust-Lightning 0.0.98 is a smaller version with several improvements and bug fixes.
- LND 0.13.0-beta.rc5 is a release candidate that supports the use of a pruned Bitcoin full node, enables receiving and sending of payments with Atomic MultiPath (AMP), and enhances its PSBT capabilities among other improvements and bug fixes.
Notable code and documentation changes
Notable changes this week in Bitcoin core, C-flash, eclair, LND, Rust lightning, libsecp256k1, Hardware wallet interface (HWI), Rust bitcoin, BTCPay server, Suggestions for improving Bitcoin (BIPs), and Lightning bolt.
- Bitcoin Core GUI # 4 adds initial support for using external hardware wallet interface (HWI) signers through the GUI. Once this feature is complete, users can use their HWI-compatible hardware wallets directly from the Bitcoin Core GUI.
- Bitcoin Core # 21573 updates the version of libsecp256k1 that is included in Bitcoin Core. The most notable change is the use of the optimized modular inverse code described in newsletters # 136 and # 146. Performance ratings sent to the PR indicated that checking old blocks was sped up by about 10%.
- C-Lightning # 4591 adds support for parsing bech32m addresses. C-Lightning now allows a peer who has negotiated the option_shutdown_anysegwit feature to specify any v1 + native Segwit address as a closing or retreat target.
You can find the original article here.
Please subscribe to the Bitcoin Optech newsletter directly to receive this content directly in your inbox every month.