The Bitcoin Optech newsletter provides readers with a high-level summary of the most important new techniques happening in Bitcoin, along with resources that help them learn more. To help our readers stay up to date with Bitcoin, we are 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 enable taproot and contains our regular sections with descriptions from a recent Bitcoin Core PR Review Club meeting and notable changes to popular Bitcoin infrastructure software.
- Taproot Activation Discussion: Since our last update on the discussion on taproot soft fork activation methods in Newsletter # 139, the Speedy Trial proposal has become the focus of attention. people interested in activation. PRs were opened for two variations 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 the way their start and stop points have been specified. PR # 21377 uses median time spent (MTP); PR # 21392 uses the height of the current block.
MTP is normally roughly consistent between Bitcoin’s mainnet (mainnet) and its various test networks, such as testnet, the default sign, and various independent signs. This allows multiple networks to share a single set of activation parameters even though they have very different block heights, which minimizes the work of synchronizing users of those networks with the consensus changes of the main network.
Unfortunately, MTP can be easily manipulated in small ways by a few miners and in big ways by a hash rate majority. It can also roll back to an earlier time, even by accident during a blockchain reorganization. In comparison, heights can only decrease in extraordinary rearrangements.1 This generally allows examiners to make the simplifying assumption that the height will only increase, making it easier to analyze activation mechanisms based on the height that the MTP mechanisms.
These compromises between the two proposals, among other concerns, created a deadlock that some developers said prevented either PR from receiving further scrutiny and ultimately merging one of them into Bitcoin. Core. This 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 when nodes start counting signaling blocks for the soft fork, counting starting at the start of the next retargeting period of 2,016 blocks after the start time. This is the same as how version bits BIP9 and UASF BIP148 started counting blocks for the software forks they helped activate.
- To also use MTP for when nodes stop counting block signaling for a soft fork that has not yet locked. However, unlike BIP9, the MTP stop time is only verified at the end of the retargeting periods where the count was performed. This removes the possibility for an activation attempt to go straight from start to failure, simplifying analysis and ensuring that there will be at least one full 2.016 block period during which miners can report activation.
- To use height as the minimum activation parameter. This further simplifies the analysis and also remains compatible with the goal of allowing multiple test networks to share activation parameters. Although the height may differ on these 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 meeting response.
Introduce deploymentstatus is a PR (# 19438) from Anthony Towns that offers three helper functions to make it easier to bury future deployments without changing all the code paths that check the activation status of a soft fork: DeploymentEnabled to test if a deployment can be active, DeploymentActiveAt to check if a deployment should be applied in the given block and DeploymentActiveAfter to know if a deployment should be applied in the next block. All three work with both buried deployments and version bit deployments.
The review club discussion focused on understanding the change and its potential benefits.
- What are the advantages of a BIP90 buried deployment on a BIP9 deployment of version bits?
- A buried deployment simplifies the deployment logic by replacing the test that governs the application with simple height checks, thereby reducing the technical debt associated with deploying these consensus changes.
- How many buried deployments are listed by this PR?
- Five: coinbase height, 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 soft forks of the Satoshi era are also buried.
- How many version bit deployments are currently defined?
- If the taproot soft fork is enabled and we later want to bury this method of activation, what changes should 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 that of BuriedDeployment. More importantly, no validation logic would need to be changed.
Notable changes to code and documentation
Notable changes this week in Bitcoin Core, C-Lightning, Lightning, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rusty bitcoin, BTCPay server, Bitcoin Improvement Proposals (BIP), and Lightning.
- 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 also proposed that this lays the groundwork for a future patch for getnodeaddresses which takes an argument from a specific network and only returns addresses from that network.
- Bitcoin Core # 21166 enhances the RPC signrawtransaction withwallet, allowing it to sign entries in transactions that have other signed entries that are not held by the wallet. Previously, if the RPC received a transaction that had signed non-wallet entries, witnesses to those entries would be interrupted in the returned transaction. Signing entries in transactions with other signed entries can be useful in a variety of situations, including adding I / O to increase transaction costs.
- LND # 5108 adds support for spontaneous atomic multipath payments (also known as original AMP) using the low-level sendtoroute RPC. Original MPAs are inherently non-interactive (or spontaneous) because the spender selects all pre-images. The selection of the expenditure pre-image is also part of the spontaneous payments of the keyend type, which have been used for the spontaneous one-way payments. Tracking PRs are expected to make spontaneous multipath payments available to the top-level sendpayment RPC.
- LND # 5047 allows the wallet to import BIP32 extended public keys (xpubs) and use them to receive payments to LND’s onchain wallet. In combination with LND’s recently updated support for PSBTs (see Newsletter # 118), this allows LND to function as a standby wallet for its non-channel funds. For example, Alice can import the xpub from her cold wallet, deposit funds into this wallet using an address LND gives her, ask LND to open a channel, sign a PSBT opening that channel with her wallet cold, then ask LND to automatically deposit funds. to his cold wallet when the channel is closed. This last part – depositing closed channel funds into a cold wallet – may require additional steps, especially in the case of non-cooperative closed channels, but this change allows LND to be fully interoperable with PSBT and compatible cold wallets. hardware wallets.
- If each block in the blockchain had the same individual Proof of Work (PoW), the valid chain with the most aggregated PoWs would also be the longest chain – the chain whose last block had the greatest height ever. However, every 2016 blocks, the Bitcoin protocol adjusts the amount of PoW that new blocks must contain, increasing or decreasing the work to prove in an attempt to keep the average time between blocks around 10 minutes. This means that it is 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 PoWs – not the most blocks – to determine if they have received any money. When users see a valid variation on this chain where some of the blocks at the end have been replaced with different blocks, they use this reorganized chain if it contains more PoWs than their current chain. Because the reorganization chain may contain fewer blocks, despite a more cumulative PoW, the height of the chain may decrease.
While this is a theoretical concern, it is generally not a practical problem. Height reduction is only possible when a reorganization crosses at least one of the retargeting boundaries between one set of 2,016 blocks and another set of 2,016 blocks. It also requires a reorganization 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 in hash rate or observable manipulation by miners). In the context of BIP8, we don’t think that a reorganization that would reduce the height would have more impact on users during an activation than a more typical reorganization. ↩
Find the original post here.
Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox each month.