This week’s newsletter summarizes a draft BIP for block template sharing between full nodes and announces a library that allows trusted delegation of script evaluation (including for features not available in Bitcoin’s native scripting languages). Also included are our regular sections describing recent updates to services and client software, announcing new releases and release candidates, and summarizing notable changes to popular Bitcoin infrastructure software.

News

  • ● Draft BIP for block template sharing: Anthony Towns posted to the Bitcoin-Dev mailing list the draft of a BIP for how nodes can communicate to their peers the transactions they would attempt to mine in their next block (see Newsletter #366). This allows the node to share transactions it will accept via its mempool and mining policy that its peers might normally reject by their own policy, allowing those peers to cache those transactions in case they are mined (which improves compact block relay effectiveness). The transactions in a node’s block template are usually the most profitable unconfirmed transactions known to that node, so peers that previously rejected those transactions for policy reasons might also find them worthy of additional consideration.

    The protocol specified in the draft BIP is simple. Shortly after a connection with a peer is initiated, the node sends a sendtemplate message indicating to the peer that it is willing to send block templates. At any later time, the peer can request a template with a gettemplate message. In response to the request, the node replies with a template message that contains a list of short transaction identifiers using the same format as a BIP152 compact block message. The peer can then request any transactions it wants by including the short identifier in a sendtransactions message (also as in BIP152). The draft BIP allows templates to be up to slightly more than twice the size of the current maximum block weight limit.

    A Delving Bitcoin thread about template sharing saw additional discussion this week about how to improve the bandwidth efficiency of the proposal. Ideas discussed included only sending only the difference since the previous template (an estimated 90% bandwidth savings), using a set reconciliation protocol such as that enabled by minisketch (allowing much larger templates to be shared efficiently), and using Golomb-Rice encoding on the templates similar to compact block filters (an estimated 25% efficiency).

  • ● Trusted delegation of script evaluation: Josh Doman posted to Delving Bitcoin about a library he’s written that uses a trusted execution environment (TEE) that will only sign a taproot keypath spend if the transaction containing that spend satisfies a script. The script can contain opcodes that are not currently active on Bitcoin today or a completely different form of script (e.g. Simplicity or bll).

    This approach requires those receiving funds to the script to trust the TEE—both that it will still be available to sign in the future and that it will only sign a spend that satisfies its encumbrance script—but it allows rapid experimentation with proposed new features for Bitcoin with actual monetary value. To reduce trust in the TEE remaining available, a backup spend path can be included; for example, a timelocked path that allows a participant to unilaterally spend their funds a year after entrusting them to the TEE.

    The library is designed for use with the Amazon Web Services (AWS) Nitro enclave.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

  • ● ZEUS v0.11.3 released: The v0.11.3 release includes improvements to peer management, BOLT12, and submarine swap features.

  • ● Rust Utreexo resources: Abdelhamid Bakhta posted Rust-based resources for Utreexo, including interactive educational materials and WASM bindings.

  • ● Peer-observer tooling and call to action: 0xB10C posted about the motivation, architecture, code, supporting libraries, and findings of his peer-observer project. He seeks to build “A loose, decentralized group of people who share the interest of monitoring the Bitcoin Network. A collective to enable sharing of ideas, discussion, data, tools, insights, and more.”

  • ● Bitcoin Core Kernel-based node announced: Bitcoin backbone was announced as a demonstration of using the Bitcoin Core Kernel library as the foundation of a Bitcoin node.

  • ● SimplicityHL released: SimplicityHL is a Rust-like programming language that compiles to the lower-level Simplicity language recently activated on Liquid. For further reading, see the related Delving thread.

  • ● LSP plugin for BTCPay Server: The LSP plugin implements client-side features of BLIP51, the specification for inbound channels, into BTCPay Server.

  • ● Proto mining hardware and software announced: Proto announced new Bitcoin mining hardware and open source mining software, built with previous community feedback.

  • ● Oracle resolution demo using CSFS: Abdelhamid Bakhta posted a demonstration of an oracle using CSFS, nostr, and MutinyNet to sign an attestation of an event’s outcome.

  • ● Relai adds taproot support: Relai added support for sending to taproot addresses.

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 v0.19.3-beta is a release for a maintenance version for this popular LN node implementation containing “important bug fixes”. Most notably, “an optional migration […] lowers disk and memory requirements for nodes significantly.”

  • ● Bitcoin Core 29.1rc1 is a release candidate for a maintenance version of the predominant full node software.

  • ● Core Lightning v25.09rc2 is a release candidate for a new major version of this popular LN node implementation.

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 #32896 introduces support for creating and spending unconfirmed Topologically Restricted Until Confirmation (TRUC) transactions by adding a version parameter to the following RPCs: createrawtransaction, createpsbt, send, sendall, and walletcreatefundedpsbt. The wallet enforces the TRUC transaction restrictions for weight limit, sibling conflict, and incompatibility between unconfirmed TRUC and non-TRUC transactions.

  • ● Bitcoin Core #33106 lowers the default blockmintxfee to 1 sat/kvB (the minimum possible), and the default minrelaytxfee and incrementalrelayfee to 100 sat/kvB (0.1 sat/vB). While these values can be configured, users are advised to adjust the minrelaytxfee and incrementalrelayfee values together. Other minimum feerates remain unchanged, but the default wallet minimum feerates are expected to be lowered in a future version. The motivations for this change range from considerable growth in the number of blocks mined with sub 1 sat/vB transactions and the number of pools mining these transactions to an increase in the Bitcoin exchange rate.

  • ● Core Lightning #8467 extends xpay (see Newsletter #330) by adding support for paying BIP353 Human Readable Names (HRN) (e.g. satoshi@bitcoin.com) and enabling it to pay BOLT12 offers directly, removing the need to run the fetchinvoice command first. Under the hood, xpay fetches the payment instructions using the fetchbip353 RPC command from the cln-bip353 plugin introduced in Core Lightning #8362.

  • ● Core Lightning #8354 starts publishing pay_part_start and pay_part_end event notifications for the status of specific payment parts sent with MPP. The pay_part_end notification indicates the duration of the payment and whether it was successful or failed. If the payment fails, an error message is provided and, if the error onion isn’t corrupted, additional information on the failure is given, such as the source of the error and the failure code.

  • ● Eclair #3103 introduces support for simple taproot channels, leveraging MuSig2 scriptless multisignature signing to reduce transaction weight consumption by 15% and improve transaction privacy. Funding transactions and cooperative closures are indistinguishable from other P2TR transactions. This PR also includes support for dual funding and splicing in simple taproot channels, and enables channel commitment upgrades to the new taproot format during a splice transaction.

  • ● Eclair #3134 replaces the penalty weight multiplier for stuck HTLCs with the CLTV expiry delta when scoring HTLC endorsement peer reputation (see Newsletter #363), to better reflect how long a stuck HTLC will tie up liquidity. To mitigate the outsized penalty of stuck HTLCs with a maximum CLTV expiry delta, this PR adjusts the reputation decay parameter (half-life) from 15 to 30 days and the stuck payment threshold (max-relay-duration) from 12 seconds to 5 minutes.

  • ● LDK #3897 extends its peer storage implementation by detecting lost channel state during backup retrieval, by deserializing the peer’s copy and comparing it to the local state.

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 August 26. The discussion is also recorded and will be available from our podcasts page.