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.
- 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 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 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…