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 to Delving Bitcoin and the Bitcoin-Dev mailing list an update on the Hornet node project. Sharp had previously 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 to Delving Bitcoin about the onion message 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 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 by Olaoluwa Osuntokun, this technique is similar in scope as upfront fees, but adds per-session state and settles through AMP payments. 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 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 recently.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange 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.

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 describe several significant improvements, including the implementation of the cluster mempool design, a new -privatebroadcast option for sendrawtransaction (see Newsletter #388), asmap data optionally embedded into the binary for eclipse attack 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 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 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.

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 #33477 updates how the dumptxoutset RPC’s rollback mode (see Newsletter #72) builds historical UTXO set dumps used for 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 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 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 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 for blinded payment paths. 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, dropping excess traffic at ingress before it reaches the onion handler. This hardens LND’s recently added onion message forwarding support (see Newsletter #396) against high-volume abuse from fast peers. The per-peer and global split mirrors LND’s earlier gossip bandwidth limits (see Newsletter #370).

  • ● LND #10754 stops forwarding an onion message when the chosen next hop is the same peer that delivered it, avoiding an immediate bounce on the same connection.

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