Bitcoin Optech #153: Locking In Taproot

This week’s newsletter celebrates the lock-in of Taproot, describes a draft BIP for improving transaction privacy and more.

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 celebrates the lock-in of the taproot soft fork, describes a draft BIP for improving transaction privacy by varying the fields used to implement anti fee sniping, and features an article about the challenges of combining transaction replacement with payment batching. Also included are our regular sections with announcements of new software releases and release candidates, plus notable changes to popular Bitcoin infrastructure software.

News

• Taproot locked in: the taproot soft fork and related changes specified in BIPs 340, 341, and 342 were locked in by signaling miners last weekend. Taproot will be safe to use after block 709,632, which is expected in early or mid November. The delay gives time for users to upgrade their nodes to a release (such as Bitcoin Core 0.21.1 or later) that will enforce taproot’s rules, ensuring that funds received to taproot scripts after block 709,632 are safe even if there’s a problem with miners.
  Developers are encouraged to start implementing taproot so they can be ready to take advantage of greater efficiency, privacy, and fungibility as soon as the activation is complete.
  Readers celebrating the lock-in of taproot may also wish to read a short thread about taproot’s origins and history by developer Pieter Wuille.
• BIP proposed for wallets to set nSequence by default on taproot transactions: Chris Belcher posted a draft BIP to the Bitcoin-Dev mailing list suggesting an alternative way wallets can implement anti fee sniping. The alternative method would enhance the privacy and fungibility of transactions made by single-sig users, multisignature 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 discourage miners from trying to steal fees from each other in a way that would reduce the amount of proof of work expended on securing Bitcoin and limit users’ ability to rely on confirmation scores. All wallets that implement anti fee sniping today use nLockTime height locks, but it’s also possible to implement the same protection using BIP68 nSequence height locks. This wouldn’t be any more effective at preventing fee sniping, but it would provide a good reason for regular wallets to set their nSequence values to the same values that are required for transactions in certain multisignature-based contract protocols, such as ideas for coinswaps and taproot-enabled LN. This helps make regular wallet transactions look like contract protocol transactions and vice versa.
  Belcher’s proposal suggests wallets randomly choose between using either nLockTime or nSequence with 50% probability when both options are available. Overall, if the proposal is implemented, it will allow users of regular single-sig transactions or uncomplicated multisignatures to join together with users of contract protocols to mutually improve each others’ privacy and fungibility.

Field Report: Using RBF and Additive Batching

by CardCoins

“Additive batching” is a scheme in which additional outputs are added to unconfirmed transactions in the mempool. This field report outlines efforts CardCoins has taken in introducing a reorg- and DoS-safe implementation of such a scheme in its customer payout workflow.

Replace By Fee (RBF, BIP125) and batching are two important tools for any enterprises directly interacting with Bitcoin’s mempool. Fees go up, fees go down, but the business must always fight for fee efficiency.

Each tool, while powerful, has its own complexities and nuances. For example, batching customer withdrawals may save on fees for the enterprise, but will likely make child pays for parent (CPFP) uneconomical for a customer who wishes to speed up the transaction. Similarly, RBF is useful for an enterprise who takes a fee-underbidding strategy (their initial transaction broadcast starts at a low fee, and is slowly bid upwards), but it exposes their customers to potential confusion as their withdrawal transaction updates in their wallet. It would also be messy for the customer to spend from this transaction while it remains unconfirmed, as the enterprise will have to pay for this child spend when attempting to replace the parent. Even worse, the enterprise may have a withdrawal pinned by another service which received the customer’s withdrawal.

When combining these two tools, a service provider unlocks new functionality but is similarly exposed to novel forms of complexity. In the base case, combining RBF and a single, static batch carries a simple combination of the complexities that RBF and batching carry discretely. However, when you combine RBF and “additive batching,” emergent edge cases and dangerous failure scenarios present themselves.

In additive RBF batching, the service provider introduces new outputs (and confirmed inputs) to a transaction in the mempool to incorporate new customer withdrawals into an unconfirmed transaction. This enables the service provider to give users the experience of an instantaneous withdrawal while still retaining much of the fee savings from doing large batches of customer withdrawals at once. As each customer requests a withdrawal, an output is added to the transaction in the mempool. This transaction continues to be updated until it confirms or reaches some other local optimum.

There are many strategies to this type of additive RBF batching. At CardCoins we took a safety-first 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 helping to test release candidates.

• Rust Bitcoin 0.26.2 is the project’s latest minor release. 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 minor release containing several improvements and bug fixes.
• LND 0.13.0-beta.rc5 is a release candidate that adds support for using a pruned Bitcoin full node, allows receiving and sending payments using Atomic MultiPath (AMP), and increases its PSBT capabilities, among other improvements and bug fixes.

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 GUI #4 adds initial support for using Hardware Wallet Interface (HWI) external signers via the GUI. Once this feature is finalized, users will be able to use their HWI-compatible hardware wallets directly from the Bitcoin Core GUI.
• Bitcoin Core #21573 updates the version of libsecp256k1 included in Bitcoin Core. The most notable change is the use of the optimized modular inverse code described in Newsletters #136 and #146. Performance evaluations posted to the PR found it accelerated old block verification by about 10%.
• C-Lightning #4591 adds support for parsing bech32m addresses. C-Lightning will now permit a peer that has negotiated the feature option_shutdown_anysegwit to specify any v1+ native segwit address as a closing or withdrawal destination.

Find the original post here.

Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month.