This week’s newsletter describes a proposed contract protocol for mitigating Lightning Network channel jamming, reports on the availability of static Bitcoin Core binaries for testing, and summarizes a change replacing Bitcoin Core’s per-peer transaction rate-limiting with a global approach. Also included are our regular sections announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

• ● Conditional message transfer contract to solve jamming: Antoine Riard posted to Delving Bitcoin a new approach to mitigate channel jamming on the Lightning Network. Jamming is a denial-of-service attack in which the attacker sends HTLCs or PTLCs and then holds them unresolved, tying up the channel liquidity along a route at no cost to itself. Riard’s proposal makes holding expensive by charging a withhold fee proportional to how long a payment is held, converting a currently free attack into a costly one.

  The mechanism is a conditional message transfer contract (CMTC) which is a Bitcoin Script construction that lets two channel counterparties later prove whether a specific message (such as a payment preimage) was exchanged between them by a given block height, which Riard treats as a universal clock. The parties agree on a temporal window and assign an adaptor point to each point in time within it, so the withhold fee can be settled according to when the message was delivered. The contract offers three settlement paths:

  • ● Message transfer success: the preimage is delivered from Bob to Alice and cryptographically acknowledged, and the two split the withhold fee based on delivery time.

  • ● Liveness challenge: if Alice is offline and cannot counter-sign, Bob can exit the contract and recover the locked funds minus an equilibrium penalty fee.

  • ● Message transfer failure: if Bob is offline or otherwise fails to transfer the message, Alice can exit and recover the withhold fee.

  Riard notes that the proposed solution needs further analysis, both of its cryptographic correctness and of its incentives, and that it remains open whether this approach, or an expansion of it, could solve other types of problems in Bitcoin.

• ● Static Bitcoin Core binaries available for testing: Michael Ford (fanquake) posted to the Bitcoin-Dev mailing list announcing test builds of static Bitcoin Core release binaries produced using the project’s existing Guix infrastructure. Test binaries are available for bitcoind and the other command-line utilities on x86_64 and aarch64 Linux, with more platforms planned. The bitcoin-qt GUI binary is unchanged.

  Bitcoin Core’s current Linux release binaries are dynamically linked, meaning that they contain most of the code they need but depend on the C library (glibc) and a few related libraries provided by the user’s operating system. Those libraries are located and loaded each time the program starts, a dependency that carries some risks. The binaries only run on systems that provide a compatible glibc (currently version 2.31 or newer), their behavior can vary with the host’s libraries, and some of the code the node actually executes falls outside the binary that reproducible builds allow users to verify. A static binary instead includes all of the code it needs, so the same verified executable runs the same way on nearly any Linux system, including older releases, distributions built on a different C library such as Alpine Linux, and minimal container images that ship no system libraries at all. The new binaries remain position-independent executables, preserving the ASLR exploit mitigation of current releases, and are only about 1 MB larger.

  The mailing list post continues years of work in Bitcoin Core #25573, which Ford opened in 2022. Progress required changes to the GCC compiler and to glibc itself, including fixes to glibc’s name resolution code, historically the main hazard of statically linking glibc. Some preparatory changes to the Guix build process (see Bitcoin Core #35537) have been merged, but the main PR remains open and under review. Readers who run Bitcoin Core on Linux are encouraged to try the test binaries and report any problems, or successes, to the mailing list or the PR.

• ● Replacing per-peer transaction rate-limiting with global rate limits: Anthony Towns posted to Delving Bitcoin announcing the merge of Bitcoin Core #34628, which replaces the per-peer transaction rate-limiting with a global approach.

  For each of its peers, a node keeps a queue of the transaction announcements it intends to send to that peer, called m_tx_inventory_to_send, sorts those announcements by ancestor feerate, and sends the best of them first. To limit bandwidth and to make it harder to probe the relay topology, a node announces no more than about 7 transactions per second to each peer. In normal times this rate is enough to drain the queue, but a sudden burst of transactions can fill it faster than the limit lets it drain. Because the node re-sorts the growing queue on every announcement, this can consume an excessive amount of CPU, a denial-of-service (DoS) vector previously described in Newsletter #324.

  Towns’ PR replaces the per-peer rate-limiting with a global rate limit, using two token buckets that meter total announcements by count (number of transactions) and by size (serialized witness size). If there is enough capacity, an incoming transaction is relayed immediately, otherwise it is added to a single global backlog sorted by feerate and cluster mempool rules. Transactions selected from that backlog are then placed in a small per-peer queue used for privacy batching. Sorting one shared backlog instead of a separate queue per peer avoids the repeated per-peer sorting that made the original design a DoS vector.

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.

• ● BTCPay Server 2.4.2 is a security release that fixes a critical vulnerability affecting all releases before 2.4.2. An unauthenticated remote attacker could obtain an LND node’s .macaroon credential files and use them to take control of the node and move funds. The project reports that the vulnerability was exploited and funds were stolen. BTCPay Server operators using LND should update to 2.4.2 and LND 0.21.1 immediately, audit their node for unauthorized activity, and rotate their macaroon credentials, since an attacker may have already obtained them. BTCPay Server’s onchain wallets and deployments using other Lightning implementations are not exposed to this specific risk.

• ● LND v0.21.2-beta is a maintenance release of this popular LN node implementation. It fixes two database migration failures, bounds memory usage during channel graph synchronization, and fixes bugs affecting onion messages, RBF cooperative closes, invoice updates, blinded-payment forwarding, and HTLC resolution.

• ● LND v0.20.3-beta is a maintenance release of LND’s 0.20 release branch. It backports several fixes also included in 0.21.2-beta, including bounds on memory use during channel graph synchronization and fixes for cooperative closes, invoice updates, blinded-payment forwarding, and HTLC resolution.

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 #35493 fixes a false warning that indicated private keys were missing when importing MuSig2 descriptors (see Newsletter #366) with all the required private keys. Previously, the importdescriptors RPC checked for a corresponding private key for every public key produced when expanding the descriptor, including the MuSig aggregate key, which doesn’t have a standalone private key. This could cause a descriptor containing all of its participants’ private keys to be reported as incomplete. The completeness check now accounts for MuSig participant keys, so complete descriptors import without a warning, while those missing participant private keys still trigger a warning.

• ● Core Lightning #9150 introduces impressions, a new type of liquidity information that records successful payments through a channel and allows the askrene RPC command (see Newsletter #316) to adjust its liquidity estimates for subsequent routing attempts. Additionally, the getroutes RPC command is updated to provide more specific error messages when routing fails, such as when the source has insufficient funds or the destination has insufficient incoming capacity. Also, the PR limits invoices generated from BOLT12 offers denominated in another currency to a 10-minute expiry by default to account for exchange rate fluctuations.

• ● BIPs #2248 updates BIP3 to remove Luke Dashjr from the list of BIP editors, following discussion on the Bitcoin-Dev mailing list. See Newsletter #299 for previous coverage of the editor set.

• ● BIPs #2225 and #2245 update BIP110 (see Newsletter #412) following its unsuccessful activation attempt. #2245 changes its status to Closed. #2225 makes BIP433’s policy rule requiring pay-to-anchor (P2A) spends to carry an empty witness stack into a consensus requirement.

• ● Eclair #3346 fixes a crash and makes several onchain and channel-handling improvements. It now verifies that decrypted payment failures correspond to a valid intermediate position in the payment route before using them as routing information, preventing malformed or maliciously crafted failures from the recipient from triggering an out-of-bounds access that could crash the payment lifecycle actor. It also starts retrying onchain transaction broadcasts when it receives error messages from Bitcoin Core it can’t classify, instead of potentially abandoning a time-sensitive transaction. When using CPFP to fee-bump a peer’s zero-fee commitment, it now accounts for the full parent-and-child package weight instead of only the parent’s weight. Finally, Eclair now uses the MuSig2 nonce associated with the funding RBF attempt that actually confirmed when sending channel_ready, instead of assuming that its latest RBF attempt is the one that confirmed.

• ● Eclair #3341 prepares to relay future channel_update gossip messages that use currently undefined message_flags or channel_flags in BOLT7. Previously, if Eclair received an update with an unknown flag bit set to one, it would discard that value and encode the bit as zero when forwarding the update. This modified the signed message and invalidated its signature. Now, Eclair preserves unknown flag values when decoding and re-encoding channel_update messages, allowing Eclair nodes to relay updates containing flags they don’t yet understand.

• ● LND #11019 fixes a data race in the legacy cooperative-close state machine, which could occur when the link goroutine (which tracks the channel’s HTLC and commitment state) and the peer goroutine (which processes close messages from the remote peer) advance concurrently. Now, instead of advancing the closer itself, the link reports to the peer’s channel manager when a channel has been flushed (pending HTLCs have been drained), ensuring that all close state-machine transitions run on a single goroutine. The PR also ensures that the RBF cooperative-close path (see Newsletter #347) checks that the peer’s delivery script is present and uses an accepted output type, even when no upfront shutdown script was negotiated (see Newsletter #76).

• ● LND #11023 changes update_fee handling to match BOLT2’s replaceable-state model and prevent redundant uncommitted fee updates from growing the update log. If a newer fee update arrives before the previous one has been included in either party’s commitment transaction, LND now replaces the previous fee value in place. The PR also limits channel mailboxes to 1,000 queued messages and 4 MiB of serialized data. If a message cannot be accepted, LND disconnects the peer instead of dropping the message and processing subsequent messages out of order. This allows the ordered channel state to be recovered upon reconnection.

• ● Libsecp256k1 #1904 strengthens the startup self-test for applications that provide their own SHA256 compression function (see Newsletter #396). Previously, the self-test hashed a single 63-byte message, which could detect general incorrect implementations but not ones that failed when processing multiple blocks, unaligned input, or a SHA256 state other than the initial one. The new test uses different message lengths and input alignments. It rejects a supplied compression function if its results differ from the expected SHA256 results, allowing faulty implementations to be detected during initialization rather than producing incorrect results later.

• ● HWI #839 fixes several PSBT parsing and transaction reconstruction issues that were revealed when adding the complete BIP174 and BIP370 test-vector suites. When reconstructing a transaction from PSBTv2, HWI now applies the computed locktime instead of leaving it at zero and uses the specified final sequence value (0xffffffff) when an input omits PSBT_IN_SEQUENCE. For PSBTv0, HWI rejects v2-only input and output fields and strictly parses the global unsigned transaction using non-witness serialization, while correctly recognizing an empty unsigned transaction as present. The PR also validates that required height and time-based locktimes fall within their specified ranges and adds tests for BIP370 locktime determination.

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