This week’s newsletter describes research into using fountain codes to allow pruned nodes to contribute to initial block download. Also included are our regular sections announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

  • ● Using fountain codes for IBD: Lucas Lima posted to Delving Bitcoin about his latest research on using fountain codes to allow pruned nodes to contribute to Initial Block Download (IBD), without significantly increasing their storage requirements.

    Lima provided a dedicated blog post where he explains how this could be achieved by dividing the entire chain into epochs, fixed-length chunks made of k blocks, encoding these epochs using fountain codes, and sending these encodings, called droplets, together with block headers to those nodes that need to reconstruct the chain. The receiving node, referred to as a bucket node, needs to gather and decode enough droplets belonging to a certain epoch in order to reconstruct the k blocks. Block headers are then used to verify that the received data is valid, preventing malicious nodes from corrupting the reconstructed chain.

    Some critical points were raised during the discussion. In particular, developers highlighted the need for a high number of connected peers to manage to reconstruct the chain, slower IBD, risk of node fingerprinting, and possible increased DoS attack surface.

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 31.1 is a maintenance release of the predominant full-node implementation. It fixes an IP address leak in -privatebroadcast that could undermine transaction origin privacy (see Newsletter #409), and includes fixes for chainstate database compaction, wallet migration, input-size estimation, MuSig2 key aggregation, and proxy handling during v2 P2P transport reconnections. See the release notes for details.

  • ● LND v0.20.2-beta is a maintenance release of this popular LN node implementation. It fixes a DNS fallback panic and an onchain forward-interceptor settlement bug, and adds the final-hop HTLC CLTV expiry validation covered last week (see Newsletter #412).

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 #32489 adds an exportwatchonlywallet RPC that exports a watch-only version of the currently loaded wallet to a new wallet file, which can be loaded on another node using the restorewallet RPC (see Newsletter #366). The exported wallet contains the original wallet’s public descriptors, transactions, labels, and other metadata, but not private keys. Previously, users had to manually construct such a wallet by importing public descriptors.

  • ● Bitcoin Core #32606 updates compact block relay to ignore compact block messages from peers that have not negotiated support with sendcmpct, from peers not selected by the node for high-bandwidth announcements with sendcmpct(1), and whenever the local node is running in -blocksonly mode. Since compact blocks are reconstructed using transactions from the receiver’s mempool, processing them can reveal which transactions the receiver is missing or already has. This is particularly undesirable for blocks-only nodes because the transactions in their mempools are more likely to have originated locally.

  • ● Bitcoin Core #34020 adds the getTransactionsByTxID() and getTransactionsByWitnessID() methods to the Mining IPC interface (see Newsletters #310 and #323). Each method takes a list of txids or wtxids and returns the corresponding serialized transactions from the node’s mempool, or empty elements for transactions it doesn’t know about. This is useful for Stratum v2 custom job declaration, where a pool may want to request only those transactions from a miner-proposed block template that it doesn’t already have.

  • ● Core Lightning #9104 and #9292 add experimental support for the option_simple_close cooperative close protocol (see Newsletter #342). Legacy cooperative closes require peers to agree on a single closing transaction and fee, and if they disagree, the close can get stuck. Simple close avoids this issue by enabling each peer to propose a valid closing transaction that subtracts their chosen fee from their own output. Both versions can be signed and broadcast, and whichever conflicting transaction confirms first closes the channel. CLN implements this flow in a new simpleclosed subdaemon, that delays broadcasting its own version when the peer’s version pays a higher fee. #9292 fixes an edge case where CLN rejected a signed simple-close transaction that replaced the closer’s uneconomical output with a permitted zero-value OP_RETURN, causing a force close.

  • ● Eclair #3323 fails incoming HTLCs whose CLTV expiry is more than 2016 blocks (approximately two weeks) in the future. This extends Eclair’s existing maximum expiry policy for outgoing HTLCs, which reduces the risk of funds being locked for an extended period and makes channel jamming harder. Eclair temporarily accepts an offending HTLC into the channel commitment and then fails it, since rejecting it outright would force close the channel.

  • ● LND #10832 continues LND’s implementation of BOLT12 offers by adding support for InvoiceRequest messages (see Newsletter #410). The new code adds TLV encoding, decoding, and structural validation, while deferring signature verification and cross-checking against the corresponding offer to subsequent PRs.

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