In this episode of “The Van Wirdum Sjorsnado,” the hosts discussed CVE-2021-31876, a bug in the Bitcoin Core code affecting replace-by-fee.
Watch This Episode On YouTube
Listen To This Episode:
In this episode of “The Van Wirdum Sjorsnado,” hosts Aaron van Wirdum and Sjors Provoost discussed CVE-2021-31876, a bug in the Bitcoin Core code that affects replace-by-fee (RBF) child transactions.
The CVE (Common Vulnerabilities and Exposures) system offers an overview of publicly known software bugs. A bug in the Bitcoin Core code was recently discovered and disclosed by Antoine Riard, and added to the CVE overview.
Van Wirdum and Provoost explained that the bug affects how RBF logic is handled by the Bitcoin Core software. When one unconfirmed transaction includes an RBF flag (which means it should be considered replaceable if a conflicting transaction with a higher fee is broadcast over the network) any following transaction that spends coins from the original transaction should also be considered replaceable — even if the second transaction doesn’t itself have an RBF flag. Bitcoin Core software would not do this, however, which means the second transaction would in fact not be considered replaceable.
This is a fairly innocent bug; in most cases the second transaction will still confirm eventually, while there are also other solutions to speed confirmation up if the included fee is too low. But in very specific cases, like some fallback security mechanisms on the Lightning Network, the bug could in fact cause complications. Van Wirdum and Provoost tried to explain what such a scenario would look like — badly.
This week’s newsletter covers a security disclosure, a summary of a Bitcoin Core PR Review Club meeting 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 describes a security disclosure affecting protocols depending on a certain BIP125 opt-in replace by fee behavior and includes our regular sections with the summary of a Bitcoin Core PR Review Club meeting, announcements of new software releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.
News
CVE-2021-31876 discrepancy between BIP125 and Bitcoin Core implementation: the BIP125 specification of opt-in Replace By Fee (RBF) says that an unconfirmed parent transaction that signals replaceability makes any child transactions that spend the parent’s outputs also replaceable through inferred inheritance. This week, Antoine Riard posted to the Bitcoin-Dev mailing list the full disclosure of his previously privately reported finding that Bitcoin Core does not implement this behavior. It is still possible for child transactions to be replaced if they explicitly signal replaceability or for them to be evicted from the mempool if their parent transaction is replaced.
Riard analyzed how the inability to use inherited replaceability might affect various current and proposed protocols. Only LN appears to be affected and only in the sense that an existing attack (see Newsletter #95) that uses pinning becomes cheaper. The ongoing deployment of anchor outputs by various LN implementations will eliminate the ability to perform that pinning.
As of this writing, there has not been any substantial discussion of the issue on the mailing list.
Call for Brink grant applications: Bitcoin Optech encourages any engineer contributing to open source Bitcoin or Lightning projects to apply for a Brink grant before the application deadline on May 17th. Initial grants are one year long and allow developers to work full time on open source projects from anywhere in the world.
Bitcoin Core PR Review Club
In this monthly section, we summarize a recentBitcoin Core PR Review Clubmeeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.
Introduce node rebroadcast module is a PR (#21061) by Amiti Uttarwar that continues work on the rebroadcast project (see Newsletters #64, #96, #129 and #142), previously discussed in review clubs #16698 and #18038, whose goal is to make node rebroadcast behavior for wallet transactions indistinguishable from that of other peers’ transactions.
The review club discussion focused on current transaction behavior and the proposed changes:
Why might we want to rebroadcast a transaction? When our transaction didn’t propagate (perhaps our node was offline) or appears to have been dropped by other nodes’ mempools in the network.
Why does a node drop a transaction from its mempool? Apart from being included in a block, a transaction can expire after 14 days, be squeezed out of a node’s limited mempool size (default size 300 MiB) by higher-fee transactions, be replaced via BIP125 opt-in Replace-By-Fee (RBF), be removed if a conflicting transaction is included in a block, or be included in a block that is later reorged out (in which case the node will try to re-add it while updating the mempool to be consistent again after the reorg).
What could be an issue with the current behavior of each wallet being responsible for rebroadcasting its own transactions?
This can be a privacy leak that allows linking the IP address to the wallet address, as under the current rebroadcasting behavior, a node that broadcasts a transaction more than once is essentially announcing that the transaction is from its wallet.
When might a miner exclude a transaction that is in our mempool? When the miner deprioritized it for having a low fee, didn’t see it yet, removed it from its mempool by RBF, censored it, or mined an empty block.
When might a miner include a transaction that is not in our mempool? When the miner manually prioritized the transaction (e.g. as a commercial service), received it before our node, or the transaction conflicted with another one in our mempool but not in theirs.
How would the proposal under review decide which transactions to rebroadcast?
Once per new block, it proposes to rebroadcast transactions above an estimated feerate that are at least 30 minutes old, have been rebroadcast no more than 6 times and not more recently than 4 hours ago, with up to 3/4 of the transactions that fit the block.
Why might we want to keep a transaction in our rebroadcast attempt tracker even after it has been removed from our mempool?
After a consensus rule change, there can be non-updated nodes on the network rebroadcasting transactions that don’t meet the new consensus rules. Keeping transactions in the rebroadcast attempt tracker would avoid these nodes rebroadcasting them too many times (a maximum of 6 times over 90 days) and allow the transactions to expire.
When would we remove a transaction from our rebroadcast attempt tracker? When the transaction is confirmed, RBFed, or conflicts with another transaction included in a block.
How would the estimated minimum feerate for rebroadcast be calculated? Why not use the lowest feerate in the last mined block?
The rebroadcast feerate floor would be estimated once a minute by assembling a block from the mempool to simulate inclusion in the next mined block. This approach is better than using the lowest feerate of the last mined block because it calculates fees based on the immediate future in a changing environment instead of based on the past.
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-Lightning 0.0.14 is a new release that makes Rust Lightning more compatible with getting data from Electrum-style servers, adds additional configuration options, and improves compliance with the LN specification, among other bug fixes and improvements.
Bitcoin Core #20867 increases the number of keys that can be included in multisig descriptors and used in the addmultisigaddress and createmultisig RPCs from 16 to 20. The increased limit can only be used in P2WSH outputs. P2SH outputs are limited to 520 byte scripts which are only large enough to hold 15 compressed public keys.
Bitcoin Core GUI #125 enables users to adjust the autoprune block space size from the default in the intro dialog. It also adds an improved description for how the pruned storage works, clarifying that the entire blockchain must be downloaded and processed but will be discarded in the future to keep disk usage low.
C-Lightning #4489 adds a funder plugin for configuring dual-funding contribution behavior in response to incoming channel open requests. Users will be able to specify a general contribution policy (percent match, percent available funds, or fixed contribution), a wallet reserve amount under which no dual-funding contributions will happen, a maximum contribution amount for any single channel open request, and more.
This PR represents the last step in enabling experimental dual-funding support between C-Lightning nodes. The interactive transaction construction and channel establishment v2 protocols arising out of this work is still being standardized in the open BOLTs #851 PR.
C-Lightning #4496 adds the ability for plugins to register topics about which they plan to publish notifications. Other plugins can subscribe to those topics to receive notifications. C-Lightning already had several built-in topics, but this merged PR allows plugin authors to create and consume notifications for any new topic category they’d like to use.
Rust Bitcoin #589 starts the process of implementing support for taproot with schnorr signatures. The existing ECDSA support is moved to a new module but continues to be exported under existing names to preserve API compatibility. A new util::schnorr module adds support for BIP340 schnorr key encodings. Issue #588 is being used to track the complete implementation of taproot compatibility.
Find the original post here.
Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month.
In this episode of “The Van Wirdum Sjorsnado,” hosts Aaron van Wirdum and Sjors Provoost discussed replace by fee (RBF). RBF is a trick that lets unconfirmed transactions be replaced by conflicting transactions that include a higher fee.
With RBF, users can essentially bump a transaction fee to incentivize miners to include the transaction in a block. Van Wirdum and Provoost explained the three advantages of RBF: the option to “speed up” a transaction (one), which can in turn result in a more effective fee market for block space (two), as well as the potential to make more efficient use of block space by updating transactions to include more recipients (three).
The main disadvantage of RBF is that it makes it slightly easier to double-spend unconfirmed transactions, which was also at the root of last week’s “double spend” controversy that dominated headlines. Van Wirdum and Provoost discussed some solutions to diminish this risk, including “opt-in RBF” which is currently implemented in Bitcoin Core.
See Also
Finally, Provoost explained in detail how opt-in RBF works in Bitcoin Core, and which conditions must be met before a transaction is considered replaceable. He also noted some complications with this version of RBF, for example in the context of the Lightning Network.
Interest in Bitcoin “double-spending” grew after recent news that the Bitcoin network processed the same bitcoin (BTC) in two transactions – the very “double-spending” scenario Bitcoin was specifically designed to prevent.
Except the double-spend didn’t happen, at least not in the traditional sense.
“The bitcoin ‘double-spend’ media headline has certainly spooked investors, but it’s a misunderstanding of how the Bitcoin network operates. In this case, a chain re-organization of one block occurred, which is a fairly common occurrence,” Jason Lau, COO of OKCoin exchange, told CoinDesk.
Put another way, no bitcoin was “double-spent” because no new coins were added to Bitcoin’s supply. Instead, the same coins from the same wallet were registered in two different blocks during a typical split in Bitcoin’s blockchain.
The reason this does not qualify as a double-spend is because only one of these transactions (the one recorded on Bitcoin’s longest blockchain history) is considered valid by the network while the bitcoin in the other transaction cannot be spent because the network does not consider it valid.
What is a Bitcoin block reorganization?
Due to the distributed and highly competitive nature of Bitcoin mining, mining pools from time to time mine the same block simultaneously and thus cause a split in the blockchain’s history. When this happens, both blocks will have miners add on to them until one history wins out over the other.
Let’s say, for instance, mining pool A and mining pool B mine a block at the same time, resulting in two different blockchain histories (versions A and B). Going forward, all other miners have to choose which version of the chain to build on. Let’s say the miner who finds the next block in the sequence chooses to build on version A, but then afterwards the next two or three or more miners decide to build on version B. Version B ultimately wins out as more miners choose to mine that transaction history.
The other history is excised from the network and considered irrelevant and any blocks mined on it become stale blocks.
This was the case at block 666,833, wherein two blocks were spawned by separate mining pools and a one-block reorganization, as described by Lau, occurred. The above scenario is why Satoshi Nakamoto said in the white paper that a transaction should only be considered final after it has six confirmations (i.e., six new blocks are mined onto the chain that has recorded the transaction).
No, a double-spend didn’t really happen
The supposed double-spend first became news yesterday after BitMex Research reported on block 666,833’s abnormalities on Twitter. The reorganization meant a “stale block” (also sometimes called an “orphan block”) had been mined that contained bitcoin also spent on Bitcoin’s valid chain, so a transaction containing the same bitcoin was recorded on both the relevant and irrelevant chains.
What BitMEX research called at first a “double-spend-like scenario” now looks like a perfect storm caused by the one block reorg and a replace-by-fee transaction. A RBF transaction occurs when you tell your wallet to send the same bitcoin again but with a higher fee, with the hopes that it will be confirmed before the lower fee transaction.
Here’s what actually happened
It went down like this: Someone sent 0.00062063 BTC to this address but set the lowest fee possible (1 satoshi per byte, or less than a fraction of a cent, per byte of transaction data).
Since the fee was so low, the transaction took a while to confirm, so the sender tried to outpace it by sending what’s called a “replace by fee transaction” (RBF).
Instead of the RBF replacing the slow transaction as intended, however, the lower fee transaction cleared first and made it into the block that was mined onto the longest chain.
Meanwhile, the higher fee transaction found its way onto the stale block. The final result: 0.00062063 BTC is recorded as existing on the address 1D6aebVY5DbS1v7rNTnX2xeYcfWM3os1va on the irrelevant transaction history while 0.00014499 BTC exists on the same address but on the relevant transaction ledger.
A flow chart of the conflicting transactions, adapted by BitMex Research from an image originally produced by 0xB10C(BitMEX Research)
The importance of 6 confirmations
Technically, the same bitcoin was spent twice in this scenario. But one transaction was double-spent to an address on a transaction history that the Bitcoin network does not consider valid (if you query the transaction ID for the “losing” transaction in any Bitcoin block explorer, for instance, nothing comes up).
“It’s kinda a double-spend but not really. Normally a double-spend refers to when you intentionally replace a transaction that sends money to someone with one that sends it to your own wallet,” Ben Carman, a Bitcoin Core contributor and developer at Suredbits, told CoinDesk.
In this scenario, “the important thing to know is that, yes, there might be different versions of the same transaction, but only [one] will ultimately be accepted” by nodes and users of the Bitcoin network, Coin Metrics Bitcoin network data analyst Lucas Nuzzi wrote on Twitter.
A double-spend typically means a sender tricks a recipient into accepting a transaction that the sender actually sends to itself, as well. This is why it’s considered best practice for merchants to wait for six confirmations before a payment is considered final to avoid an outcome like this one.
As CoinMetric’s co-founder and CoinDesk columnist Nic Carter opined on Twitter, what occurred yesterday was actually pretty pedestrian for Bitcoin, not to mention something Satoshi Nakamoto describes in the white paper itself.
