This week’s newsletter shares an update on the proposal for nodes to share their current block template and summarizes a paper outlining a covenant-less vault construction. Also included are our regular sections announcing new releases and release candidates and describing notable changes to popular Bitcoin infrastructure software.

News

  • ● Continued discussion of block template sharing: Discussion continued around the proposal for full node peers to occasionally send each other their current template for the next block using compact block relay encoding (see Newsletters #366 and #368). Feedback was raised around privacy and node fingerprinting concerns and the author decided to move the current draft to the Bitcoin Inquisition Numbers and Names Authority (BINANA) repository, to address these considerations and to refine the document. The draft was given the code BIN-2025-0002.

  • ● B-SSL a Secure Bitcoin Signing Layer: Francesco Madonna posted to Delving Bitcoin about a concept which is a covenant-less vault model using taproot, OP_CHECKSEQUENCEVERIFY, and OP_CHECKLOCKTIMEVERIFY. In the post, he mentions that it uses existing Bitcoin primitives, which is important because most vault proposals require a soft fork.

    In the design, there are three different spend paths:

    1. A fast path for normal operation where an optional Convenience Service (CS) can enforce the chosen delay.

    2. A one-year fallback with custodian B.

    3. A three-year custodian path in case of disappearance or inheritance events.

    There are 6 different keys A, A₁, B, B₁, C and CS where B₁, and C are custodially held and are only used at the same time in the recovery path.

    This setup creates an environment where the user can lock up their funds and be fairly sure that the custodians they have entrusted their funds to won’t steal. While this does not restrict where the funds can move to like a covenant would, this setup does provide a more resilient scheme for self-custody with custodians. In the post, Francesco calls for readers to review and discuss the white paper before anyone tries to implement this idea.

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.

  • ● Bitcoin Core 30.0 is the latest version release of the network’s predominant full node. Its release notes describe several significant improvements, including a new 2500 cap on legacy sigops in standard transactions, multiple data carrier (OP_RETURN) outputs now being standard, an increased default datacarriersize to 100,000, a default minimum relay feerate and incremental relay feerate of 0.1sat/vb, a default minimum block feerate of 0.001sat/vb, improved transaction orphanage DoS protections, a new bitcoin CLI tool, an experimental inter-process communication (IPC) mining interface for Stratum v2 integrations, a new implementation of coinstatsindex, the natpmp option now being enabled by default, support for legacy wallets being removed in favor of descriptor wallets, and support for spending and creating TRUC transactions, among many other updates.

  • ● Bitcoin Core 29.2 is a minor release containing several bug fixes for P2P, mempool, RPC, CI, docs and other issues. Please see the release notes for more details.

  • ● LDK 0.1.6 is a release of this popular library for building LN-enabled applications that includes security vulnerability patches related to DoS and funds theft, performance improvements, and several bug fixes.

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.

  • ● Eclair #3184 improves the cooperative closing flow by resending a shutdown message upon reconnection when one had already been sent before disconnection, as specified in BOLT2. For simple taproot channels, Eclair generates a new closing nonce for the resend and stores it, allowing the node to produce a valid closing_sig later.

  • ● Core Lightning #8597 prevents a crash that occurred when a direct peer returned a failmsg response after CLN sent a malformed onion message via sendonion or injectpaymentonion. Now, CLN treats this as a plain first-hop failure and returns a clean error instead of crashing. Previously, it treated this as an encrypted failonion that came from further downstream.

  • ● LDK #4117 introduces an opt-in, deterministic derivation of the remote_key that uses the static_remote_key. This allows users to recover funds in the event of a force close using only the backup seed phrase. Previously, the remote_key depended on per-channel randomness, requiring channel state to recover funds. This new scheme is opt-in for new channels, but applies automatically when splicing existing ones.

  • ● LDK #4077 adds SplicePending and SpliceFailed events, with the former being emitted once a splice funding transaction is negotiated, broadcast, and locked by both sides (except in the case of an RBF). The latter event is emitted when a splice aborts before locking due to an interactive-tx failure, a tx_abort message, a channel shutdown, or a disconnection/reload while in a quiescent state.

  • ● LDK #4154 updates the handling of preimage on-chain monitoring to ensure that claim transactions are only created for HTLCs whose payment hash matches the retrieved preimage. Previously, LDK attempted to claim any claimable HTLC (expired ones and those with a known preimage), which risked creating invalid claim transactions and potential fund loss if the counterparty timed out another HTLC first.