diff --git a/_includes/references.md b/_includes/references.md index b4652ac2c..808da15cb 100644 --- a/_includes/references.md +++ b/_includes/references.md @@ -189,6 +189,7 @@ for details --> {% endcomment %} [BIP351]: https://github.com/bitcoin/bips/blob/master/bip-0351.mediawiki [BIP352]: https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki [BIP353]: https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki +[BIP361]: https://github.com/bitcoin/bips/blob/master/bip-0361.mediawiki [BIP370]: https://github.com/bitcoin/bips/blob/master/bip-0370.mediawiki [BIP371]: https://github.com/bitcoin/bips/blob/master/bip-0371.mediawiki [BIP372]: https://github.com/bitcoin/bips/blob/master/bip-0372.mediawiki diff --git a/_posts/en/newsletters/2026-04-24-newsletter.md b/_posts/en/newsletters/2026-04-24-newsletter.md new file mode 100644 index 000000000..03a23e654 --- /dev/null +++ b/_posts/en/newsletters/2026-04-24-newsletter.md @@ -0,0 +1,226 @@ +--- +title: 'Bitcoin Optech Newsletter #402' +permalink: /en/newsletters/2026/04/24/ +name: 2026-04-24-newsletter +slug: 2026-04-24-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter describes Hornet Node's work on a declarative executable +specification of consensus rules and summarizes a discussion about onion message +jamming in the Lightning Network. Also included are our regular sections with +selected questions and answers from the Bitcoin Stack Exchange, announcements of +new releases and release candidates, and descriptions of notable changes to +popular Bitcoin infrastructure software. + +## News + +- **Hornet Node's declarative executable specification of Bitcoin consensus rules**: + Toby Sharp [posted][topic hornet update] to Delving Bitcoin and the Bitcoin-Dev [mailing + list][hornet ml post] an update on the Hornet node project. Sharp had + [previously][topic hornet] described a new node implementation Hornet that + reduced initial block download times from 167 minutes down to 15 minutes. In + this update, he reports completing a declarative specification of non-script + block validation rules, consisting of 34 semantic invariants composed using a + simple algebra. + + Sharp also outlines future work, including extending the specification to + script validation, and discusses potential comparisons with other + implementations such as libbitcoin in response to feedback from Eric Voskuil. + +- **Onion message jamming in the Lightning Network**: Erick Cestari [posted][onion del] to + Delving Bitcoin about the [onion message][topic onion messages] jamming problem affecting + the Lightning Network. BOLT4 acknowledges onion messages to be unreliable, recommending + to apply rate limiting techniques. According to Cestari, these techniques are what makes message jamming possible. Attackers + may spin up malicious nodes and flood the network with spam messages triggering rate limits + of peers, forcing them to drop legitimate messages. Moreover, BOLT4 does not enforce a + maximum message length, allowing attackers to maximize the reach of a single message. + + Cestari reviewed several mitigations to onion message jamming and provided a + comprehensive overview of the techniques he deemed more suitable: + + - *Upfront fees*: This technique was first proposed by Carla Kirk-Cohen in [BOLTs #1052][] + as a solution for channel jamming, but can be easily extended. Nodes would advertise a per-message + flat fee, to be included in the onion payload and deducted at each hop. In case the fee is not + paid, the message would be just dropped by the node. This method presents some limitations, such + as being able to only forward messages to channel peers and increased p2p overhead. + + - *Hop limit and proof-of-stake based on channel balances*: This technique was [proposed][mitig2 onion] + by Bashiri and Khabbazian at the University of Alberta and has two different components: + + - Leashing hop count: Either setting a hard-cap on the maximum number of hops that a message could do + (e.g. 3 hops), or having the sender solve a proof-of-work puzzle, whose difficulty increases + exponentially with the number of hops. + + - Proof-of-stake forwarding rule: Each node sets per-peer rate limits according to the peer's aggregate + channel balance, granting well-funded nodes more forwarding power. + + The trade-offs of this approach are related to centralization pressure, due to larger nodes being at + an advantage, while the 3-hops hard-cap could reduce anonymity set. + + - *Bandwidth metered payment*: [Proposed][mitig3 onion] by Olaoluwa Osuntokun, this technique is + similar in scope as upfront fees, but adds per-session state and settles through + [AMP payments][topic amp]. A sender would first send the AMP payment, dropping fees + at each intermediate step and delivering an ID for the session. The sender would then include the + ID in the onion message. Known limitations of the approach are related to the ability to only forward + messages to channel peers and the possibility to link all the messages belonging to the same session. + + - *Backpropagation-based rate limiting*: This approach, [proposed][mitig4 onion] by Bastien Teinturier, + uses a backpressure mechanism that is statistically able to trace back spam to its source. + When the per-peer rate limiting is hit, the node sends a drop message back to the sender, which in turn + relays it to the last peer that forwarded the original message halving its rate limit. While the correct + sender is statistically identified, the wrong peer could be penalized. Moreover, an attacker could fake + the drop message, lowering rate limits of honest nodes. + + Finally, Cestari invited LN developers to join the discussion, stating that a window is still available to + mitigate the issue before prolonged DDoS attacks hit the network, as [happened to Tor][tor issue] recently. + +## Selected Q&A from Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] is one of the first places Optech +contributors look for answers to their questions---or when we have a +few spare moments to help curious or confused users. In +this monthly feature, we highlight some of the top-voted questions and +answers posted since our last update.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Why did BIP342 replace CHECKMULTISIG with a new opcode, instead of just removing FindAndDelete from it?]({{bse}}130665) + Pieter Wuille explains that the replacement of `OP_CHECKMULTISIG` with + `OP_CHECKSIGADD` in [tapscript][topic tapscript] was necessary to enable batch + verification of [schnorr][topic schnorr signatures] signatures (see + [Newsletter #46][news46 batch]) in a potential future protocol change. + +- [Does SIGHASH_ANYPREVOUT commit to the tapleaf hash or the full taproot merkle path?]({{bse}}130637) + Antoine Poinsot confirms that [SIGHASH_ANYPREVOUT][topic sighash_anyprevout] + signatures currently commit only to the tapleaf hash, not the full merkle path + in the [taproot][topic taproot] tree. However, this design is under discussion + as one BIP co-author has suggested committing to the full merkle path instead. + +- [What does the BIP86 tweak guarantee in a MuSig2 Lightning channel, beyond address format?]({{bse}}130652) + Ava Chow points out that the tweak prevents the use of hidden script paths + because [MuSig2's][topic musig] signing protocol requires all participants to + apply the same [BIP86][] tweak for signature aggregation to succeed. If one + party attempts to use a different tweak, such as one derived from a hidden + script tree, their partial signature won't aggregate into a valid final + signature. + +## 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.0][] is the latest major version release of the network’s + predominant full node implementation. The [release notes][notes31] describe + several significant improvements, including the implementation of the [cluster + mempool][topic cluster mempool] design, a new `-privatebroadcast` option for + `sendrawtransaction` (see [Newsletter #388][news388 private]), `asmap` data + optionally embedded into the binary for [eclipse attack][topic eclipse + attacks] protection, and an increase in the default `-dbcache` to 1024 MiB on + systems with at least 4096 MiB of RAM, among many other updates. + +- [Core Lightning 26.04][] is a major release of this popular LN node + implementation. It enables [splicing][topic splicing] by default, adds new + `splicein` and `spliceout` commands including a `cross-splice` mode that + targets a second channel as the destination of a splice-out, redesigns + `bkpr-report` for income summaries, adds parallel pathfinding and multiple bug + fixes in `askrene`, adds a `fronting_nodes` option on the `offer` RPC and a + `payment-fronting-node` config, and removes support for the legacy onion + format. See the [release notes][notes cln] for additional details. + +- [LND 0.21.0-beta.rc1][] is the first release candidate for the next major + version of this popular LN node. Users running nodes with the + `--db.use-native-sql` flag against an SQLite or PostgreSQL backend should note that + this version migrates the payment store from the key-value (KV) format to + native SQL, with an opt-out via `--db.skip-native-sql-migration`. See the + [release notes][notes lnd]. + +## 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 #33477][] updates how the `dumptxoutset` RPC’s `rollback` mode + (see [Newsletter #72][news72 dump]) builds historical UTXO set dumps used for + [assumeUTXO][topic assumeutxo] snapshots. Instead of rolling back the main + chainstate by invalidating blocks, Bitcoin Core creates a temporary UTXO + database, rolls it back to the requested height, and writes the snapshot from + the temporary database. This preserves the main chainstate, eliminating the + need to suspend network activity and the risk of fork-related interference + with the rollback, at the cost of additional temporary disk space and slower + dumps. A new `in_memory` option keeps the temporary UTXO database entirely in + RAM, enabling faster rollbacks but requiring over 10 GB of free memory on + mainnet. For deep rollbacks, it is recommended to use no RPC timeout (`bitcoin-cli + -rpcclienttimeout=0`) as it may take several minutes. + +- [Bitcoin Core #35006][] adds a `-rpcid` option to `bitcoin-cli` to set a + custom string as the JSON-RPC request `id` instead of the default hardcoded + value of `1`. This allows requests and responses to be correlated when + multiple clients make concurrent calls. The identifier is also included in the + server-side RPC debug log. + +- [BIPs #1895][] publishes [BIP361][], an abstract proposal for + [post-quantum][topic quantum resistance] migration and legacy signature + sunset. Assuming a separate post-quantum (PQ) signature scheme is standardized + and deployed, it outlines a phased migration away from ECDSA/[schnorr][topic + schnorr signatures] signature schemes. The current version of the proposal is + divided into two phases. Phase A prohibits sending funds to quantum-vulnerable + addresses, thereby accelerating the adoption of PQ address types. Phase B + restricts ECDSA/schnorr spending and includes a quantum-safe rescue protocol + to prevent theft of quantum-vulnerable UTXOs. + +- [BIPs #2142][] updates [BIP352][], the [silent payments][topic silent + payments] BIP proposal, by adding a send/receive test vector for an edge case + where the running sum of input keys hits zero after two inputs but the final + sum over all inputs is non-zero. This catches implementations that reject + early during incremental summation instead of summing all inputs first. + +- [LDK #4555][] fixes how forwarding nodes enforce [`max_cltv_expiry`][topic + cltv expiry delta] for [blinded payment paths][topic rv routing]. The field is + meant to ensure an expired blinded route is rejected at the introduction hop + rather than being forwarded through the blinded segment and failing closer to + the receiver. Previously, LDK compared the constraint against the hop's + outgoing CLTV value; it now checks the inbound CLTV expiry as intended. + +- [LND #10713][] adds per-peer and global token-bucket rate limits for incoming + [onion messages][topic onion messages], dropping excess traffic at ingress + before it reaches the onion handler. This hardens LND's recently added onion + message forwarding support (see [Newsletter #396][news396 lnd onion]) against + high-volume abuse from fast peers. The per-peer and global split mirrors LND's + earlier gossip bandwidth limits (see [Newsletter #370][news370 lnd gossip]). + +- [LND #10754][] stops forwarding an [onion message][topic onion messages] when + the chosen next hop is the same peer that delivered it, avoiding an immediate + bounce on the same connection. + +{% include snippets/recap-ad.md when="2026-04-28 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="1052,33477,35006,4555,10713,10754,1895,2142" %} +[news46 batch]: /en/newsletters/2019/05/14/#new-script-based-multisig-semantics +[topic hornet update]: https://delvingbitcoin.org/t/hornet-update-a-declarative-executable-specification-of-consensus-rules/2420 +[hornet ml post]: https://groups.google.com/g/bitcoindev/c/M7jyQzHr2g4 +[topic hornet]: /en/newsletters/2026/02/06/#a-constant-time-parallelized-utxo-database +[onion del]: https://delvingbitcoin.org/t/onion-message-jamming-in-the-lightning-network/2414 +[mitig2 onion]: https://ualberta.scholaris.ca/items/245a6a68-e1a6-481d-b219-ba8d0e640b5d +[mitig3 onion]: https://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail/lightning-dev/2022-February/003498.txt +[mitig4 onion]: https://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail/lightning-dev/2022-June/003623.txt +[tor issue]: https://blog.torproject.org/tor-network-ddos-attack/ +[Bitcoin Core 31.0]: https://bitcoincore.org/bin/bitcoin-core-31.0/ +[notes31]: https://bitcoincore.org/en/releases/31.0/ +[news388 private]: /en/newsletters/2026/01/16/#bitcoin-core-29415 +[Core Lightning 26.04]: https://github.com/ElementsProject/lightning/releases/tag/v26.04 +[notes cln]: https://github.com/ElementsProject/lightning/releases/tag/v26.04 +[LND 0.21.0-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.21.0-beta.rc1 +[notes lnd]: https://github.com/lightningnetwork/lnd/blob/master/docs/release-notes/release-notes-0.21.0.md +[news72 dump]: /en/newsletters/2019/11/13/#bitcoin-core-16899 +[news396 lnd onion]: /en/newsletters/2026/03/13/#lnd-10089 +[news370 lnd gossip]: /en/newsletters/2025/09/05/#lnd-10103 diff --git a/_topics/en/assumeutxo.md b/_topics/en/assumeutxo.md index 3eb29451a..a2422ab85 100644 --- a/_topics/en/assumeutxo.md +++ b/_topics/en/assumeutxo.md @@ -76,6 +76,9 @@ optech_mentions: - title: "SwiftSync faster syncs compatible and complementary with assumeUTXO" url: /en/newsletters/2025/04/11/#swiftsync-speedup-for-initial-block-download + - title: "Bitcoin Core #33477 improves assumeUTXO snapshot creation using a temporary chainstate" + url: /en/newsletters/2026/04/24/#bitcoin-core-33477 + ## Optional. Same format as "primary_sources" above see_also: - title: "Bitcoin Core issue #15605: AssumeUTXO discussion" diff --git a/_topics/en/onion-messages.md b/_topics/en/onion-messages.md index 6e83c5a43..dc3c8c15b 100644 --- a/_topics/en/onion-messages.md +++ b/_topics/en/onion-messages.md @@ -101,6 +101,9 @@ optech_mentions: - title: "Discussion about separating onion message relay from HTLC relay" url: /en/newsletters/2025/07/04/#separating-onion-message-relay-from-htlc-relay + - title: "Discussion of onion message jamming and mitigation techniques" + url: /en/newsletters/2026/04/24/#onion-message-jamming-in-the-lightning-network + ## Optional. Same format as "primary_sources" above see_also: - title: Blinded paths diff --git a/_topics/en/quantum-resistance.md b/_topics/en/quantum-resistance.md index e06b6fd46..8b49ee250 100644 --- a/_topics/en/quantum-resistance.md +++ b/_topics/en/quantum-resistance.md @@ -124,6 +124,9 @@ optech_mentions: - title: "SHRIMPS: 2.5 KB post-quantum signatures across multiple stateful devices" url: /en/newsletters/2026/04/03/#shrimps-2-5-kb-post-quantum-signatures-across-multiple-stateful-devices + - title: "BIPs #1895 publishes BIP361, a post-quantum migration and legacy signature deprecation proposal" + url: /en/newsletters/2026/04/24/#bips-1895 + ## Optional. Same format as "primary_sources" above see_also: - title: Taproot diff --git a/_topics/en/silent-payments.md b/_topics/en/silent-payments.md index 0141302eb..a5dbad59e 100644 --- a/_topics/en/silent-payments.md +++ b/_topics/en/silent-payments.md @@ -101,6 +101,9 @@ optech_mentions: - title: "BIPs #2089 publishes BIP376, defining new PSBTv2 fields for BIP352 tweak data" url: /en/newsletters/2026/04/17/#bips-2089 + - title: "BIPs #2142 adds a send/receive test vector to the BIP352 silent payments specification" + url: /en/newsletters/2026/04/24/#bips-2142 + ## Optional. Same format as "primary_sources" above see_also: - title: Output linking