This week’s newsletter summarizes a wide-ranging discussion about free relay and fee-bumping upgrades in Bitcoin Core. Also included are our regular sections sharing popular questions and answers from the Bitcoin Stack Exchange, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure projects.

News

• ● Varied discussion of free relay and fee bumping upgrades: Peter Todd posted to the Bitcoin-Dev mailing list a summary of a free relay attack that he previously responsibly disclosed to Bitcoin Core developers. This led to an entangled discussion of multiple issues and proposed improvements. Some of the topics discussed included:

  • ● Free relay attacks: free relay occurs when a full node relays unconfirmed transactions without the amount of fee revenue in its mempool increasing by at least the minimum relay rate (by default, 1 sat/vbyte). Free relay often costs some money, so it’s not technically free, but the cost is far below what honest users pay for relay.

    Free relay allows an attacker to greatly increase the bandwidth used by relaying full nodes, which may reduce the number of relay nodes. If the number of independently operated relay nodes drops too low, spenders are essentially sending transactions directly to miners, which has the same centralization risks as out-of-band fees.

    Todd’s described attack exploits differences in mempool policy between miners and users. Many miners appear to enable full-RBF but Bitcoin Core does not enable it by default (see Newsletter #263). This allows an attacker to craft different versions of a transaction which will be treated differently by full-RBF miners and non-full-RBF relay nodes. Relay nodes can end up relaying multiple versions of a transaction that have minimal chance of confirming, wasting the bandwidth of the relaying nodes.

    Free relay attacks do not directly allow attackers to steal other users’ funds, although a sudden or prolonged attack may be used to disrupt the network and make other types of attacks easier. To the best of our knowledge, no disruptive free relay attack has ever been performed.

  • ● Free relay and replace-by-feerate: Peter Todd has previously proposed two forms of replace-by-feerate (RBFR); see Newsletter #288. One criticism of RBFR was that it enabled free relay. A similar amount of free relay is already possible through the attack he described this week and similar attacks, so he argued that concerns about free relay should not block adding a feature useful for mitigating transaction pinning attacks.

    One reply argued that free relay created by RBFR was fundamental to its design, but other free relay problems in the design of Bitcoin Core might be solvable. Todd disagreed.

  • ● TRUC utility: Peter Todd argued that TRUC was a “bad proposal”. He previously criticized the protocol (see Newsletter #283) and specifically criticized the specification of TRUC, BIP431, which uses concerns about free relay to advocate for TRUC over his own RBFR proposal.

    However, BIP431 also argues against versions of RBFR, such as Todd’s one-shot RBFR, that depend on the replacement paying a high enough feerate that it becomes one of the most profitable transactions to mine in the next few blocks, described as entering the top part of the mempool. Both Todd and others agreed that would be much easier to do once Bitcoin Core begins using cluster mempool, although Todd also suggested alternative methods that are available now. TRUC does not need information about the top part of the mempool, so it does not depend on cluster mempool or alternatives.

    A longer form of this criticism was summarized in Newsletter #288, with subsequent research (summarized in Newsletter #290) illustrating how difficult it is for any set of transaction replacement rules to always make a choice that will improve miner profitability. Compared to RBFR, TRUC does not change Bitcoin Core’s replacement rules (except to always allow replacements to be considered for TRUC transactions), so it should not make any existing problems with replacement incentive compatibility worse.

  • ● Path to cluster mempool: as described in Newsletter #285, the cluster mempool proposal requires disabling CPFP carve-out (CPFP-CO), which is currently used by LN anchor outputs to protect a large amount of money in payment channels. In combination with package relay (specifically package replace by fee), one-shot RBFR may be able to replace CPFP-CO without requiring changes to any LN software that already repeatedly RBF fee bumps its anchor output spends. However, one-shot RBFR depends on learning top-mempool feerates from something like cluster mempool, so both RBFR and cluster mempool would need to be deployed simultaneously or an alternative method for determining top-mempool feerates would need to be used.

    By comparison, TRUC also provides an alternative to CPFP-CO, but it is an opt-in feature. All LN software would need to upgrade to support TRUC and all existing channels would need to undergo a channel commitment upgrade. That could take a significant amount of time and CPFP-CO couldn’t be disabled until there was strong evidence that all LN users had upgraded. Until CPFP-CO was disabled, cluster mempool could not safely be widely deployed.

    As mentioned in previous Optech newsletters #286, #287, and #289, a slow adoption of TRUC and fast availability of cluster mempool could be addressed through imbued TRUC, which would automatically apply TRUC and sibling eviction to anchors-style LN commitment transactions. Several LN developers and contributors to the imbued TRUC proposal said that they would prefer to avoid that outcome—explicitly upgrading to TRUC is better in many ways, and there are multiple other reasons for LN developers to work on channel upgrade mechanisms—but it seems plausible that imbued TRUC may be considered again if cluster mempool development outpaces the development of LN commitment upgrades.

    Although both imbued TRUC and widespread adoption of opt-in TRUC allow disabling CPFP-CO and thus make it possible to deploy cluster mempool, neither TRUC system depends on cluster mempool or other new methods of calculating transaction incentive compatibility. This makes it easier to analyze TRUC independently of cluster mempool than it is to analyze RBFR.

  As of this writing, discussion on the mailing list is ongoing.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.

• ● Why is restructure of mempool required with cluster mempool? Murch explains issues with Bitcoin Core’s current mempool data structure, how cluster mempool addresses those issues, and how cluster mempool may be deployed in Bitcoin Core.

• ● DEFAULT_MAX_PEER_CONNECTIONS for Bitcoin Core is 125 or 130? Lightlike clarifies that while the maximum number of automatic peer connections is 125 in Bitcoin Core, a node operator might add up to 8 additional connections manually.

• ● Why do protocol developers work on maximizing miner revenue? David A. Harding lists several advantages of being able to predict which transactions get into a block using the assumption that miners will maximize fee revenue, noting “This allows spenders to make reasonable feerate estimates, volunteer relay nodes to operate with a modest amount of bandwidth and memory, and small decentralized miners to earn just as much fee revenue as large miners”.

• ● Is there an economic incentive to use P2WSH over P2TR? Vojtěch Strnad points out that while certain uses of P2WSH can be cheaper than P2TR outputs, most use cases of P2WSH, like multisig and LN, would benefit from the reduced fees enabled by hiding unused script paths in taproot and using schnorr signatures for key aggregation schemes like MuSig2 and FROST.

• ● How many blocks per second can sustainably be created using a time warp attack? Murch calculates that in the context of a time warp attack, “An attacker would be able to sustain a cadence of 6 blocks per second without increasing the difficulty.”

• ● pkh() nested in tr() is allowed? Pieter Wuille points out that, according to BIP386, “tr() Output Script Descriptors”, pkh() nested in tr() is not a valid descriptor, but that under BIP379 “Miniscript” such a construction is allowed and that it is up to the application developer to decide which specific BIPs they adhere to.

• ● Can a block more than a week old be considered a valid chain tip? Murch concludes that such a chain tip could be considered valid, but that the node would remain in the “initialblockdownload” state as long as the chain tip is more than 24 hours in the past according to the node’s local time.

• ● SIGHASH_ANYONECANPAY mediated tx modification Murch explains the challenges of using SIGHASH_ALL | SIGHASH_ANYONECANPAY in an onchain crowdfunding scheme and how SIGHASH_ANYPREVOUT might help.

• ● Why does RBF rule #3 exist? Antoine Poinsot confirms that RBF rule #4 (replacement transaction pays additional fees above original transaction’s absolute fees) is stronger than rule #3 (replacement pays absolute fees of at least the sum paid by the original transaction) and notes that the reason for the two similar rules in the documentation comes from the two separate checks in the code.

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.

• ● BDK 1.0.0-beta.1 is a release candidate for “the beta first version of bdk_wallet with a stable 1.0.0 API”.

Notable code and documentation changes

Notable recent changes in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition, and BINANAs.

• ● Bitcoin Core #30320 updates assumeUTXO behavior to avoid loading a snapshot if it’s not an ancestor of the current best header m_best_header and instead sync as a regular node. If the snapshot later becomes an ancestor of the best header due to a chain reorganization, assumeUTXO snapshot loading resumes.

• ● Bitcoin Core #29523 adds a max_tx_weight option to transaction funding RPC commands fundrawtransaction, walletcreatefundedpsbt, and send. This ensures the resulting transaction weight doesn’t exceed the specified limit, which can be beneficial for future RBF attempts or for specific transaction protocols. If not set, the MAX_STANDARD_TX_WEIGHT of 400,000 weight units (100,000 vbytes) is used as the default value.

• ● Core Lightning #7461 adds support for nodes to self-fetch and self-pay BOLT12 offers and invoices, which may simplify account management code that calls CLN in the background as described in Newsletter #262. The PR also allows nodes to pay an invoice even if the node itself is the head of the blinded path. In addition, unannounced nodes (those without unannounced channels) can now create offers by automatically adding a blinded path whose penultimate hop is one of their channel peers.

• ● Eclair #2881 removes support for new incoming static_remote_key channels, while maintaining support for existing ones and for new outgoing channels that use this option. Nodes should use anchor outputs instead, as incoming static_remote_key new channels are now considered obsolete.