diff --git a/_posts/en/newsletters/2026-07-10-newsletter.md b/_posts/en/newsletters/2026-07-10-newsletter.md new file mode 100644 index 000000000..fc7657fcd --- /dev/null +++ b/_posts/en/newsletters/2026-07-10-newsletter.md @@ -0,0 +1,140 @@ +--- +title: 'Bitcoin Optech Newsletter #413' +permalink: /en/newsletters/2026/07/10/ +name: 2026-07-10-newsletter +slug: 2026-07-10-newsletter +type: newsletter +layout: newsletter +lang: en +--- +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][fount del] to Delving Bitcoin + about his latest research on using [fountain codes][fount wiki] to allow pruned nodes + to contribute to Initial Block Download (IBD), without significantly increasing their + storage requirements. + + Lima provided a dedicated [blog post][fount blog] 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][topic transaction origin privacy] (see [Newsletter #409][news409 + privatebroadcast]), and includes fixes for chainstate database compaction, + wallet migration, input-size estimation, [MuSig2][topic musig] key + aggregation, and proxy handling during [v2 P2P transport][topic v2 p2p + transport] reconnections. See the [release notes][bcc31.1 rn] 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][topic + htlc] CLTV expiry validation covered last week (see [Newsletter + #412][news412 cltv]). + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +- [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][news366 watchonly]). The exported wallet contains the + original wallet's public [descriptors][topic 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][topic 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][news310 mining] and [#323][news323 mining]). 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][topic + pooled mining] 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][core lightning #9292] add + experimental support for the `option_simple_close` cooperative close + protocol (see [Newsletter #342][news342 simpleclose]). 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][core lightning #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][topic htlc] 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][topic channel jamming attacks] 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][topic + offers] by adding support for `InvoiceRequest` messages (see [Newsletter + #410][news410 bolt12]). The new code adds TLV encoding, decoding, and + structural validation, while deferring signature verification and + cross-checking against the corresponding offer to subsequent PRs. + +{% include snippets/recap-ad.md when="2026-07-14 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32489,32606,34020,9104,9292,3323,10832" %} +[fount del]: https://delvingbitcoin.org/t/fountain-codes-a-way-to-reduce-blockchain-storage-costs/2624 +[fount wiki]: https://en.wikipedia.org/wiki/Fountain_code +[fount blog]: https://lucasdbr05.com/posts/fountain-codes/ +[Bitcoin Core 31.1]: https://bitcoincore.org/bin/bitcoin-core-31.1/ +[bcc31.1 rn]: https://bitcoincore.org/en/releases/31.1/ +[LND v0.20.2-beta]: https://github.com/lightningnetwork/lnd/releases/tag/v0.20.2-beta +[news366 watchonly]: /en/newsletters/2025/08/08/#bitcoin-core-pr-review-club +[news310 mining]: /en/newsletters/2024/07/05/#bitcoin-core-30200 +[news323 mining]: /en/newsletters/2024/10/04/#bitcoin-core-30510 +[news342 simpleclose]: /en/newsletters/2025/02/21/#bolts-1205 +[news410 bolt12]: /en/newsletters/2026/06/19/#lnd-10789 +[news409 privatebroadcast]: /en/newsletters/2026/06/12/#bitcoin-core-35410 +[news412 cltv]: /en/newsletters/2026/07/03/#lnd-10927 \ No newline at end of file diff --git a/_topics/en/channel-jamming-attacks.md b/_topics/en/channel-jamming-attacks.md index d684dd8ca..14dffadfc 100644 --- a/_topics/en/channel-jamming-attacks.md +++ b/_topics/en/channel-jamming-attacks.md @@ -121,6 +121,9 @@ optech_mentions: - title: Protocol proposed for upfront and hold fees to address channel jamming url: /en/newsletters/2025/03/28/#ln-upfront-and-hold-fees-using-burnable-outputs + - title: "Eclair #3323 fails incoming HTLCs with a CLTV expiry more than 2016 blocks in the future" + url: /en/newsletters/2026/07/10/#eclair-3323 + ## Optional. Same format as "primary_sources" above see_also: - title: HTLCs diff --git a/_topics/en/compact-block-relay.md b/_topics/en/compact-block-relay.md index 25be4653e..b3b560e8c 100644 --- a/_topics/en/compact-block-relay.md +++ b/_topics/en/compact-block-relay.md @@ -81,6 +81,9 @@ optech_mentions: - title: "Bitcoin Core #35550 rejects sendcmpct messages with an out-of-range announcement field" url: /en/newsletters/2026/07/03/#bitcoin-core-35550 + - title: "Bitcoin Core #32606 ignores compact block messages from peers that haven't negotiated support" + url: /en/newsletters/2026/07/10/#bitcoin-core-32606 + ## Optional. Same format as "primary_sources" above # see_also: # - title: