This week’s newsletter describes a fixed vulnerability affecting old versions of Bitcoin Core. Also included are our regular sections summarizing recent discussions about changing Bitcoin’s consensus rules, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

  • ● Vulnerability disclosure affecting old versions of Bitcoin Core: Antoine Poinsot posted to the Bitcoin-Dev mailing list to announce a vulnerability affecting Bitcoin Core versions before 29.0. The vulnerability was originally responsibly disclosed by Eugene Siegel along with another closely related vulnerability described in Newsletter #314. An attacker could send an excessive number of node address advertisements to force a 32-bit identifier to overflow, resulting in a node crash. This was partly mitigated by limiting the number of updates to one per peer per every ten seconds, which for the default limit of about 125 peers would prevent overflow unless the node was continuously attacked for over 10 years. The vulnerability was completely fixed by using 64-bit identifiers, starting with last month’s release of Bitcoin Core 29.0.

Changing consensus

A monthly section summarizing proposals and discussion about changing Bitcoin’s consensus rules.

  • ● Proposed BIP for 64-bit arithmetic in Script: Chris Stewart posted a draft BIP to the Bitcoin-Dev mailing list that proposes upgrading Bitcoin’s existing opcodes to operate on 64-bit numeric values. This follows his previous research (see Newsletters #285, #290, and #306). In a change from some of the earlier discussion, the new proposal uses numbers in the same compactSize data format currently used in Bitcoin. Additional related discussion occurred on two threads on Delving Bitcoin.

  • ● Proposed opcodes for enabling recursive covenants through quines: Bram Cohen posted to Delving Bitcoin to suggest a set of simple opcodes that would enable the creation of recursive covenants through self-reproducing scripts (quines). Cohen describes how the opcodes could be used to create a simple vault and mentions a more advanced system that he’s been working on.

  • ● Description of benefits to BitVM from OP_CTV and OP_CSFS: Robin Linus posted to Delving Bitcoin about several of the improvements to BitVM that would become possible if the proposed OP_CTV and OP_CSFS opcodes were added to Bitcoin in a soft fork. The benefits he describes includes increasing the number of operators without downsides, “reducing transaction sizes by approximately 10x” (which reduces worst-case costs), and allowing non-interactive peg-ins for certain contracts.

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.

  • ● LND 0.19.0-beta.rc4 is a release candidate for this popular LN node. One of the major improvements that could probably use testing is the new RBF-based fee bumping for cooperative closes.

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 #32155 updates the internal miner to timelock coinbase transactions by setting the nLockTime field to the current block’s height minus one and requiring the nSequence field not to be final (to enforce the timelock). Although the built-in miner isn’t typically used on mainnet, updating it encourages mining pools to adopt these changes early in their own software in preparation for the consensus cleanup soft fork proposed in BIP54. Timelocking coinbase transactions solves the duplicate transaction vulnerability, and would allow the costly BIP30 checks to be lifted.

  • ● Bitcoin Core #28710 removes the remaining legacy wallet code, documentation, and related tests. This includes the legacy-only RPCs, such as importmulti, sethdseed, addmultisigaddress, importaddress, importpubkey, dumpwallet, importwallet, and newkeypool. As the final step for legacy wallet removal, the BerkeleyDB dependency and related functions are also removed. However, the bare minimum of legacy code and an independent BDB parser (see Newsletter #305) are retained in order to perform wallet migration to descriptor wallets.

  • ● Core Lightning #8272 disables the DNS seed lookup peer discovery fallback from the connection daemon connectd to resolve call block issues caused by offline DNS seeds.

  • ● LND #8330 adds a small constant (1/c) to the pathfinding bimodal probability model to address numerical instability. In edge cases where the calculation would otherwise fail due to rounding errors and produce a zero probability, this regularization provides a fallback by causing the model to revert to a uniform distribution. This resolves normalization bugs that occur in scenarios involving very large channels or channels that don’t fit a bimodal distribution. Additionally, the model now skips unnecessary probability calculations and automatically corrects outdated channel liquidity observations and contradictory historical information.

  • ● Rust Bitcoin #4458 replaces the MtpAndHeight struct with an explicit pair of the newly added BlockMtp and the already existing BlockHeight, enabling better modeling of both block height and Median Time Past (MTP) values in relative timelocks. Unlike locktime::absolute::MedianTimePast, which is constrained to values above 500 million (roughly after 1985), BlockMtp can represent any 32-bit timestamp. This makes it suitable for theoretical edge cases, such as chains with unusual timestamps. This update also introduces BlockMtpInterval, and renames BlockInterval to BlockHeightInterval.

  • ● BIPs #1848 updates the status of BIP345 to Withdrawn, as the author believes its proposed OP_VAULT opcode has been superseded by OP_CHECKCONTRACTVERIFY (OP_CCV), a more general vault design and a new type of covenant.

  • ● BIPs #1841 merges BIP172, which proposes formally defining Bitcoin’s indivisible base unit as a “satoshi,” reflecting current widespread usage and helping standardize terminology across applications and documentation.

  • ● BIPs #1821 merges BIP177, which proposes redefining “bitcoin” to represent the smallest indivisible unit (commonly referred to as 1 satoshi), rather than 100,000,000 units. The proposal argues that aligning terminology with the actual base unit would reduce confusion caused by arbitrary decimal conventions.

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm at 16:30 UTC on May 20. The discussion is also recorded and will be available from our podcasts page.