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 recent progress on code to activate taproot and contains our regular sections with descriptions of a recent Bitcoin Core PR Review Club meeting and notable changes to popular Bitcoin infrastructure software.
News
- Taproot activation discussion: since our last update on discussion about activation methods for the taproot soft fork in Newsletter #139, the Speedy Trial proposal became the focus of attention among those interested in activation. PRs were opened for two variants of it: PR#21377, using a variation on BIP9, and PR#21392, using a modification that became part of BIP8. The main technical difference between these PRs is how their start and stop points were specified. PR#21377 uses Median Time Past (MTP); PR#21392 uses the height of the current block.
MTP is normally roughly consistent between Bitcoin’s main network (mainnet) and its various test networks, such as testnet, the default signet, and various independent signets. This allows multiple networks to share a single set of activation parameters even if they have vastly different block heights, minimizing the work of keeping those networks’ users in sync with mainnet’s consensus changes.
Unfortunately, MTP can be easily manipulated in small ways by a small number of miners and in large ways by a majority of hash rate. It can also revert to an earlier time even by accident during a block chain reorganization. By comparison, heights can only decrease in extraordinary reorgs.1 That generally allows reviewers to make the simplifying assumption that height will only ever increase, making it easier to analyze height-based activation mechanisms than MTP mechanisms.
These tradeoffs between the two proposals, among other concerns, created an impasse that some developers thought was preventing either PR from receiving additional review and, ultimately, getting one of them merged into Bitcoin Core. That impasse was resolved to the satisfaction of some participants in the activation discussion when the authors of the two PRs agreed to a compromise:
- To use MTP for the time when nodes begin counting blocks signaling for the soft fork, with counting starting at the beginning of the next 2,016-block retarget period after the start time. This is identical to the way BIP9 versionbits and BIP148 UASF started counting blocks for the soft forks they helped activate.
- To also use MTP for the time when nodes stop counting block signaling for a soft fork that hasn’t locked in yet. However, in a difference from BIP9, the MTP stop time is only checked at the end of retarget periods where counting was performed. This removes the ability for an activation attempt to go directly from started to failed, simplifying analysis and guaranteeing that there will be at least one complete 2,016 block period where miners can signal for activation.
- To use height for the minimum activation parameter. This further simplifies analysis and also remains compatible with the goal of allowing multiple test networks to share activation parameters. Even though height may differ on those networks, they can all use a minimum activation height of 0 to activate within the window defined by MTP.
Bitcoin Core PR Review Club
In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.
Introduce deploymentstatus is a PR (#19438) by Anthony Towns that proposes three helper functions to make it easier to bury future deployments without changing all the code paths that check a soft fork’s activation status: DeploymentEnabled to test if a deployment can be active, DeploymentActiveAt to check if a deployment should be enforced in the given block, and DeploymentActiveAfter to know if a deployment should be enforced in the following block. All three work with both buried deployments and version bits deployments.
The review club discussion focused on understanding the change and its potential benefits.
- What are the advantages of a BIP90 buried deployment over a BIP9 version bits deployment?
- A buried deployment simplifies the deployment logic by replacing the test that governs enforcement with simple height checks, thereby reducing the technical debt associated with deployment of those consensus changes.
- How many buried deployments are enumerated by this PR?
- Five: height in coinbase, CLTV (CHECKLOCKTIMEVERIFY), strict DER signatures, CSV (OP_CHECKSEQUENCEVERIFY), and segwit. They are listed in the BuriedDeployment enumerator proposed by the PR in src/consensus/params.h#L14-22. One could argue that the Satoshi-era soft forks are also buried.
- How many version bits deployments are currently defined?
- If the taproot soft fork is activated and we later want to bury that activation method, what changes would need to be made to Bitcoin Core, if this PR is merged?
- The main change would be greatly simplified compared to the current code: move the DEPLOYMENT_TAPROOT line from the DeploymentPos enumerator to the BuriedDeployment one. Most importantly, no validation logic would need to be changed.
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 #21594 adds a network field to the getnodeaddresses RPC to help identify nodes on various networks (i.e. IPv4, IPv6, I2P, onion). The author has also proposed that this lays the groundwork for a future patch for getnodeaddresses that takes an argument of a specific network and returns only addresses in that network.
- Bitcoin Core #21166 improves the signrawtransactionwithwallet RPC, allowing it to sign inputs in transactions which have other signed inputs that are not owned by the wallet. Previously, if the RPC was passed a transaction that had signed inputs not owned by the wallet, the witnesses to those inputs would be broken in the returned transaction. Signing inputs in transactions with other signed inputs can be useful in a variety of situations, including adding inputs/outputs to bump the transaction fee.
- LND #5108 adds support for making spontaneous Atomic Multipath Payments (also called Original AMPs) using the low-level sendtoroute RPC. Original AMPs are non-interactive (or spontaneous) by nature as the spender selects all preimages. Spender preimage selection is also a part of keysend-style spontaneous payments, which have been used for singlepath spontaneous payments. Follow-up PRs are expected to make spontaneous multipath payments available to the higher-level sendpayment RPC.
- LND #5047 allows the wallet to import BIP32 extended public keys (xpubs) and use them for receiving payments to LND’s onchain wallet. In combination with LND’s recently updated support for PSBTs (see Newsletter #118), this allows LND to operate as a watch-only wallet for its non-channel funds. For example, Alice can import the xpub from her cold wallet, deposit funds into that wallet using an address LND gives her, request LND open a channel, sign a PSBT opening that channel with her cold wallet, and then have LND automatically deposit funds back to her cold wallet when the channel is closed. That last part—depositing closed channel funds back to a cold wallet—may require extra steps, particularly in the case of non-cooperatively closed channels, but this change brings LND most of the way towards being fully interoperable with PSBT-compatible cold wallets and hardware wallets.
Footnotes
- If every block on the block chain had the same individual Proof of Work (PoW), the valid chain with the most aggregate PoW would also be the longest chain—the chain whose latest block had the greatest height yet seen. However, every 2,016 blocks, the Bitcoin protocol adjusts the amount of PoW that new blocks need to contain, increasing or decreasing the work needing to be proved in an attempt to keep the average time between blocks around 10 minutes. That means it’s possible for a chain with fewer blocks to have more PoW than a chain with more blocks.
Bitcoin users use the chain with the most PoW—not the most blocks—to determine whether they’ve received money. When users see a valid variation on that chain where some of the blocks on the end have been replaced by different blocks, they use that reorganized chain if it contains more PoW than their current chain. Because the reorg chain may contain fewer blocks, despite having more cumulative PoW, it’s possible for the height of the chain to decrease.
Although this is a theoretical concern, it’s usually not a practical problem. Decreasing height is only possible when a reorg crosses at least one of the retarget boundaries between one set of 2,016 blocks and another set of 2,016 blocks. It also requires a reorg involving a large number of blocks or a recent major change in the amount of PoW required (indicating either a recent major increase or decrease of hash rate, or an observable manipulation by miners). In the context of BIP8, we don’t believe a reorg that decreased height would have any more impact on users during an activation than a more typical reorg. ↩
Find the original post here.
Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month.
