This week’s newsletter summarizes a proposal for allowing Stratum v2 pool miners to receive compensation for the transaction fees contained in the block templates they turn into shares, announces a research fund investigating the proposed OP_CAT opcode, and describes a discussion about mitigating merkle tree vulnerabilities with or without a soft fork. Also included are our regular sections announcing new releases and release candidates as well as describing notable changes to popular Bitcoin infrastructure software.

News

  • ● Stratum v2 extension for fee revenue sharing: Filippo Merli posted to Delving Bitcoin about an extension to Stratum v2 that will allow tracking the amount of fees included in shares when the shares contain transactions selected by an individual miner. This can be used to adjust the amount paid to the miner by the pool, with miners selecting higher feerate transactions being paid more.

    Merli links to a paper he co-authored that examines some of the challenges of paying different miners different amounts based on the transactions they select. The paper suggests a scheme that is compatible with a pay per last N shares (PPLNS) pooled mining payout scheme. His post links to two in-progress implementations of the scheme.

  • ● OP_CAT research fund: Victor Kolobov posted to the Bitcoin-Dev mailing list to announce a $1 million fund for research into a proposed soft fork to add an OP_CAT opcode. “Topics of interest include but are not limited to: the security implications of OP_CAT activation on Bitcoin, OP_CAT-based computing and locking script logic on Bitcoin, applications and protocols utilizing OP_CAT on Bitcoin, and general research related to OP_CAT and its impact.” Submissions must be received by 1 January 2025.

  • ● Mitigating merkle tree vulnerabilities: Eric Voskuil posted to the Delving Bitcoin discussion thread about the consensus cleanup soft fork proposal (see Newsletter #296) a request for an update given recent discussion on the Bitcoin-Dev mailing list. In particular, he saw “no justification for the proposed invalidation of 64 byte transactions” based on his argument that there’s no performance improvement to full nodes in protecting against merkle tree vulnerabilities like CVE-2012-2459 by forbidding 64-byte transactions in comparison to other checks that can be performed without a consensus change (and, indeed, those checks are being performed now). The consensus cleanup proposal champion, Antoine Poinsot, appeared to agree about this full node aspect: “The advantage I initially mentioned about how making 64-bytes transactions invalid could help caching block failures at an earlier stage is incorrect.”

    However, Poinsot and others also previously proposed forbidding 64-byte transactions to protect software verifying merkle proofs against CVE-2017-12842. This vulnerability affects lightweight wallets that use simplified payment verification (SPV) as described in the original Bitcoin paper. It can also affect sidechains that perform SPV and may affect some proposed covenants that require soft fork activation.

    Since the publication of CVE-2017-12842, it’s been known that SPV can be made safe by a verifier additionally checking the depth of the coinbase transaction in a block. Voskuil estimates this would require an additional 576 bytes on average for typical modern blocks—a small increase in bandwidth. Poinsot summarized the arguments and Anthony Towns expanded on an argument about the complexity of performing the additional depth verification.

    Voskuil also linked to a previous suggestion by Sergio Demian Lerner for an alternative soft fork consensus change that would have a block header commit to the depth of its merkle tree. This would also protect against CVE-2017-12842 without forbidding 64-byte transactions and would allow SPV proofs to be maximally efficient.

    Discussion was ongoing at the time of writing.

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.

  • ● Core Lightning 24.08 is a major release of this popular LN node implementation containing new features and bug fixes.

  • ● LDK 0.0.124 is the latest releases of this library for building LN-enabled applications.

  • ● LND v0.18.3-beta.rc2 is a release candidate for a minor bug fix release of this popular LN node implementation.

  • ● BDK 1.0.0-beta.2 is a release candidate for this library for building wallets and other Bitcoin-enabled applications. The original bdk Rust crate has been renamed to bdk_wallet and lower layer modules have been extracted into their own crates, including bdk_chain, bdk_electrum, bdk_esplora, and bdk_bitcoind_rpc. The bdk_wallet crate “is the first version to offer a stable 1.0.0 API.”

  • ● Bitcoin Core 28.0rc1 is a release candidate for the next major version of the predominant full node implementation. A testing guide is available.

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.

Note: the commits to Bitcoin Core mentioned below apply to its master development branch, so those changes will likely not be released until about six months after the release of the upcoming version 28.

  • ● Bitcoin Core #30454 and #30664 respectively add a CMake-based build system (see Newsletter #316) and remove the previous autotools-based build system. See also follow-ups in PRs #30779, #30785, #30763, #30777, #30752, #30753, #30754, #30749, #30653, #30739, #30740, #30744, #30734, #30738, #30731, #30508, #30729, and #30712.

  • ● Bitcoin Core #22838 implements multiple derivation path descriptors (BIP389), which allows a single descriptor string to specify two related derivation paths, the first for receiving payments, and the second for internal use (such as for change). See Newsletters #211 and #258.

  • ● Eclair #2865 adds the ability to wake up a disconnected mobile peer by attempting to connect to its last known IP address and push a mobile notification. This is especially useful in the context of async payments where the local node holds a payment or an onion message and when the peer comes back online, it is delivered. See Newsletter #232.

  • ● LND #9009 introduces a mechanism to ban peers for sending invalid channel announcements, such as channels that are already spent, have no funding transaction, or have an invalid funding output. Banned peers are handled differently depending on the relationship:

    • For banned peers without a shared channel, the node disconnects from them.

    • For banned peers with a shared channel, the node ignores all of their channel announcements for 48 hours.

  • ● LDK #3268 adds ConfirmationTarget::MaximumFeeEstimate for a more conservative fee estimation method for dust calculations when checking counterparty feerates, to avoid unnecessary force closures caused by sudden fee spikes. This PR also splits ConfirmationTarget::OnChainSweep into UrgentOnChainSweep and NonUrgentOnChainSweep to distinguish between time-sensitive (e.g., with expiring HTLCs) and non-urgent force closures.

  • ● HWI #742 adds support for the Trezor Safe 5 hardware signing device.

  • ● BIPs #1657 adds a new standard field to PSBT outputs for DNSSEC proofs when using BIP353. External devices such as hardware signers may examine the PSBT outputs to retrieve RFC 9102-formatted proofs, which enforce time constraints to ensure that only valid proofs are accepted. See Newsletter #307.