Bitcoin Optech

Bitcoin Optech Newsletter #422 Recap Podcast

2026-09-15T00:00:00+00:00

Mark “Murch” Erhardt and Mike Schmidt are joined by Adam Gibson and Rob Segers to discuss Newsletter #422.

The Bitcoin Optech Podcast and transcription content is licensed Creative Commons CC BY-SA 2.0

Download audio

News

● A protocol for probabilistic coinjoin and covert betting (1:14)
● Update on silent payments light clients (43:26)

Releases and release candidates

● LDK v0.3-rc1 (1:04:06)
● LDK v0.2.6 (1:05:58)
● BTCPay Server 2.4.4 (1:07:44)

Notable code and documentation changes

● Bitcoin Core #35949 (1:13:04)
● Bitcoin Core #34931 (1:15:11)
● Bitcoin Core #36048 (1:18:14)
● Bitcoin Core #36123 (1:21:12)
● Bitcoin Core #36176 (1:22:32)
● Core Lightning #9434 (1:24:49)
● LND #11061 (1:26:29)
● LND #11125 (1:27:23)
● LND #11064 (1:28:33)
● BTCPay Server #7561 (1:29:31)
● BTCPay Server #7559 (1:31:03)

Transcription

transcription coming soon

Bitcoin Optech Newsletter #422

2026-09-11T00:00:00+00:00

This week’s newsletter describes a proposed protocol for probabilistic coinjoins disguised as covert bets and summarizes benchmarks of a silent payments indexing server against compact block filters for light clients. Also included are our regular sections announcing new releases and release candidates and describing notable changes to popular Bitcoin infrastructure software.

News

● A protocol for probabilistic coinjoin and covert betting: Adam Gibson posted to Delving Bitcoin about Babilonia, a proposal for a new probabilistic coinjoin and covert betting protocol. The idea behind the proposal is to provide privacy-seeking behavior with plausible deniability. Instead of recognizable actions, which can be tracked, flagged, and criminalized, Gibson proposes a covert betting protocol, where users participate in order to break the common input ownership heuristic. The bet resembles an onchain coin flip where money changes hands, but to the outside looks like a normal payment.

The protocol, described in a paper, works like this:
- Alice and Bob provide their inputs to build a shared UTXO. They also sign a refund transaction, that gives the funds back to the owners in case of a long timeout, and a payout transaction, to settle the bet.
- Alice generates two secret numbers a_1 and a_2, picking one as her choice, and publishes the corresponding public keys A_1 and A_2.
- Bob picks one as his guess and constructs a public key K that can only be spent in case his and Alice’s choices are the same.
- The payout transaction sends the funds to an output spendable by K. Alice signs that transaction with a partial adaptor signature. After Bob signs with his partial signature and the funding transaction confirms, Alice provides the adaptor’s hidden secret out-of-band, letting Bob decrypt her chosen number. If he won, he completes and broadcasts the payout transaction to claim the funds.
According to the author, multiple rounds of the protocol would statistically allow users to maintain their initial funds, minus fees, while improving their privacy. This is true on average, but may deviate for individual users. However, in the paper Gibson states that there is still no clear measure of the actual efficacy of the protocol. In a follow-up post, Gibson noted that a single bet leaks its size, since the winner’s payout is an integer multiple of their contribution to the pot, and released a second version of the paper that splits each bet into several unequal sub-bets.
● Update on silent payments light clients: Rob Segers posted to the Bitcoin-Dev mailing list about updates to an older discussion on Delving Bitcoin (see Newsletter #305). That discussion, that stalled in June 2024, was focused on providing specifications for silent payments light clients and measuring performance of different ways to retrieve data from blocks.

Segers ran an instance of BlindBit Oracle v2, an implementation of the BIP352 indexing server which drops filters completely and instead streams per-output data (txid, tweak, and 8-byte output prefix), and compared its performance against BIP158 compact block filters and taproot-only filters. The comparison was done on unsampled block data from taproot activation until block 965,089 (a total of 255,434 blocks). Results show that the BlindBit Oracle approach downloads about 2.1x as many bytes as a taproot-only filter plus the raw tweak data a filter client still needs, not counting the full block a filter client must fetch on each match, in exchange for no false positives and no per-match block fetches.

Segers also noted that a light client currently cannot tell whether a server omitted a tweak for a block, which would silently lose the receiver money. His server publishes per-block commitments over the sorted tweak set and checkpoints them to nostr every six hours, making omissions attributable after the fact, although clients should still fetch the full block on a match.

Finally, Segers noted that the new version of the BlindBit Oracle had drifted severely from the original specifications. Thus, the author provided a convergence draft which is up for discussion.

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.

● LDK v0.3-rc1 is a release candidate for the next major version of this library for building LN-enabled wallets and applications. It adds RBF fee bumping for pending splices and support for adding and removing funds in the same splice. It also negotiates anchor channels by default and requires applications to explicitly accept incoming channels. Upgrading invalidates previously issued BOLT11 invoices containing payment metadata. Developers should review the API and backwards-compatibility changes before testing.
● LDK v0.2.6 is a security release of this library for building LN-enabled wallets and applications. It fixes a denial-of-service vulnerability in which an invalid payment, rejected after a second HTLC with the same payment hash was successfully forwarded, could leave the channel manager in a state that fails to deserialize. It also fixes a fee-inflation vulnerability that allowed a malicious counterparty to make a node over-allocate fees when contributing to a splice it initiated, with the excess going to the counterparty’s output.
● BTCPay Server 2.4.4 is a security release of this self-hosted payment processor. It deletes legacy BitPay Basic-auth API keys and removes that authentication method, requiring affected integrations to migrate to supported authentication. Existing Greenfield API keys continue to work. The release also requires authorization to change invoice states, prevents restricted API keys from creating unrestricted keys, and includes the API-key storage changes described below. The accompanying Docker updates restrict host-management access, replace LND’s shared default wallet password with unique passwords, and block LND’s unauthenticated wallet-management routes at the reverse proxy. These LND changes address observed probing of LND’s unauthenticated password-change endpoint on servers where operators had re-exposed the LND API after the 2.4.2 incident (see Newsletter #418). Operators who did so should remove that access. All server administrators are encouraged to upgrade and review the breaking changes. For the web-hosting billing plugin, migration requires upgrading to version 4.0.0 and replacing the legacy API key with a new Greenfield API key; see its migration guide.

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 #35949 updates block template creation to follow BIP54’s proposed mitigation for the Murch–Zawy time warp attack (see Newsletter #316). For the last block of each 2,016-block difficulty period, the minimum timestamp must be at least that of the period’s first block. Previously, if the node’s clock was behind the period’s first block, the proposed timestamp could also be earlier, provided it exceeded the median timestamp of the previous 11 blocks. The getblocktemplate RPC now adjusts both mintime and the proposed curtime when necessary, including when the node’s clock is behind this minimum. This applies to all networks in preparation for the possible activation of the consensus cleanup soft fork, without changing consensus validation.
● Bitcoin Core #34931 fixes a bug where a UTXO database entry that could not be deserialized was treated as a missing coin. Consequently, a valid block spending the unreadable coin could be permanently marked as invalid, which would leave the affected node unable to follow the network’s best chain. Bitcoin Core now distinguishes between these outcomes and aborts with a database error when deserialization fails. An additional coin serialization bug or memory corruption before storage would be required for this bug to occur, since LevelDB’s checksums already detect ordinary disk corruption.
● Bitcoin Core #36048 fixes command injection through the -walletnotify configuration option (see Newsletter #86) on non-Windows systems. An authenticated RPC caller could create a wallet with a crafted name using the createwallet command. If the operator configured the -walletnotify option with the wallet name placeholder, %w, subsequent transaction notifications for that wallet could execute commands embedded in the wallet name on the node’s operating system. Although the wallet name was shell escaped, the substitution function interpreted the regular expression replacement characters within it, breaking the shell quoting. Placeholder substitution now treats wallet names literally, preserving the shell escaping. This behavior was introduced in Bitcoin Core 24.0.
● Bitcoin Core #36123 and #36169 fix unbounded memory growth and Windows port sharing in the replacement HTTP server (see Newsletters #411 and #420). The first prevents a client from growing the server’s per-connection receive buffer indefinitely by sending requests faster than the server can process them. Socket reads now pause when buffered requests await processing, allowing TCP backpressure to slow the sender. The second PR reserves the address and port exclusively for Windows listening sockets. Previously, another local process could bind the same endpoint and potentially receive connections containing RPC credentials. In one reviewer’s test, sixteen REST connections increased memory usage by 3.2 GB before the buffering fix and only 3 MB afterward over 90 seconds.
● Bitcoin Core #36176 fixes an error that occurs when a wallet operation attempts to save its load-on-startup preference while the dynamic settings file is disabled with the -nosettings option. When creating, loading, or unloading a wallet, users can also specify whether it should be loaded automatically at the next startup (see Newsletter #111). Previously, attempting to save this preference with settings disabled produced an RPC error or caused Bitcoin-Qt to crash with an uncaught exception after the wallet state had already changed. Now, the operation completes with a warning that the preference could not be saved.
● Core Lightning #9434 and #9473 fix crashes involving persistent routing preferences in askrene (see Newsletter #316). askrene stores routing information in layers, which can include biases favoring or discouraging particular nodes or channels (see Newsletter #381). The first PR fixes a startup crash when restoring a node bias with a description from a persistent layer. Restoring the incoming and outgoing bias values reused the description buffer after it had been freed, causing askrene to crash and lightningd to shut down because it treats askrene as an important plugin. The second fixes a crash when removing channel or node biases by resetting them to zero. Previously, the zero-valued bias record was removed from memory before being saved, causing a null pointer dereference. Now, the zero value is saved before the record is removed from memory, preventing the previous bias from being restored after a restart.
● LND #11061 continues the implementation of BOLT12 offers by adding support for signing and verifying invoice requests and invoices using BIP340 Schnorr signatures. The signatures commit to a Merkle root constructed from the messages’ signed TLV records. Read validators now reject invalid signatures rather than only checking that a signature is present. This builds on the invoice request codec described in Newsletter #413.
● LND #11125 allows callers to reserve wallet UTXOs until the transaction spending them reaches a chosen number of confirmations. Previously, reservations either expired after a specified time or were removed at the first confirmation of the spending transaction. Slow confirmations could therefore outlast the reservation, while a reorg could leave the inputs unreserved. Now, the LeaseOutput (see Newsletter #182) and FundPsbt RPCs accept a confirmation count, allowing reservations to remain active across reorgs and ignore time-based expiration. Callers can still release reservations explicitly, which is required if a transaction is abandoned. Existing timed reservations remain the default.
● LND #11064 makes channel opening messages explicitly specify the channel type, as required by BOLT2. LND now includes channel_type in open_channel, echoes it in accept_channel, and rejects incoming open_channel messages that omit it. RPC callers can still omit a type, in which case LND chooses one based on both peers’ supported channel types.
● BTCPay Server #7561 and #7542 update how API keys are stored and handled. The first PR stores hashes and derived key IDs instead of storing plaintext credentials in the database indefinitely. A cleanup job clears newly created plaintext secrets once they are more than five minutes old. After migration, existing Greenfield keys continue to authenticate, but their secrets can no longer be retrieved from the server. The upgrade also deletes legacy BitPay-like Basic-auth API keys and removes that authentication method. Revoking a specified API key now requires its ID instead of its secret and key responses include an id field. The second PR removes the newly generated API key from the redirect URL to the API key management page, preventing the URL from exposing credentials through browser history or request logs.
● BTCPay Server #7559 extends Lightning payment monitoring beyond a BTCPay invoice’s payment deadline, through its configured monitoring period. Previously, a customer could pay a Lightning invoice after the BTCPay invoice expired, but BTCPay would not record the payment. Now, the listener uses the existing monitoring period, allowing late payments received during that period to be recorded. This does not change the payment deadline for either invoice or detect payments indefinitely.

Bitcoin Optech Newsletter #421 Recap Podcast

2026-09-08T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by average_gary, Erick Cestari, Conduition, and Greg Sanders to discuss Newsletter #421.

The Bitcoin Optech Podcast and transcription content is licensed Creative Commons CC BY-SA 2.0

Download audio

News

● Using silent payments for miner payouts in coinbase transaction (2:19)
● Responsible disclosure of a denial-of-service vulnerability in CLN (27:42)

Changing consensus

● Continued discussion of PQC output types (54:03)
● DropKick commit/reveal PQC rescue (1:14:08)
● SHRINCS draft BIP (1:35:48)
● BIP448 and CSFS/CTV demos and applications (37:55)

Releases and release candidates

● Core Lightning 26.06.7 (1:51:35)
● LND v0.21.3-beta (1:55:32)
● LND v0.20.4-beta (1:55:37)

Notable code and documentation changes

● Bitcoin Core #36111 (1:58:21)
● Bitcoin Core #36032 (2:01:17)
● Core Lightning #9435 (2:04:52)
● Eclair #3368 (2:08:10)
● Eclair #3366 (2:10:54)
● LND #11090 (2:14:55)
● LND #11140 (2:20:33)
● HWI #792 (2:23:55)
● BDK #2262 (2:25:48)

Transcription

transcription coming soon

Bitcoin Optech Newsletter #421

2026-09-04T00:00:00+00:00

This week’s newsletter describes an idea for pools to pay miners using silent payments in the coinbase transaction and summarizes the responsible disclosure of a denial-of-service vulnerability affecting older versions of Core Lightning. Also included are our regular sections summarizing proposals and discussion about changing Bitcoin’s consensus rules, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

● Using silent payments for miner payouts in coinbase transaction: average_gary posted to Delving Bitcoin about his idea for how pools could pay miners to different addresses directly in the coinbase transaction. Instead of providing an xpub to the pool to derive a fresh address for each payout, which could result in privacy issues if the pool’s database gets compromised, a miner could share a silent payment address, which is static and can be used several times without privacy leaks, through the encrypted communication channel provided by Stratum v2.

For BIP352 silent payments, the receiver derives the shared secret from the transaction’s input public keys, which a coinbase transaction does not have. The pool can create an ephemeral private key to be used to derive the sending public key A_send. To prevent the pool from grinding a malicious a_send private key, A_send is hashed with the height of the block being mined, which replaces the outpoint-derived uniqueness. The 34-byte A_send is finally included in the coinbase scriptSig replacing the so-called pool tag, so that the miner can scan the chain for the funds.

The author is looking for feedback and critiques on the proposed idea, so that it can be formalized into a real specification.
● Responsible disclosure of a denial-of-service vulnerability in CLN: Erick Cestari posted to Delving Bitcoin the responsible disclosure of a critical denial-of-service (DoS) vulnerability affecting CLN nodes running versions prior to 25.09. An attacker would have been able to flood a node with ping messages asking for the largest possible pong reply and never read the TCP socket, causing an out-of-memory (OOM) crash, needing only to complete the BOLT8 handshake, without a channel.

The issue was linked to the way CLN manages its connections. Each peer opens a BOLT8 encrypted Noise channel with the node and the connection is managed by a specific daemon, connectd. The daemon handles the TCP connection, decrypts the incoming messages, and routes them to the specific subdaemon managing a payment channel with the sending peer. However, there are some messages that are taken care of locally by the daemon. One of them is the ping message and the sender gets to pick the size of the pong reply.

While CLN applies a backpressure mechanism to the messages routed to the subdaemons, with connectd waiting for them to be ready before reading a new message, that did not apply to the daemon itself, which would continue to read the locally handled messages. An attacker would have been able to repeatedly send ping messages requesting a reply of the maximum allowed size of 65531 bytes and never read the answer, thus filling its TCP socket buffer first, then the peer’s. This would have prevented the peer_outq queue from draining, leading to the OOM crash.

The issue was fixed by providing the connectd daemon with its own backpressure mechanism, activated by the peer_outq queue actually draining before reading the next incoming message. The fix was introduced in Core Lightning #8525 and published in release 25.09.

Changing consensus

A monthly section summarizing proposals and discussion about changing Bitcoin’s consensus rules.

● Continued discussion of PQC output types: Following last month’s summary of Pieter Wuille’s Delving Bitcoin thread on post-quantum output types, Wuille replied to Conduition’s argument that pairing CISA with P2TRv2 would strongly incentivize migration. Wuille was not convinced that feerate savings, which he put at a maximum weight reduction of about 28% and only for transactions with many inputs, would move the long tail: wallet and custodian support is the bottleneck, CISA adds specification and implementation complexity that may delay a P2TRv2 soft fork, and entities might postpone any PQC work until they can ship P2TRv2 and CISA together. He still prefers P2TRv2 as a default for casual users and P2MR for more sophisticated users who want to hide EC points, and noted that post-Q-day hash-based signatures likely need a new witness costing rule that weighs CPU more and serialized size less (see Newsletter #417). He also cautioned that having third-party relay nodes incrementally aggregate signatures would hide the real bandwidth cost within the consensus layer and could entrench existing mining pools by incentivizing direct submission to miners. Conduition countered that a CISA supporting output type can be adopted first with ordinary BIP340 signatures and aggregation added later, and that an 8x (or larger) serialized block-size increase to make hash-based signatures fee-competitive with EC would push archival storage into terabytes per year unless block-wide SNARK aggregation can prune witnesses. Adam Gibson agreed with Wuille that bundling CISA into P2TRv2 is a poor fit for P2TRv2’s adoption-first goal.
● DropKick commit/reveal PQC rescue: Conduition posted to the Bitcoin-Dev mailing list a sketch of DropKick, a commit/reveal post-quantum rescue protocol (see also Newsletter #361 and Newsletter #348) for users who have not moved coins to PQC-enabled outputs by Q-day. A user hides a commitment to their post-quantum public key and ownership witness (proof of knowledge asymmetry) somewhere in a block (for example in an OP_RETURN or a taproot tweak). Users without a PQ-safe UTXO of their own can hand their commitments to untrusted aggregators, who merkle-commit many users’ commitments under a single onchain root, optionally for a fee paid from the rescued coins. After a delay, they reveal the proof, a signature from their post-quantum public key, and an SPV-style opening proof that the commitment appeared in an earlier block. DropKick can be deployed as a non-confiscatory soft fork if it encumbers only UTXOs with decidable knowledge asymmetries, where validators can tell from the output alone that hidden data such as a hashed pubkey exists. Covering undecidable cases such as BIP32 key derivation would rescue more coins but could confiscate some. P2PK coins cannot be covered. Compared with Tadge Dryja’s Lifeboat, which requires each user to have a PQ-secure UTXO to post a commitment, DropKick drops the requirement to index and order every onchain commitment, at the cost of miner-censorship risk on the reveal: Conduition argues a long delay (about 100 blocks if users will pay 1% of the UTXO to honest miners) plus a value-proportional fee can make censorship unprofitable, assuming that the censors are not capable or unwilling to reorganize out blocks that undermine the censorship attempt.
● SHRINCS draft BIP: Conduition posted to the Bitcoin-Dev mailing list, on behalf of the SHRINCS working group, a first draft specifying SHRINCS as a semi-stateful hash-based signature scheme for Bitcoin (see Newsletter #391). Public keys are 48 bytes. Stateful signatures are 548 bytes at the smallest; a built-in stateless fallback produces 5,777-byte signatures (the draft raises the stateless budget to 2^40 signatures so high-frequency protocols such as LN can use the fallback). Verification is 4x-16x faster per byte than BIP340 schnorr with SHA256 hardware acceleration, or at worst 2,792 SHA256 compressions for a stateless signature. Notable changes since the original proposal include black-box SLH-DSA (FIPS-205) compatibility, flexible XMSS trees of any structure, and faster (larger) stateful parameters. The draft specifies only a signature scheme; deployment of the new signatures per new opcodes or a new output type would be subject of a separate proposal. Reusing a stateful counter lets an observer forge signatures. Antoine Riard noted that 5,777-byte stateless signatures would be roughly 90x the onchain cost of today’s transactions unless those fields are discounted. Jonas Nick and remix7531’s libshrincs C library with machine-checked WOTS+C proofs was also separately released to provide implementation support for those wishing to integrate SHRINCS.
● BIP448 and CSFS/CTV demos and applications: Work around BIP448 (the tapscript bundle of OP_TEMPLATEHASH, OP_CHECKSIGFROMSTACK (CSFS), and OP_INTERNALKEY; see Newsletter #397) continues with new sites aggregating demos, implementations, and proofs of concept. A BIP448 GitHub organization collects implementations (Bitcoin Inquisition, a Bitcoin Core patch without activation, miniscript and PSBT integration, draft LN-Symmetry BOLTs and Core Lightning implementation, and an Ark OP_TEMPLATEHASH signet demo). The organization notes that the full bundle will be usable on the default signet with the next Bitcoin Inquisition release. askii21m announced covenants.diy, a browser editor that builds taproot outputs and steps through tapscript under selectable opcode sets, with permalinked examples including BIP448 rebindable state, BIP119 vaults and congestion control, and BIP348 delegation. Jesus Najera (setzeus) of Cofund published an interactive Covenants Use-Case Atlas of more than two dozen constructions, including vaults, congestion control, Ark issuance, and LN-Symmetry.

Ademan posted a related construction for Ark out-of-round (OOR) virtual transaction output (VTXO) assignments used to open small just-in-time (JIT) Lightning channels. Because the Ark server is both operator and initial VTXO holder, it can currently reassign the same VTXO many times. Ademan’s equivocation bond is slashable by publishing two CSFS-validated signatures from the assignment key over distinct BIP341 sighashes. The bond and the preallocated transaction tree need a next-transaction covenant, which can be either OP_CHECKTEMPLATEVERIFY (CTV) or OP_TEMPLATEHASH.

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.

● Core Lightning 26.06.7 is a security release for the current major version of this popular LN node implementation. It fixes several responsibly disclosed vulnerabilities, none of which are known to be actively exploited, reported by researchers including Erick Cestari, whose earlier disclosure is described in the news section above. The project strongly encourages all users to upgrade. As described in Newsletter #420, the source code is being withheld for 14 days after the August 28 binary release to slow attackers from reverse engineering the fixes. After that, CLN’s reproducible builds will allow users to verify the binaries. Between August 28 and September 1, Docker users who pulled the v26.06.7 or latest tags received images that reported the new version but did not contain the fixes. These users should check their image digest and re-pull.
● LND v0.21.3-beta is a maintenance release of this popular LN node implementation. It includes the peer resource limits, channel_update encoding fix, and dust HTLC resolution fix described in the notable code section below, as well as the PSBT funding deadlock fix from Newsletter #420. It also fixes a cooperative close fee bug for channels with auxiliary outputs such as Taproot Assets channels, a native SQL invoice migration failure for legacy AMP invoices, a REST WebSocket proxy panic, and several gossip query and cooperative close bugs, and adds the experimental XCreateAccount RPC (see Newsletter #419).
● LND v0.20.4-beta is a maintenance release of LND’s 0.20 release branch. It backports most of the fixes in 0.21.3-beta, including the peer resource limits, channel_update encoding fix, and dust HTLC resolution fix, and additionally rejects fixed-size TLV records such as inbound fees and MuSig2 nonces whose declared length is incorrect, instead of silently accepting and re-encoding them.

Notable code and documentation changes

● Bitcoin Core #36111 limits the memory used by the validateaddress RPC when reporting errors for overly long bech32 strings. Previously, for strings exceeding the 90-character limit set by BIP173, every position past the limit was returned as an error location (see Newsletter #177) and converted into a separate JSON value. Now, the RPC returns only position 90, where the length violation begins. In the author’s tests, an authenticated request near the maximum HTTP request size used approximately 5.7 GiB of memory before the change and 240 MiB after.
● Bitcoin Core #36032 improves the performance of createrawtransaction, createpsbt, sendmany, and other RPCs that build a transaction by making output parsing linear instead of quadratic. Previously, the parser iterated through the output keys and separately looked up each corresponding value individually, rescanning the same internal list each time. In addition, sendmany held the wallet lock while parsing. Now, the parser walks through the keys and values together by index, similar to the gettxspendingprevout fix in Newsletter #419. The author reports that parsing 10,000 outputs in a debug build now takes 0.5 seconds instead of 1.8 seconds.
● Core Lightning #9435 updates CLN to force close a channel when a peer sends a channel_reestablish message with a next_commitment_number of zero, as required by BOLT2. A value of zero indicates that the peer has lost its channel state, and broadcasting the latest commitment transaction lets it recover its balance using a static channel backup. Previously, CLN only enforced this on a freshly opened channel. For any other channel, CLN first detected the peer’s stale next_revocation_number, sent a warning, and left the channel open.
● Eclair #3368 fixes a bug where a commitment_signed message received from a peer on a non-taproot channel could carry the partial_signature_with_nonce TLV used by simple taproot channels for their MuSig2 partial signatures (see Newsletter #404). Although Eclair correctly verified the message’s regular ECDSA signature, it incorrectly stored the unsolicited partial signature as the peer’s signature. This prevented Eclair from force closing the channel later on. Now, Eclair selects the signature type that matches the channel’s commitment format before verification and only stores the verified signature.
● Eclair #3366 hardens splicing against peers that don’t follow the specification. Eclair now disconnects a peer that sends channel updates after its own stfu quiescence message, or that sends a commitment_signed message while the splice is still being negotiated. Eclair force closes instead of accepting if a peer attempts to advance the channel’s existing commitment while the splice is being signed. It also refuses to complete a splice or dual funding RBF attempt whose commitment numbers no longer match the channel’s. Finally, when a splice in which Eclair sells liquidity through liquidity advertisements is aborted after signing begins, Eclair now immediately fails the incoming HTLCs paying for it (see Newsletter #379 for a related fix).
● LND #11090 rate limits inbound ping messages and caps each peer’s outgoing message queue, preventing the kind of resource exhaustion described for CLN in the news section above. For each peer connection, LND now maintains two token buckets. The inbound ping request bucket starts with 200 tokens and replenishes at a rate of 10 per second. Exhausting this bucket results in the peer getting disconnected. The outbound pong reply bucket starts with 20 tokens and replenishes at a rate of one per second. Exhausting this bucket causes LND to stop replying, which is a deliberate deviation from BOLT1. Each peer’s outgoing queue is also capped at 10,000 messages or approximately 16 MiB. Additionally, the PR fixes the encoding of channel_update gossip messages so that LND’s own updates advertising inbound fees are signed over exactly the bytes it broadcasts. Previously, these bytes could differ, causing peers to reject the update. Updates that LND forwards from other nodes now also keep any TLV records it doesn’t recognize, rather than dropping them and invalidating the originator’s signature (see Newsletter #418 for a similar Eclair fix).
● LND #11140 fixes how LND handles a forwarded HTLC when the outgoing channel force closes and the HTLC is trimmed as dust on one party’s commitment transaction but not the other’s. Previously, if the HTLC had an output on LND’s commitment but the peer’s commitment confirmed without one, LND never failed the incoming HTLC back, because it had judged the HTLC based on its own commitment. The incoming HTLC would then stay pending until the upstream channel force closed near its expiry. Now, LND decides based on the commitment that actually confirmed. LND also no longer fails an incoming HTLC early when the outgoing HTLC is dust on its commitment but has an output on the peer’s commitment, since the peer could still claim the output with the preimage.
● HWI #792 adds a --registration option to the signtx command for signing PSBTs using BIP388 wallet policies that were previously registered on a hardware signing device with the registerdescriptor command (see Newsletters #419 and #420). The option accepts the serialized registration returned by registerdescriptor, including the policy name, descriptor, device type, and any device-specific registration data such as Ledger’s HMAC. Support is implemented for BitBox02, Coldcard Edge, Jade, and non-legacy Ledger devices.
● BDK #2262 fixes a bug where reindexing a wallet’s transaction graph could miss some of the wallet’s own outputs. BDK’s KeychainTxOutIndex watches a look-ahead window of addresses beyond the highest BIP32 derivation index it has seen, extending the window each time an output at a higher index is found. Previously, reindexing examined each output only once, so an output beyond the current window was deemed not to belong to the wallet and was never reexamined, even after a later output extended the window. Since outputs were examined in a random order, the same wallet could show different balances on different runs. Reindexing now repeats the process until the window stops extending.

Bitcoin Optech Newsletter #420 Recap Podcast

2026-09-01T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Níckolas Goline, Optout, Abubakar Sadiq Ismail, and Moonsettler to discuss Newsletter #420.

The Bitcoin Optech Podcast and transcription content is licensed Creative Commons CC BY-SA 2.0

Download audio

Action items

● Prepare for an upcoming Core Lightning security release (1:46)

News

● Discussion on universal opt-in replay protection (53:54)
● HWI repository to enter maintenance mode (1:24:05)
● Request for comments on using block-range filters (19:06)

Releases and release candidates

● BTCPay Server 2.4.3 (1:28:31)
● Eclair 0.14.2 (1:29:09)

Notable code and documentation changes

● Bitcoin Core #34075 (31:21)
● Bitcoin Core #35730 (1:32:02)
● Bitcoin Core #35580 (1:34:03)
● Bitcoin Core #35665 (1:38:36)
● Bitcoin Core #35933 (1:43:02)
● Core Lightning #9374 (1:45:58)
● Eclair #3342 (1:47:15)
● Eclair #3321 (1:48:55)
● LND #11008 (1:50:44)
● HWI #841 (1:52:09)
● HWI #849 (1:53:48)
● Rust Bitcoin #6755 (1:55:12)

Transcription

Mike Schmidt: Welcome everyone to Bitcoin Optech Newsletter #420 Recap. This week, we’re going to be talking about the Core Lightning (CLN) security release action item, and we have News items covering replay protection for future soft forks; we have the announcement of HWI repo entering maintenance mode; there’s a discussion on block-range filters for light clients. And then, we also have Sadiq, who’s going to talk about one of our Bitcoin Core PRs a little bit later, amongst some other Releases and Notable codes segment items. This week, Murch, Gustavo, and I are joined by a few different guests. We’ll let them introduce themselves. Níckolas?

Níckolas Goline: Hey, Níckolas, I work at Core Lightning. I’m the lead maintainer. After Rusty left Lightning, I stepped in to take care of the releases, and whatnot. I’ve been working on the Bitcoin industry for 12 years now, exchanges and open-source projects, and I used to have a C# implementation of the Lightning Network, called NLightning. I lost funds and I joined Core Lightning to keep the work going.

Mike Schmidt: Excellent. Thanks for joining. Optout?

Optout: Yeah, hello, I’m Optout and I’m an aspiring Bitcoin Core contributor.

Mike Schmidt: Excellent, thanks for joining. And Sadiq?

Abubakar Sadiq Ismail: Hi, I am Abubakar Sadiq, I contribute to Bitcoin Core, supported by 2140 and Btrust.

Prepare for an upcoming Core Lightning security release

Mike Schmidt: Well, thank you three for joining. We may have a fourth guest joining. We’ll have them introduce themselves when it’s appropriate, but let’s jump into the newsletter and start with the Action item, “Prepare for an upcoming Core Lightning security release”. Níckolas has joined us from Core Lightning. Obviously, this item came out Friday, and we were sort of warning, if you will, or having listeners and readers get ready for the forthcoming release. But maybe, Níckolas, you can let us know what has happened since then, and maybe also what happened before then, and maybe what people should be aware of more broadly.

Níckolas Goline: Sure. I guess everyone is aware of the huge influx of AI security reports. Everyone is getting those, we are no exception for those, and we got a big number of security reports. And it’s been three weeks since we got the first one, just one critical one, but I would say not a big deal, because the exploit is very convoluted, it’s very hard to achieve. So, that’s why we took our time, included more advisories on the list. It was very hard work for the small team we have to sort through the advisories and duplicate them, write fixes, check the fixes from each other, review the code, write tests. It was very hard work we have done. And then finally, last week on Friday morning, we had the release ready. We opted to do a binary-only release this time, because releasing the contents, the source code, would help attackers, at least give them a lead on how to exploit the vulnerabilities. We included a lot of low vulnerabilities and middle, something like this, as well as some public PRs we had open that fix some known bugs, to make it harder for an attacker to pinpoint the changes. And then, the source will come in 14 days since the release, so we are talking about next Friday, not this one, the next one.

To put people at ease, we signed the release, we signed the three, the git tree, all the contents, including tests, documentation changes, and the changes itself. We signed the binaries up front. So, as soon as we have the source ready for release, people will be able to just do the reproducible builds and check that the SHAs match and that we didn’t put anything strange in the release. It comes at a time that we just had a huge issue of COLDCARD, and I know people are very wary of running stuff that they cannot read the code. But then, it actually is a bigger problem because no one is reading changes anyways. So, people are usually running CLN or LND, or other implementations, from Docker images or from the binaries itself. Just a few select people really read the codes and the changelogs, and those people contacted us as well and asked if there’s something they could do. And the message is the same for everyone, it’s a public message, “Update now”. If you cannot update, if you’re not comfortable updating, if you cannot read the source right now, just run the node with –offline. This makes the node not accept incoming HTLCs (Hash Time Locked Contracts). It does not accept new channels, but it keeps an eye on the onchain, what’s happening onchain. So, you cannot get force closed, or someone publishing a node commitment transaction and trying to rob your funds.

So, this is what we have. And this is public as well, but we were running on the internal swaps and other parts of the company on Blockstream. We’ve been running the same release as everyone else. Especially, we run the 26.06.6 until Friday afternoon. So, we didn’t get a special treatment for the company. We were running the same software as everyone else with 5 or 6 bitcoin in the game. So, we are really behind what we told on the public release. It’s not a big deal. And just something that came in, I guess it was yesterday morning. Someone already reverse-engineered the binaries. So, if you really want to see the changes, it’s out there, it’s public, it’s open source. We cannot release what we have because, like I said, documentation changes and the tests give away the whole thing. So, if we try to do something right now and publish, stripping the tests and the documentation, the tree wouldn’t be the same. And then, I guess it generates more questions than it answers. So, if you’re really curious about the changes, it’s public. But yeah, in 14 days, now it’s 11 days, everyone will see what we have done.

If I can just add something more, this was a big learn for us as well. I guess it’s new for open-source projects to do embargo releases like we did. Bitcoin, BTCPay Server did one just a couple of days before we did ours. We already had that in mind, we were going that path. And when we saw Nicolas and his team launch a binary only, it just enforced that we should do the same, thinking about the safety of our users’ coins on the network. And the big learn is that LLM’s AI are very, very ahead of what everyone thought they would be. And it took just a couple of hours for someone to just grab the binaries. We took all the measures to make it harder, but it took a matter of hours for them to just reverse-engineer the binaries. And from the source code they extracted, they could generate the exact same binaries. So, it’s a big learn.

Mark Erhardt: So, maybe let me jump in here with a couple of questions. It sounds like you can confirm that the binaries built by, I think it was a Nirvati or something, I saw a blogpost yesterday, and they said that they disagreed with the approach. The embargo seemed like a bad idea to them. So, they reverse-engineered the source code from the binary, and with the source code, they were able to reproduce the build on Fedora. So, it sounds to me like you can confirm that they did indeed get the right source code. Is that correct?

Níckolas Goline: Yes. And it not me saying that they got the right source code. It’s the sum saying that the SHA sum is the same. So, the binary is the same, so they have the right source code. There’s not much we can do. And I guess this is the big learn we all got from this.

Mark Erhardt: Right, yeah. I think they said that the binaries had been built with the debug statements, and that had helped them a lot with putting it back together.

Níckolas Goline: Yeah, I guess helped them, but we could never stop them doing what they’ve done. I guess LLMs are very good right now, and especially the very expensive ones, it’s just a matter of time. So, the learn here is that we still have a couple of dozen security advisories to go through, and we already have fixes for most of them. Most of them are on the lower end of vulnerabilities, as it goes. So, the next security release will be different. We’ll probably be warning people like, “Tomorrow we’ll have our security release. Please update”. And then, we’ll be building the binaries beforehand, not letting the CI do it because it takes time. So, we will release the source and the binaries together, and people will have to update faster, I guess. They will have to keep track of what’s happening, because everything is moving very fast right now.

Mark Erhardt: Yeah, I think that’s the big takeaway for everyone: (a) embargoes are really difficult with LLMs being able to reconstruct source code much more easily; and (b) a lot of people seemed confused or alienated by the approach of the embargoed release because they felt, “Well, isn’t the whole idea of open-source code that I can see what I run?” So, yeah, I think that was also the recommendation of the blogger that had done the reverse-engineering, was to release source code and binary at the same time, but maybe without a pre-announcement so that people wouldn’t know ahead of time to look; or with pre-announcement so that people know to update. There are just no good solutions really in this day and age with LLMs so quickly catching up on security engineering, and the whole security game changing in a matter of months. So, yeah, if you say you have a couple of dozen more security vulnerabilities, lower-end security issues that will be fixed, it sounds like you got, well, at least a few dozen reports in the past few months. That sounds like a lot of crunch time.

Níckolas Goline: Yeah, there was a lot. I would say we got more than 100 reports. And from that 100, I would say, like, 60%, 70% was duplicates, so they were finding the same vulnerabilities. And most of those were not vulnerabilities, per se. It’s not coins at risk or a DoS risk. It was mostly bugs. We got some vulnerabilities like, “If they have access to your database”. And that’s like, if they have access to your database, you’re doomed, right? So, it’s just a bug, it’s not a vulnerability. So, it got us working a lot to go through all of this. And the team has been very, very good at it as well. I could not ask for a better team to work with, because we went through a lot of code. LLMs, they have the ability to overestimate things, and everything is critical. And every time we got a pack of vulnerabilities from one of the teams, it was, like, 90% critical. And then, it got a lot of effort to go through that, read all the reports, the reproduction steps, and realize it’s just a bug.

Mark Erhardt: Yeah. There’s one thing, that a lot of these LLM reports are incredibly verbose, because they sort of give reproduction steps or someone that’s not familiar with it. And then, on the other hand, I heard from Bitcoin Core contributors as well that a lot of the reports were for odd threat models, sort of like, “You can crash the node when you misuse an RPC”. Well, yeah, but the RPC is only accessible to the node runner, so they’re basically shooting their own node. They can just call bitcoin-cli stop!

Níckolas Goline: That’s true!

Mark Erhardt: Yeah. Well, I’m glad that you were able to rule out a lot of the reports, but I bet that you have been working around the clock.

Níckolas Goline: Yes, for the past three weeks. I guess everyone in the space, I guess since the COLDCARD hack, it opened a door, like the Pandora box. And now, everyone is just dealing with this huge influx of AI-generated stuff. We’ve been getting reports on the security at blockstream.com. But there is just clear text that shows that the person that is filling the reports are not very used to security reports and the whole deal.

Mark Erhardt: You mean they don’t even encrypt the security vulnerability reports?

Níckolas Goline: No, it’s just plain text over Gmail. So, it’s really bad. It shows that AI is running with some MITM proxies, and this gives us a lot of work. But we cannot ask people to not do that, because some of those were real and it helps us at the end of the day. It’s just that we have to upgrade our tooling on our side to be able to move faster to false positives.

Mark Erhardt: But people, at least give your LLM a GPG key so it can encrypt its security reports!

Níckolas Goline: Yes, please!

Mike Schmidt: Níckolas, I know you’ve got to run. Anything that you would leave listeners with? It seems like that would be a good place to leave it is just, everyone’s working on this, look out, update your software, etc.

Níckolas Goline: Yeah, you should really update for the latest version. Right now, it’s 26.06.7 We have the Docker images out for ARM, ARMv7, ARM64, AMD64. We have the binary signed as well if you want to run this yourself. And keep an eye on the official channels, like X and the node runners’ Discord. There’s a Telegram group as well. We are posting on the three separate groups at the same time, so nobody’s left out. And at these crazy times, you just have to be on the lookout for new releases for all the software you’re running, so keep an eye on that. And in the following weeks, we will have a few more security releases.

Mark Erhardt: Sorry, could you repeat where you were be announcing?

Níckolas Goline: It’s the Discord channel for CLN, the Telegram group for node runners, CLN node runners, and official Blockstream X, or Twitter.

Mark Erhardt: Maybe also send an email to the Bitcoin-Developer mailing list for this sort of thing.

Níckolas Goline: Yes, we will.

Mark Erhardt: Thanks.

Mike Schmidt: Níckolas, we appreciate you joining last minute to talk about this. We know you’ve got a lot of things on your plate, it sounds like, and we appreciate you coming to speak directly about this.

Níckolas Goline: Thank you for the space. I’m really grateful to be able to expose our side of the story and why we chose to do what we chose to do. So, thank you. See you around.

Request for comments on using block-range filters

Mike Schmidt: Cheers. We’re going to jump to the News section a little bit out of order. We’re going to go to the item titled, “Request for comments on using block-range filters”. And, Optout, this was motivated by a post from you about light wallets that use compact block filters, being able to download a small filter for every block, and check locally whether any of their addresses might be in it, and then only downloading full blocks on a match. But we want to get into the range aspect. And I know you did some sort of studies on what ranges are appropriate, but maybe to start out, what’s the motivation here, and then you can talk about the range filters?

Optout: Yeah, sure. So, as a general background, I’m interested in any ideas or proposed changes that help the use case when you have a wallet but you don’t have any software running, and you want to get up to speed to see the situation with your wallet. And of course, the full way to do it is you can install and start a Bitcoin Core node and do a full IBD (Initial Block Download), which is quite resource-intensive. Although, in the last couple of releases, there’s been quite some improvements to the IBD process. And in general, compact block filters is a good way for this use case. Although, in my opinion, not too many wallets make use of it, there should be more.

So, with this background, there was a post in Delving about some new filter encoding. I think it was fuse filters. And what caught my eye was that the author mentioned hierarchical block filters, and that got me thinking how could that help. The basic idea is that with the compact block filters, we have a block filter for every block, which you download first the block filters for each block, which tells you if the addresses, the output scripts you are interested in are present in that block or not. So, the idea with hierarchical is that we create a filter not for one block but for a range of consecutive blocks, and you download those first and you have a match, then you download the individual block filters. So, a block-range filter for, let’s say, 256 blocks basically includes the same set of scripts which are included in those 256 block filters, but exactly the same as even those which were spent within the range, because for history you still need those which were created and destroyed within the range. But in general, they contain less information, because they tell you if an address was used in that block range, but it doesn’t tell you in exactly which block.

So, the cost is that if you have a match, you have to download all the block filters, which is kind of a duplicate download. But still, because of the savings in the block-range filter, the total download size can be less, which is kind of counterintuitive. But I decided to explore, and to my surprise, I found that the savings can be actually quite substantial. In some cases, the total download size went below 20% of the original. And of course, this depends on the exact parameters, like how many transactions you have, because that influences how many times you have to go to the second level. So, I just did this as a preliminary analysis to see if this idea is worth pursuing. And yeah, I think it is, and I have some ideas for continuing because this is just a basic idea. And of course, there are a lot of open questions as well still.

Mark Erhardt: Right. So, the compact client side block filters basically give you a table of contents, or an easy way to check whether output scripts and UTXOs that you’re interested in are present in blocks or being used. And you sort of introduce a second level there that groups block ranges of 256 blocks into a single filter, so you can only get that bigger filter for the range and see, “Oh, if there’s nothing in here that interests me, I don’t have to download the 256 individual block filters”. But when you do have a hit, you obviously have to download all of the 256 individual block filters. So, now you download more data than you would have if you had done that in the first place. But when you don’t even find anything, of course, you save a lot. So, especially for wallets or users that don’t necessarily transact every day, maybe just a couple of times a month, or even less often, there’s a huge savings here, because they only download the ranges and then are able to say, “Oh, I did not have any activity in these about two days”. You were muted.

Optout: Yes, exactly, that’s right.

Mike Schmidt: Optout, you mentioned fuse filters, and we did have a discussion about that back in Newsletter #403, just a different approach to BIP158’s internal, I guess, algorithm. Then we talked about that with roasbeef and Rearden in the podcast as well. I think that was an update to the internals, and not necessarily an idea to extend the range wider as you’re doing there. But I know you mentioned it, so I wanted to tease that for listeners who wanted to dig in more to that.

Mark Erhardt: I mean, talking a little more about who this is good for, if you run a high-volume wallet that has transactions every day, you probably are not going to save with this. If you have transactions every day, you should probably just download the compact client side block filters in the first place, or you have a full copy of the blockchain already because you’re running a high volume, or at least daily active service, and you need to be aware of what’s going on. But if you’re running a light client that you transact with maybe once or twice a month, this sounds like you could significantly reduce the bandwidth, because you’re actually only interested in a few blocks per month. And then, only if your block falls into this range of 256 blocks, you would even download the block filters. So, yeah, for light clients, especially ones that run on the mobile network that would be huge decrease in bandwidth.

Mike Schmidt: Optout, what are next steps for you? Where can listeners find more or potentially help contribute or learn more? Like, where are you going and where should people who are curious be going to find out more?

Optout: Well, for listeners, there’s not much more I can say than, check out this Delving post mentioned here. And I welcome any ideas or suggestions. I have a few ideas which I plan to try out, also do some measurements on the actual mainnet data. And yeah, I have some other ideas. Like, I just mentioned one that once you download the filter for the block range, you have the set of all the scripts within that block range. So, for the individual blocks, maybe we could save some bandwidth if we don’t encode the actual scripts, but just their index within the block range, which are somewhat smaller numbers than the hashes used in the compact block filters. So, this could reduce this data duplication which you have to do when you have a match in the block range. So, that’s something I want to pursue and see how much saving can be obtained there. Yeah, so the Delving post and if I have any new news, then I’ll post it there as well.

Mike Schmidt: Excellent. Well, I guess we’ll keep an eye out for that. Maybe we’ll have you on the podcast in a future show to go through more. Murch, did you have a final question?

Mark Erhardt: Yeah, I was wondering, so you said you would encode the height in the result of the block filter. Is that at the range level or at the individual block level?

Optout: Well, my idea is that you can think of a one-block range, a one-block filter, which through this encoding it encodes, for example, 4,000 output scripts within that block. And if you have the filter for the whole block range, that’s something on the order of 256 times 4,000 scripts. And if you have that, that’s basically you have a number of output scripts and you can just count them and give them their index first, second, third, and so on. And then later in the block filters, you can just use these index numbers, which as I see, they should be, like, on the order of 13 bits, and not, like, 19 bits, which we use in the compact block filter. So, that could decrease a little bit the data. So, this would be a special, a different kind of block filter, which doesn’t include the hash of the actual scripts, but just an index within the block-range data, which we already downloaded.

Mark Erhardt: Right, that would not be forward-compatible. But basically, you would be using the range block sequence of output scripts that you have contained in there as just a reference for the blocks at the block level. I was wondering whether maybe the other way around is interesting, that if you get a result for a hash, that it tells you which blocks to download in the range instead of, yeah, maybe it could just tell you which blocks are relevant and then you only download those filters?

Optout: Yeah, that’s an interesting idea.

Mark Erhardt: All right. Sounds interesting to me, at least. I hope that helps with your request for comments.

Optout: Yeah, thanks a lot.

Mike Schmidt: Optout, we appreciate your time on this project and for joining us today. We understand if you have other things to do, you’re free to drop. Or if you want to hang on, you can.

Optout: Yeah, thanks for having me. I’ll hang on.

Bitcoin Core #34075

Mike Schmidt: We’re going to do a quick detour into the Notable code segment and jump to Bitcoin Core #34075, mempool-based fee estimation, since we have the PR’s author here. Sadiq, you can frame this up however you would like, including commenting on Bitcoin Core’s historical fee estimator quality.

Abubakar Sadiq Ismail: Thanks, Mike. Yeah, the goal of this PR is to improve Bitcoin Core fee estimator. It works, it works really well, but it does overestimate due to a particular limitation that it has, which is it does not look at current data, it uses, like, historical data for its feerate estimation. So, this PR tried to address that limitation. Over the last two years, I started doing research on approaches to estimating feerate and I studied the previous Bitcoin Core feerate estimator to understand why it was designed the way it is, and study the state-of-the-art feerate estimators. So, I made a series of Delving Bitcoin posts with data. And other contributors in the community also commented about their own research. And then, we converged in an approach to make sure that the feerate estimator is still a bit conservative, but it does not overestimate when it shouldn’t. So, Bitcoin Core full node has access to the mempool. It can easily build block templates and see the chunk feerates in that block template.

So, what the new approach of estimating feerate in Bitcoin Core does after my PR is that it takes the minimum of the legacy bitcoind block-policy feerate estimator, and what is currently being paid in the mempool, so what are the chunk feerates of the top block template in the mempool? And then, we select some percentile feerates, based on some empirical data that we do, and then just return the minimum. And this works really well and it reduces overestimation quite significantly, has a high, like, up to 80% success rate. And sometimes it does underestimate, because there are scenarios where the block portion distribution arrivals take a while, and then some congestion occurs in the mempool, or there is an influx of transactions in the network. And because it takes the minimum, it cannot reflect due to that. So, there is some underestimation due to that. And the compromise that we did was, it’s safer to fee bump, but once you overestimate, there is basically no way to come back from that.

So, yeah, I have been running the empirical data, opening up the PR to reviews, refining it, and we currently have a much version of the PR that is intended to be released in the next major release of Bitcoin Core. So, this is the background. I did not go in depth into the algorithm and how it works. There is some preliminary health sanity checks that we do, because you cannot just naively use the mempool for feerate estimation. You have to ensure that your node is well connected and it is not censoring transactions or doing some nasty things before you use your mempool for feerate estimation. So, I have some heuristics that I use to determine whether the mempool is healthy enough to rely on, so I can go into that.

Mark Erhardt: Yeah, I have a couple of questions about that. So, for example, if you were throwing away about 45% of all transactions because you disagree with people putting NFTs into the blockchain, and then you see what you had in your mempool and what gets included in blocks, would your node consider itself healthy if you only have about half of all transactions in blocks? Or what is the threshold for healthiness?

Abubakar Sadiq Ismail: Yes, so I use, like, six blocks’ interval, I do not just take one block. So, I take the average of six blocks. And I use a conservative 75%. And with that, the majority of the time I have not seen any scenario where a node that is censoring transactions has achieved 75% success rate in that six blocks’ average. So, it’s like a number that I’ve picked based on empirical research. I have a data branch and I’m gathering data and I can easily tweak and update that if that is not the case. But right now, the threshold is 75%.

Mark Erhardt: 75% of the transactions or the block weight?

Abubakar Sadiq Ismail: Your mempool has to see 75% of the transactions in the last six blocks’ average.

Mark Erhardt: So, for example, if you set -datacarrier to zero, so you wouldn’t propagate any transactions that have an OP_RETURN output, you would not use mempool feerate estimation anymore?

Abubakar Sadiq Ismail: It depends. If people are using a lot of OP_RETURNs, then your node is not seeing OP_RETURNs, so your feerate estimation using mempool will be very inaccurate. I think even using block-policy feerate estimator will not be accurate as well. So, yeah, that’s the advantage of the tracking statistics, to ensure that you are not doing that.

Mark Erhardt: Okay. So, yeah, you talked a little bit about the mempool feerate estimation, when it is used and what effect it has. So, it can only reduce the estimate. Basically, if the mempool feerate estimation estimates lower, the lower estimate is used for the transaction building and for the RPC that returns a feerate estimate. Could you go a little more into why you wouldn’t want the mempool feerate estimate to be used to increase? You touched on it, but let’s dive a little deeper into that.

Abubakar Sadiq Ismail: Yeah, so during my first post, I was recommending using the mempool feerate estimation for as soon as possible feerate estimate, which is like one and two confirmation targets. But it has come to my notice there are some theoretical attacks that are possible. Like, miners can do some mempool games to artificially inflate feerate estimate in the network. Right now, we are not seeing that, and I don’t think there is the mining centralization that warrants that, but it’s still theoretically possible. So, they can even not publish their high feerate transaction, but they can just choose to withhold blocks or do something, like some mempool tricks, to just create influx of transactions in the mempool. So, you are not really sure when there is a spike, whether that spike is legitimate from Bitcoin users, or it is just someone who controls the hashrate trying to manipulate you to pay in more. That’s why Bitcoin Core, the bitcoind block-policy feerate estimator uses the mempool transactions that have confirmed in blocks as the data points for the feerate estimate.

So, yeah, I saw research from I think Kalle Alm, who suggested using the minimum of the bitcoind block-policy feerate estimate and mempool feerate estimate recommendation. So, I started running empirical analysis on that to see how that works. And it turns out to be really good and good enough for use case that Bitcoin users want, which is not overpay when basically the mempool is empty, which is, right now, the majority of the time.

Mark Erhardt: Right. So, one of the problems that the confirmation-based feerate estimation had is that the reduction of the feerate would lag behind. So, you take the transactions that you had seen in your mempool and then later see confirmed, and you take the time that it took between first seeing them and then seeing them confirmed to estimate how long it takes for transactions with those feerates to get a confirmation. Now, of course, if there were a lot of high-feerate transactions and then fewer of those get added, the feerate would start going down. But since you have this lagging indicator by having to see them first unconfirmed and later confirmed, you would continue to overestimate if you’re trying to be in the next block, because you would assume that, “Oh, to be in the next block, we have to pay that feerate that was previously used, to be in the next block”. So, in the past, especially a long time ago when people were relying on Bitcoin Core feerate estimates more, we sometimes would see an artificial floor, a second artificial floor, the feerates going down and then Bitcoin Core feerate estimation continuing to self-reinforce high feerates at a higher level for some time, because people that were trying to use the next block estimate can continue to pay the same feerate for some time. And the mempool feerate estimation would now very effectively pull this down, because it would see that what is waiting in the mempool right now is much lower than the prior estimates. So, on that edge of the feerate diagram, it works very well to pull the estimates down to the actual mempool content.

One of the games that miners might play is if they have a big cartel, they could create transactions that have high feerates but not mine them. So, they would be sitting in the mempool and people just looking at the mempool would try to beat the high-feerate transactions sitting in the mempool. But then, the mining cartel would not mine them, just leave them in the mempool. So, other people would be paying feerates to compete with something that is actually not competing for blockspace. And this is prevented by the old feerate estimation style of Bitcoin Core, where we require confirmations to be counted for feerate estimation.

Abubakar Sadiq Ismail: Well described, basically. Yeah, this is correct. Are we improved? Not improved, but we’ve switched the default. It’s now not overestimating to a significant factor. Previously, it’s like you would see even 10x or 15x overestimation. But now, it’s like much, much lower, but still this lowers it really down. And I have a graph in the PR description where it accurately describes what bitcoind is recommending and what the mempool is recommending and what the actual block feerates are. So, you can vividly see that this just corrects what is being recommended when it is not actually high.

Mark Erhardt: Right. So, the mempool-based feerate estimate has two different values that it picks. One is the median of the next block for the higher estimate, and then, what is it, the last quartile of the next block by block weight. So, if you create a block template, you basically pick what is the feerate at 50% of the block weight and what is the feerate at 75% of the block weight of our next block’s template. So, 75% is the conservative, but that would still mean that most of the time, the mempool feerate estimate is actually going to get you into the next block, right?

Abubakar Sadiq Ismail: Yes. So, the assumption that we have in full, we don’t really have next block, it’s like next one or two blocks basically. So, if you are a conservative user, you can use the conservative mode, which will take the 50th percentile as you mentioned, and it’s very unlikely that you get bumped out. But yeah, you are right, for the 75th percentile, you may not confirm in the next block, but most likely you will be in the subsequent one, because you will be at the top then after the block has confirmed. So, it depends on the user’s needs. That’s why we have the two options. But the default right now is the economical version, which is the 75th percentile.

Mark Erhardt: So, if you were worried about your transaction being in the actual next block, what you might want to do is you polling the mempool feerate estimate every minute or so, and if it is significantly higher than the feerate of your transaction previously, you would RBF it again. And you would basically just keep bumping your transaction to the 75th percentile of the next block, which would still be at the low end of the block. And it would still likely be a significant reduction over the block-based feerate estimate when feerates are generally dropping right now. But this enables you still to sort of aim for the next block, maybe as an idea for operators.

Abubakar Sadiq Ismail: Yeah, also with cluster mempool right now, we also have an added tool which is getmempoolfeeratediagram. So, you can actually visualize the graph of the mempool and see what are the feerate percentiles from the top block, and determine what is the position of your transaction. So, yeah, the user experience is going to be nicer, I think, for people that have Bitcoin nodes. They can see the position of their transaction. If they want to rely on bitcoind estimate smart fee, they can do it and it works. But if they want to do smart things, they can do what you suggest, or see the position and fee bump to the next position.

Mark Erhardt: Of course, maybe also in this context, RBFing is a bit of a privacy leak, because you might add another input and then combine more transaction graph data into your wallet history. So, if you’re very privacy-sensitive, you might want to overestimate a little more. So, you could use the mempool feerate estimate and then just add a little if you’re both privacy-sensitive and want to be reliably in the next block.

Mike Schmidt: Abubakar, you made a few references to your thought process over time with regards to when it ended up in this PR. I wanted to call out a few things. We had you on in Newsletter and Podcast #295, #283 and #276 to talk about these kinds of items. So, if listeners are curious, probably not all of that discussion is valid, based on what’s in the PR today. In fact, Abubukar, you noted some differences in your change in approach over time. But if folks are curious, they can reference back to that. Also, I thought that the description in the PR that we’re covering here is actually a pretty good reference as well. There’s a ton of different links. It’s almost like its own blogpost as well. So, if you’re hearing that this is a Notable code item, maybe treat it almost more like a News item. There’s a lot to dig in if you’re curious about it. Yes, Murch?

Mark Erhardt: Oh, I have actually one more question. So, I took a good look at this PR for the newsletter item. And I was wondering, if there are too few transactions waiting for confirmation in the mempool, the estimate falls back to the minimum feerate, right? So, if the mempool is actually empty but healthy, you would want to use the minimum feerate and still expect to be in the next block, right? And in the release notes, it said that it would fall back to the higher of the minimum relay feerate, which is now 0.1 sats/vB (satoshis per vbyte), or the mempool minimum feerate, the higher of the two. And I was wondering if the mempool is generally empty or not full, wouldn’t the mempool minimum feerate also be the minimum relay feerate? Because I think the mempool minimum feerate only rises when the mempool is full, right? So, if your mempool, which is by default 300 MB for the data structure, overflows, the mempool minimum feerate will rise. So, could you maybe touch on how it’s not always the minimum relay feerate, or what I’m missing here?

Abubakar Sadiq Ismail: Yeah, I think your thought process is correct. I don’t think it’s going to diverge in that case. I was just trying to be conservative in case if they do, but I will have to look at the historical data to see if it ever happens. But I don’t think it’s likely that that will occur. So, in this case, the minimum relay fee is enough for your transaction to propagate. But you also don’t want it to propagate and not be in your mempool. So, I guess I will add an assumption in the code that they should be the same, see if any tests will fail, or I will see a crash.

Mark Erhardt: Maybe if you configure a very, very, very small limit for the mempool, you might get into some cases where, let’s say, there were very high feerates for a brief moment and your local mempool feerate went up very high. And then, as the demand drops a little bit or drops very rapidly, you might get into a situation where you have an almost empty mempool, but the minimum feerate hasn’t regenerated fully yet. So, I guess in that case, it is good to know that it is the higher of the two minimums, but I think you’d have to run a very odd configuration and then run into very specific circumstances. But yeah, anyway, I just noted that it was pointed out as an item, and was wondering whether there was more here.

Abubakar Sadiq Ismail: No, I was just being conservative, I did not. But that’s a good point.

Mike Schmidt: Abubakar, thanks for your work on this over the years. And thanks for joining us today among these other appearances that you’ve made. And also, thank you for engaging 10 out of 10 nerd-level Murch on this particular item. Murch is on fire for this one. We appreciate your time. You’re free to drop, or you can hang on if you’d like.

Abubakar Sadiq Ismail: Yeah, it’s my pleasure. Thanks for having me.

Discussion on universal opt-in replay protection

Mike Schmidt: Cheers. We’re going to jump back up to the News item. We have a fourth guest that has joined us. Moon, before we introduce the item, why don’t you introduce yourself? Who are you?

Moonsettler: Hello everyone, I’m basically just someone that likes to opine on Bitcoin consensus rules, I guess. I try to contribute to the discussion about Bitcoin security and scaling. I think that’s all about me. I’m a nym and that’s how I like it.

Mike Schmidt: Well, thanks for joining us. We’ll jump into your item titled, “Universal opt-in replay protection”. Maybe you want to help us set this one up, Moonsettler. Maybe, what is replay protection? Why are you happening to talk about it now? And then, what is your proposal?

Moonsettler: All right. So, replay protection means if there is a chain split, then the default is that a transaction that is valid on one chain is also going to be valid on the other chain. And replay protection is some explicit rule that prevents this from happening. And for example, the Bitcoin Cash fork included such a replay protection. But transactions that did not use it, I believe, were re-playable on both networks. So, if someone wanted to, let’s say, sell his Bitcoin Cash and he was not careful, then he could also have sent his bitcoins away to someone else. This is a major issue. And I have seen when the BIP110 fork discussion happened, and we were watching the whole thing basically play out live, a lot of people advised that nobody should even attempt to sell one side of the fork, because there is this great danger that there was no replay protection. And that can be a deliberate choice. Like, anytime someone attempts a fork, they can decide, and especially if it’s a hostile fork, they would probably decide not to add replay protection. And people, of course, every time something like this happens, the discussion comes up who controls the network and who decides, and stuff like that. And I always thought that in the end, if you are up against a minor majority, the only thing you can do is sell your coins on the fork that you do not want to see, and keep them on the fork that you want to see. And if enough people do this, then the economic incentives align, and that fork will have the greater hashrate.

Now, when someone is faced with a situation with no replay protection, then obviously it becomes apparent that this is not as easy to do, and it’s actually dangerous. And the whole idea about adding opt-in replay protection is to empower the users, that when in need, they can safely and securely make a deliberate decision. They can express their desire, their beliefs, their preferences via moving their coins. And even if only one of the forks, let’s say, even if only one of the forks enforces these rules, the coins can still be split. And this might actually be very important if we ever find ourselves on a minority hash fork. Let’s say a majority miner cartel hash-power share decides to execute a hostile hard fork, the thing that people keep bringing up is, let’s say, messing with the issuance schedule, like the miners creating coins for themselves. This is a very old trope. And what can the user do on a network with no replay protection and with the blocks actually coming in very slow? Like, people who sat on the BIP110 chain saw that when the majority of the hashrate is not mining your chain, then you are in a really tough situation.

So, when all this happened and people were asking the questions, “What do you do in such a case?” that’s when I thought, well, the obvious answer should be that we empower the users before this happens, right? So, in case you have to do this, then you have the tools, you are empowered to express your preferences. Now, obviously, there is a question about how to do this, because pretty sure that any such rule that we would add could be used to attempt to scam people. Like, someone could make some P2P exchange, but they commit to a hash that is not in the longest chain, and that transaction is basically invalid, and they never pay you; but you sign your end, and that becomes valid, and stuff like that. So, it’s very important if such a rule is added that the interfaces people use should warn them of this situation. Yes?

Mark Erhardt: Maybe let’s explain a little bit what your idea is first before we get into how it could be broken.

Moonsettler: Yeah, sorry. So, my idea, I would like to stress that this was just an example, so I’m not saying this is how it should look like. Obviously, there are multiple ways to do this technically. But the idea is that you can commit to a previous blockhash. So, that is the gist of the idea, that if that previous blockhash changes, your transaction is invalid. This is the thing that I thought that empowers people to make an economic decision and express their preferences in a safe way. And normally, transactions do not commit to previous blockhashes. And this is normally a feature, by the way, because the way Bitcoin reaches any sort of finality, or the way it tries to not solve the Byzantine General Problem, but I like to say it actually proves that it does not need to solve the Byzantine General Problem, is we allow reorgs. That is a basic fact of Bitcoin that we allow reorgs. And normally, we want transactions to be includable in any reorg. But again, a chain split, a fork war, is a very different situation.

Mark Erhardt: Right. For example, now in the situation where BIP110 was forking off, I think they found eight blocks in the past three weeks. And here, they could, for example, commit to the first block after the chain split that is only present on their own chain, so the first block that was signaling for BIP110 activation that was not in the best chain for the rest of the Bitcoin Network. And that way, if they send a transaction, they want to only confirm on the BIP110 chain tip; they would be able to force the transaction to only be valid there by committing to this branch of the blockchain. And then, even while Bitcoin had 3,000 blocks more meanwhile, they would not be able to mine that transaction into their chain. And that way, you would be able to split your coins between Bitcoin and the BIP110 chain tip effectively.

Moonsettler: Yes. So, the main issue that people were warning against is actually, that you are trying to sell your coins on the BIP110 chain, and the same transaction would be replayed on the longer chain, the heavier chain, the more work chain, let’s call it ‘legacy chain’ in this case. But I think the more interesting question is really when the situation is more dire. Like, in a case when we are not the hash majority, this is a much more interesting case, because at that point it can be a literal life-or-death situation for what we believe Bitcoin is and how we fight for that, how we express that. But anyhow, my idea was that we add a commitment to a previous blockhash in the taproot annex. This is pretty economic, pretty cheap, and the taproot signatures already commit to the annex. So, it would be one use of the taproot annex, because we have not really figured out what we want to use it for. But there are ideas and there are proposals about how to structure it. And I don’t actually insist on it, it just sounded funny in my head, to <0xFAF0>, Fork Around and Find Out, should be the graphics and then we include the previous blockhash. Obviously, you don’t have to include the whole hash. You can include the block height and you can include the partial hash. There are all kinds of trade-offs and possible solutions, and I don’t have a strong opinion. Like, whatever technical committee agrees is fine by me. I really just want the users empowered. I want us to be able to safely express something like, “I’m selling these coins. I’m not interested in this network. Whatever this is, I don’t want any of this and I’m selling”.

Mark Erhardt: I think what Moonsettler is getting at here is one of the most important points about such a fork situation that was very frequently misrepresented in the last few months. The user base can express a preference for one of the two sides of a fork only by their economic actions. And the economic action in this case would be to buy one side and to sell the other side. If a large portion of the user base, the economic actors in the network, express a strong preference, this would devalue one of the fork sides and force the hashrate to mine the other one for profit. Otherwise, they would be mining a chain tip that is less valued but costs the same energy to produce blocks for, and thereby the user base as a group can express the preference. One of the things people pointed out was that even though many people had offered to make trades for future coins on one or the other side, there was very little economic demand for one of the sides, and the people that understood this situation used this as a predictor for which side would succeed of this fork. And now, one of the problems was, I blogged about this a few weeks ago too, that you weren’t able to easily split your coins and then move them separately on the two chain tips.

With Moon Settler’s proposal, where you would be optionally able to put a commit in your annex, you could sign a transaction that can only be used in one of the two chain tips. This would allow you to safely move your coins into a trade or onto an exchange and not send both of your chains. Otherwise, when you make a transaction that spends a specific UTXO and it is valid for both chain tips, because the UTXO still exists on both chain tips, both coins would move, right? And so, one thing that I see with this proposal is that Bitcoin Core and Electrum, and maybe some other wallets, meanwhile use something that is called anti-fee sniping, which uses a locktime and locks the transaction to be only valid if included in the next block or later. So, this prevents attackers from remining the previous block to collect the fees. The idea is if ever the fees of transaction become the dominant part of the block reward, it might become more attractive if there are very few transactions waiting, to remine the previous block and take all the juicy waiting transactions and all the transaction fees from the previous block, instead of trying to build on the previous block and continue the blockchain. And to obfuscate how long transactions have been waiting to be mined, the anti-fee sniping sometimes sets previous block heights as the locktime. So, for example, if you committed to a block that is only two blocks previous, and your anti-fee sniping says your transaction was created 100 blocks ago, that would be a little funny.

So, implementing this might have a few edge cases where you have to think about it a little further. But as an option, having this universal opt-in replay protection would make it much easier for the economic actors in the network to express their preference for different forks if it were adopted.

Moonsettler: Yes, thank you. That was a very good summary of the idea. I think the most important thing is really that if people are not empowered to make such a decision, then we are going to see this whole narrative, I don’t know what to call it, ‘perversion’, that the miners run the network and they decide what the rules are and stuff like that all over again. And again, future forks can actually be really hostile. I don’t consider BIP110 a hostile fork attempt, but the no replay protection was certainly a bit hostile in my evaluation.

Mark Erhardt: Actually, I think they finally had an opt-in replay protection in their fork, so there is some way of signing differently. And if you use the new type of signing, it will only be valid for the new BIP110 hard fork chain tip. But, well, to be fair, it only started with the hard fork.

Moonsettler: Yes. And the other thing I wanted to add is you can actually just use the fees. Like, you can say, “I’m paying these fees”, let’s say I’m paying a million sats of fees, and let’s say there is not a rule change for just someone who is trying to execute like a deep reorg, I can say, “I’m paying this million sats’ fees on the currently longest chain, and the one that is trying to catch up is not getting that, no matter what they do”. So, I think it empowers the users in multiple ways, but we probably should think about the adversarial side of this, like it always pay to take into account how scammers might try to take advantage of the new rule. And that’s all I wanted to start as a discussion really. So, it’s less of a concrete proposal that this is how we should do it, and more like we should really, really think about this, because it would be very empowering to the users if we had something like this. And anyone that attempts a hostile fork basically cannot circumvent such a rule if it exists on our fork or the legacy fork. So, as long as one of the chains enforces this rule set, we can safely split the coins and express our economic preferences.

The other thing I wanted to say is ancestrally splitting the coins is really, really difficult. So, there is this lock in. The miners are unable to move their UTXO, their newly minted coinbase UTXO, for 100 blocks. And we have seen how slowly the BIP110 blocks came and how excruciating it may have been to the people who were there and tried to figure out how to talk to the miners, let’s say, even with fees or whatever else. So, that was another thing that I thought of, that we should really have something like this just in case.

Mark Erhardt: Right. In this case, there were two interesting aspects. So, because one chain tip was moving so much faster, one way you could split your UTXOs was to pay a low-feerate transaction that would get mined on the Bitcoin side because the feerates were very low, but it would get ignored by the BIP110 side because the feerates had accumulated by them having eight blocks in over three weeks. There were hundreds of blocks of transactions waiting, and I think feerates went up over 12 sats/vB. So, you could mine a low-feerate transaction on one chain tip, and then create a second transaction with a high feerate that would be eligible to be included in the BIP110 chain tip eventually, and would be a lot more attractive than the low-feerate transaction that you had on the Bitcoin side. So, there were some ways to work around it, but especially what you usually rely on, which is the miner outputs that coinbase transactions can only exist on one chain tip, because obviously the coinbase is different when someone else mines a block. So, any transaction that either spends a coinbase output or derives from a spent coinbase output is inherently unique to that chain tip. So, there are some ways to do it, but this universal replay protection that Moonsettler suggests sounds like a very easy way for users to get in on this.

I would now be curious, Moonsettler, you said that there were maybe some scenarios or ways in which scammers could use this annex commitment to a specific blockhash. Could you maybe touch on some ideas you had how it could be misused to confuse people?

Moonsettler: Okay, before that, so one second. So, the idea that you can ancestrally split even just a single UTXO, and then you can involve that in, like, large coinjoins have been brought up, that if you have one UTXO, so that you can make it easier for others to participate. But this usually is highly interactive and forces people into abandoning their current security setup. Like, someone has relied on a security setup for years, certain hardware and software configuration that he uses. And every time that you need to coordinate with other people and you need to step out of your comfort zone, that is a huge deterrent from participating in this. Like, this is just risk, risk, risk. And even relying on feerates is not as concrete as something enforced by consensus and something as deliberate as picking a block and saying, “My transaction is only valid on a chain that includes this block”. That’s all I wanted to say about this. I think it’s a huge upgrade in security and it being noninteractive, and that is empowering to people.

So, ways this can turn out to be problematic is two things came into mind. One is people including performative commitments in every transaction, like commitments to the segwit of the activation block, or whatever they like. And after a while, every UTXO will have some form of commitment, and we are just getting a UI clutter in trying to track all the ways that transactions ancestrally commit to block heights. So, instead of using it when the need arises and for its intended purpose, people can use it for silly reasons. And also, people could, like I mentioned, craft transactions that are either not going to be valid or they have good reason to assume that it’s not going to be valid in retrospect. Like, shallow reorgs can be used with these commitments to maybe scam people out of money. So, for all these reasons, my belief is that we should certainly empower people, but we should also provide them with information. So, if a UTXO that they receive has ancestral commitments, they should be able to see this on the regular interfaces that they are using. Because if they are blind to it, like, if they are using the current interfaces, they are completely blind to these commitments, these restrictions, then there might be situations where they lose money. So, that is possible.

Mark Erhardt: Right. So, let’s say this universal replay protection were soft-forked in the future and you were running a light client or other software that isn’t upgraded to the soft fork yet, you could be in a situation that someone offers you a transaction and you do not check the annex, and it’s actually invalid in your chain tip. And thereby, you don’t notice that the payment they’re offering you unconfirmed is not reliable. It sounds like things to consider might be that such commitments should have a minimum depth of maybe six blocks or something, so that you cannot be subject to a shallow reorg. We haven’t had a six-block reorg in 12 years. So, a six-block, just from the top of my head, sounds like a pretty decent minimum. And the other one would be that, what was the other one? I was going to say another thing! Anyway, if I think of it, I’ll let you know. But it sounds like an interesting topic.

Moonsettler: Sorry, I actually don’t like the idea that we have a minimum height commitment or confirmation minimum, because this goes against user empowerment in certain situations. Like, when 90% of the hashrate is mining a hard fork that we don’t want, this can take an excruciating long time. And the earlier people can express, even with just fees, their preference. Like, let’s say people are starting to pay 100 times the fees on one of the forks, like they are not splitting coins or anything, they are just paying 100 times the fees for those transactions. That might be something that they can immediately start doing. And so, I don’t really like the idea of minimum commitment, but I do like the idea of empowerment and well-informed choice. Users have to be able to make a well-informed choice. That’s kind of my take on this, that I want them to see what they are doing. And that requires changes in the nodes aside from these new rules. So, the new consensus rules do not help people to see, again, these commitments can exist ancestrally. So, you might receive a UTXO that has no such commitment, but its ancestor had such a commitment. And in that case, you are still exposed to this. And probably, my guess is the users are most interested in the shortest of these commitment ranges. Like, you are not interested in, let’s say, a 1,000-deep commitment. You are interested in the commitment that is immediate ancestor and two blocks away from you. So, that’s my guess.

Again, the more information the users can see, the better. It might be a problem that is not specific to bitcoiners, but anyone that tries to make a P2P exchange with other assets. And those software not recognizing this rule might actually allow people to get scammed. So, we have to consider these things as well. And from this perspective, maybe it helps if you require some minimum commitment amount. But again, watching that whole BIP110 situation, at the moment it felt like a bad idea to me. On the other hand, preventing commitments too deep, like unreasonably deep, like 1,000, more than 1,000, 10,000-block-deep commitments is probably just basically spam. Like it’s not practical, it’s not for the intended purpose. So, I was more in the in the mindset of we should not allow people to make like commitments for no good reason. Really, that is basically just spam and cluttering everything. In fact, I think the valuable commitments are very close to the current chain tip. I think that that is the likely thing. Or, of course, the most likely thing if there is a chain split is an immediate block that follows the split, right? That’s the most likely thing that people would commit to. And that might even be a few hundred blocks deep, in case the BIP110 fork, or now maybe a few thousand. I did not count how much, but a lot of time has passed and we are going on. So, it’s a hard thing to say, yeah.

Mark Erhardt: Right, but when you want to commit to one side of a fork, you can also move up the commitment, right? When you commit to a successor of a specific block, you also explicitly commit to its ancestors. So, if, for example, the limit were that you can’t bury it more than 250 blocks, you could still go to the block that is 200 from the chain tip in the current Bitcoin chain tip.

Moonsettler: Yes. Sorry, such a rule does not take away from the utility, but I think people would symbolically want to commit to those two blocks. Like, that’s the instinct that everyone is committing to one block that they really want for a chain. And that makes it easier for people to communicate about things and verify things.

Mark Erhardt: Right, because it’s the same hash every transaction, yeah.

Moonsettler: Yes, I don’t think I have much to say if you have questions.

Mark Erhardt: Yeah, I remember the other thing that I mentioned. You were worried about performative or spam commitments in the annex. The annex is, of course, subject to the witness data discount, and thereby a commitment of 34 bytes or even smaller than that would be extremely cheap. So, maybe such a commitment should be actually bigger. And because once such a transaction is mined, other transactions can build on top of it, it might be fine if such a commitment were fairly expensive, because it gives a point for people to split out and spread out such replay protection. Once any transaction is unique to one chain tip, you could take an output from that transaction, splinter it in hundreds of coins, send it to people that, for example, pay for a replay protection. And they can then put that into their input set of a transaction in order to get the replay protection.

Moonsettler: Yes, excellent point. So, if we are trying to keep spamming this extra chain state annotation, because in my head we would annotate the chain stain with the closest ancestral commitment of every UTXO; if you want to decrease the spamminess of this commitment state, then it might be a very good idea to make the commitments relatively expensive as to not be too trivial, but still absolutely useful. And again, it’s a feature if it’s recognizable, I believe. Like if you can recognize the hash of a specific hash that is meaningful to you and you can recognize it in every UTXO, let’s say, that you receive, I think that’s a feature. So, I like the idea.

Mike Schmidt: Moon, thanks for joining us to talk about this today. We appreciate you hanging on in the newsletter to be able to opine on this.

Moonsettler: Thank you very much.

HWI repository to enter maintenance mode

Mike Schmidt: Cheers. We have one more News item this week with no guest, “HWI repository to enter maintenance mode”. So, this is maybe a quiet end of an era here, because Ava Chow has announced that the HWI (Hardware Wallet Interface) repository and tool that lets Bitcoin Core and other software talk to hardware signing devices, is going to plan to scale back to maintenance-only work and will eventually be archived. Murch, I think you may have some additional insights here.

Mark Erhardt: Yeah, basically, while the HWI was developed under the umbrella of the Bitcoin Core org, it had been essentially a solo developer project. And recently, or actually for a couple of years, Ava has been mentioning that it was one of the projects she was looking for a successor for, either someone that took over the maintenance of the repository or a different project taking over this work. So, one of the reasons why this never got fully folded into Bitcoin Core was that Python makes it very difficult to make the project reproducible. And now, recently, the Wizardsardine team has been working on BHWI, which is the Bitcoin Hardware Wallet Interface, which is a project that is open source, but developed by the Wizardsardine team that also produces the Liana wallet. And this seems to be getting close to feature parity. There are also some other open-source contributors that work on BHWI. So, Eva indicated that she would be finishing the MuSig2 support in HWI, and after that point would enter maintenance mode, where only small updates would be made to keep the continuous integration happy. And otherwise, HWI would not be further developed.

So, hopefully, this helps give BHWI even more support and attention. And perhaps because it is written in Rust, it would be easier to make that reproducible. And, well, I can’t speak for the Bitcoin Core project obviously, but if it got broadly adopted by the ecosystem, potentially it would also be released either in tandem or compatible with Bitcoin Core, or even in Bitcoin Core eventually. So, yeah, I guess I hope that hardware wallet, hardware signer developers, and people that are interested in wallet development and this interface between hardware signers and wallet software, pay attention and maybe allocate some of their development resources in a way that helps move forward.

Mike Schmidt: So, it sounds like perhaps three different factors. We noted, I guess, each of them in the newsletter, which is the lack of reproducibility; the fact that Ava was basically the sole developer on the repository; and then, I guess, slightly tangential but related, is the fact that there is this alternate library that also appears to have some energy around it in Rust with Wizardsardine. You mentioned there’s some external contributors as well. We covered two HWI PRs, I think, last week, and I think we have two more in the code section this week. So, the project is still continuing to make some changes, but I guess listeners should be aware of this potential end state or maintenance mode for the project. All right. That wraps up Alerts and the News, and we can move to Releases and release candidates. Gustavo?

BTCPay Server 2.4.3

Gustavo Flores Echaiz: Yes, thank you, guys. So, this week, we have two releases. The first one comes from the BTCPay Server repo. So, this is a security release 2.4.3, which doesn’t share any details on what the fix is or what the issue was. It simply says that users that have servers that are shared by many users are very recommended to update, okay? So, that is the only advisory here. You should all update, but mainly if your server is being shared with multiple users.

Eclair 0.14.2

The next one is the Eclair release v0.14.2. So, this one has multiple bug fixes, which we’ve been discussing in the past two previous newsletters. For example, in the Newsletter #419, we covered on-the-fly funding issues. So, this is a specific feature that is used by ACINQ’s Lightning Service Provider (LSP). So, the company behind the development of Eclair uses an LSP for the Phoenix wallet and offers a service with the on-the-fly funding or Just-in-Time (JIT) channels. So, a lot of issues related to that were fixed and were included in this release. Also, as we discussed last week, limiting the resources consumed by the channel announcement, by the gossip protocol, is also part of this release, and other bug fixes as well. Additionally, we’re going to cover later, in the next section, some new features that were also included, such as adding support for fulfillment payload, which is a type of message for attribution data; we’re going to get to that in a second. And also, being able to advertise that we are only receiving or forwarding onion messages from peers with whom we have channels. That is also now part of the BOLTs spec, and that is also included in this release. So, mainly bug fixes, but two major features too.

Also, one advisory included in this release is that you should no longer run Eclair and Bitcoin Core on separate machines without a secure tunnel. So, users are explicitly advised to either run Bitcoin Core and Eclair on the same machine, or use a secure tunnel between, if you’re running Bitcoin Core on a remote machine. So, those are the two releases of this week and now we get to the Notable code and documentation changes. The first item, #34075, we covered it at the beginning of this episode, which is the incorporation of a mempool-based feerate estimator next to the existing block-policy estimator. So, at the beginning, I think we kind of did an enough deep dive on that feature. But the item is there and the PR description is quite complete. So, if you ever had any extra questions, you could find all the details there.

Bitcoin Core #35730

The next item, Bitcoin Core #35730, this is about a new config option, called -rpcmaxconnections, which defaults to 16 and defines the number of clients that can, at the same time, connect to Bitcoin Core’s HTTP server, which by the way, in Newsletter #411, we covered how the previous HTTP server, which was dependent on a libevent, one of the last remaining external dependencies of Bitcoin Core, that was replaced by a new HTTP server that doesn’t have any external dependencies. So, with that change in mind, the previous implementation had limitations that couldn’t allow it to develop this new feature that this newsletter covers. So, this new config option about having a default max connections of clients that can connect to the HTTP server is mainly motivated because previously, having no cap on the number of connections could lead to those connections exhausting the resources of the machine Bitcoin Core was running on. And that could cause other unrelated operations, such as disk operations, to fail. So, the main motivation is around capping the resources consumed by external clients that connect to the HTTP server.

Side effect is also a performance boost, in the sense that if multiple external clients connect to the HTTP server, the connection requests used to be processed one by one, and now more than one connection can be processed per iteration.

Bitcoin Core #35580

The next item, #35580, here, there’s a bug that is fixed. When constructing a block template, Bitcoin Core could incorrectly check for the transaction’s chunk’s sigops-adjusted weight, which is not the same as the BIP141-defined weight. Instead, it also takes into account the cost of the sigops of the transaction, and it can determine a higher weight than the actual BIP141 weight. Yes?

Mike Schmidt: I should have called out before, but this is also Abubakar’s PR. Maybe he also wants to comment on it?

Abubakar Sadiq Ismail: I am here.

Mike Schmidt: How did Gustavo do so far?

Abubakar Sadiq Ismail: He’s doing great! Yeah, this is part of a series of fixes that I am currently trying to do for the block assembler, where right now it’s impossible to generate a fully-built block template because of some bugs. So, in the PR, there is an attached issue that describes three issues that will prevent creating a full block template in Bitcoin Core. And this PR fixes one of them, which is during block assembly, we select chunks from the mempool and add them to the block template. And we have an accumulator of the weight of the selected chunks. And while we are selecting, we test that a particular chunk in the mempool will fit into the block template or not. So, there is a mistake in that function that performs that check. But instead of adding the accumulated weight of the chunk-to-be-added chunk weight, we accumulate it with the adjusted weight, which may be higher than the chunk actual weight, because the sigops-adjusted weight is the maximum of the chunk weight and the sigop cost of the transaction.

So, there is a scenario where you may skip some chunk instead of adding it by assuming that you will exceed the weight budget while that is false. So, that has two issues. It may make you not fill a block template; it may also make miners lose fee revenue, because the chunk that you skip has a higher fee than the subsequent one. So, this is a minor bug fix to the block assembly that changes the accumulator to add the actual chunk weight instead of the sigops-adjusted weight. So, I plan to incorporate the other fixes, and with that, we will be able to create a full block template, potentially.

Mark Erhardt: Yeah, one of the problems here is that the sigops-adjusted limit is only enforced at the full block level. So, when you have a transaction that has a very high sigop load, you don’t have to enforce it at the transaction level. So, really what you want is only one dimension by which the block weight is measured, which we succeeded at comparing with the witness discount being calculated, so that the weight is backwards- and forwards-compatible to the size, but not for the sigops. It’s kind of weird for the sigops, where we enforce it at the block level, but not at the transaction level. And then, I think in taproot, we actually enforce it at the transaction level, rather than just the block level.

Bitcoin Core #35665, #36025, and #35516

Gustavo Flores Echaiz: Thank you, Abubakar and Murch for that extra context. So, moving on to the next item, we have three PRs in one item: #35665, #36025, and #35516. So, all of them fix several issues when combining or joining PSBTs. So, you can read the item for the exact reason why they happen, but I think the important point is when do they happen. So, for example, the first PR fixes a bug that occurs when you are combining two different PSBTs, let’s say you and a cosigner, but the PSBTs disagree on the key origin of an xpub in the metadata part of the PSBTv2. So, for example, your PSBT says that the fingerprint and the derivation path of the xpub is different than what your cosigner says. So, what Bitcoin Core would do here is that it would simply add both keys, so keep the same xpub, but with different origins, and that would then create an invalid PSBT that decodepsbt RPC rejects. And the reason why it was doing that is because it was grouping records by key origin, so it was missing that the xpubs were duplicate, because it was grouping them by key origin rather than grouping them by xpub, which is the right way to do it. So, that was the basic bug and the fix. However, this bug is very theoretical because it’s very unlikely this situation happens. The xpub has one origin, and you and your cosigner having two different origins for the same extended public key is just an unlikely scenario.

The second PR fixes a very similar issue when it comes to tapscript records, particularly when there’s a control block, which is what commits the tapscript to the transaction. So, the same thing could happen. The same tapscript could point to different control blocks on you and your cosigner’s PSBT file, and the same thing could occur here; both scripts would get duplicated and it would also trigger an invalid PSBT edge case. That is also a scenario that is malformed or inconsistent metadata, not really something you could run into. But however, the second PR also has another case where the same tapscript has multiple valid control blocks. So, you could also run in the same issue, but this is actually protocol-valid, because imagine you have a tapscript, but just in different locations. So, for example, one scriptpath has the same script as another scriptpath, but it doesn’t really resolve to the same control block because they have a different merkle position. So, here, once again, you could get an invalid PSBT because it was processed incorrectly in this specific edge scenario, which is protocol-valid, but very, very niche.

The last PR is a more real-world example. When you are combining two PSBTs with the joinpsbts RPC, for example if you’re in a coinjoin or a payjoin transaction, joinpsbts will shuffle the inputs and the outputs, but instead of combining both PSBTs, it would construct a separate PSBT file that would drop some global metadata, specifically the global xpub record and other proprietary fields. So, this was more likely to run into, and this is also solved by instead of creating a new separate PSBT that drops the records, you’re just keeping one of the PSBTs that you’re joining and that retains the metadata records.

Bitcoin Core #35933 and #34697

So, the next item, very similar in some ways, is related to MuSig2 PSBT PRs #35933 and #34697. So, here, the first one is if you have a hardened public derivation on a MuSig aggregate key, which doesn’t really make sense because a MuSig aggregate key doesn’t have a private corresponding key, then before, the process would simply abort. Now, it will detect that it’s trying to derive from an aggregate key with hardened derivation, so it doesn’t really make sense. So, it will just fail normally instead of aborting the process. Also, if Bitcoin Core, when processing a MuSig to PSBT, was trying to match with the wrong aggregate key and it wouldn’t derive properly, it would also abort the process. Now, it will simply skip the mismatch key and try to find another key that actually derives correctly.

The second PR, well, it improves the detection of duplicate keys in descriptors. So, for example, if you have the same xpub that you’re using for two separate keys, and a MuSig2 PSBT, but they have different derivations, you’re not exactly duplicating the keys. But Bitcoin Core could interpret it as such if one of them was using hardened derivation; it wasn’t properly trying to derive the key with the private key information that it would have. So, it would just simply run into a situation where it wouldn’t be able to derive from a hardened derivation path and it would just believe that both keys were the same, and it would hit the scenario where they would be falsely treated as duplicates. So now, Bitcoin Core, if possible, uses the private key information when comparing key expressions, and when one of them or many of them require hardened derivation. So, it doesn’t falsely treat keys as duplicates as it was doing before.

Core Lightning #9374

Now, we’ve completed the Bitcoin Core repo and now we’re jumping into the LN implementations. So, the next item comes from Core Lightning #9374. This is a similar bug that we covered in Newsletter #418 on Eclair, where when making multiple RBF attempts on a dual-funded channel funding transaction, CLN would expect the last RBF attempt to be the one to confirm, similar to what Eclair was also doing on its own bug. However, a previous attempt can always confirm. So now, CLN properly records the funding attempt and actually confirms, instead of assuming that it’s going to be the last attempt that confirms. And this was specifically occurring when a peer was reconnecting while CLN was still syncing with the blockchain. That’s when CLN could assume that it was the latest RBF attempt that confirmed and log the channel to an unconfirmed funding transaction, instead of actually looking for the one that actually confirmed, even if it was a previous RBF attempt.

Eclair #3342

The next two items are from the Eclair repo. So, those are the features that I was mentioning that were part of the latest release. So, the first one is Eclair implementing what’s called option_onion_message_only_channels, which is a feature bit that we covered in Newsletter #416, when the BOLTs spec added this new feature, which basically allows a node to advertise to the network that it will only accept onion messages that come from channel peers. As we’ve discussed before, there’s a lot of difficulty in handling onion messages and managing resources around onion messages. So, some nodes simply prefer to only accept these onion messages from channel peers. So, now it’s part of the BOLTs spec, and Eclair implements it in this new item in PR #3342. So, any Eclair user can now use this option and advertise to their peers that they either do that; or, on the opposite, they can decide not to implement it and advertise to the network nodes that they will accept an onion message that is not necessarily from a peer.

Eclair #3321

And then, the next item #3321, this one implements support for the fulfillment_payload field added to the update_fulfill_htlc message. So, we talked also about this in Newsletter #416, because those two items were added to the BOLTs spec together. So, in BOLT’s #1344, we covered that the attributable failures protocol was extended to successful payments. So, when you make a successful payment, the receiver sends back to the sender a message that can now include a payload for the attributable failures protocol. That is the fulfillment_payload. However, this payload is defined, but no specific application or message inside that payload is yet defined. So, Eclair implements relaying those payloads and authenticating them as part of the attribution data, but does not yet originate them or actually implement a specific application. And that is the case also for the BOLTs repository. What’s cool about this is that LDK has also implemented this feature way before it was actually added to the BOLTs repo. So now, Eclair and LDK nodes are both compatible on using this new feature, that we should probably expect more details in the BOLTs repo over specific applications on how to use it eventually. But in general, this is just an extension of the attributable failures protocol to successful payments.

LND #11008

The next item, the LND repo now, #11008. So, here there was another bug in LND where, if at the same time you were receiving a PSBT from a channel co-funder and you were verifying that PSBT for a funding opening transaction of a channel, but meanwhile you were also at the same time canceling a channel reservation, so not exactly closing a channel but you were going open a channel and now you’re canceling that channel reservation, well if you did both of those actions at the same time, your LND node single reservation handler could kind of get stuck and prevent your node from opening or accepting channels, or even leaving newly-funded channels stuck until you restarted your node. Some users even reported spending dozens of hours in this state, where they were just stuck and unable to open or accept new channels or process newly-funded channels. So, the fix is that both of these operations are no longer depending on each other and they will not block each other independently.

HWI #841

The next two items are from the HWI repo, as we discussed earlier in this episode, that it’s going to enter maintenance mode. Well, before it does, it has shipped two new features. The first one, #841, this is a follow up to what we covered last week in PR #842, which added the registerdescriptor command for registering a descriptor on a hardware signing device. So, once you as a user, you’ve registered wallet descriptor policy on your hardware device, the display address command is extended to match that use case. So, for example, you have your hardware signing device, you use a software wallet that uses HWI to connect to your signing device, you register a descriptor on the signing device, that was what we covered last week. And now, your software wallet can basically instruct with HWI to display an address on your hardware signing device that matches the descriptor that you registered in your hardware signing device. And your hardware signing device will be the one making sure that the address being derived matches the descriptor policy when getting struck to a specific address index and receive or change branch.

HWI #849

The next item is an update, PR #849, updates the support for COLDCARD devices, specifically for COLDCARD edge devices, which is an experimental firmware for COLDCARD devices. So, the main feature being added here is that single-signature taproot addresses, HWI can now instruct COLDCARD to display a single-signature taproot address with the display address command. So, the COLDCARD device does have its own address explorer feature, but that is independent of the software wallet and HWI. So now, this is about HWI instructing COLDCARD to display the same address that is being displayed on the software wallet. HWI instructs the COLDCARD signing device to also display it. There was also a bug with COLDCARD and HWIs, where the PSBTv2 format was always being converted to PSBTV0. So now, that is fixed So it preserves the PSBTv2 format instead of converting it unnecessarily.

Rust Bitcoin #6755

The last item in this newsletter and in this section is Rust Bitcoin PR #6755. Here, what was happening is if Rust Bitcoin received, let’s say, from a block that it was verifying, if it included a transaction that was using a non-standard sighash (signature hash) value, it could map that non-standard sighash value to a standard sighash type, and that would you lose the original value. And then, when comparing the sighash value to the segwit v0 signature hash, it would basically not be able to verify the signature because the value had been overridden by a standard value. So, there was a mismatch in the transaction, and Rust Bitcoin could consider that this transaction was invalid, even though it was consensus-valid and was probably already confirmed and included in a block. So now, Rust Bitcoin will preserve the original value, even if it’s a non-standard value, instead of overwriting it silently with a standard value. However, users can still require standard sighash types.

There is a function for that, called from_standard, that we covered in Newsletter #138. So, a caller could also say, “I want you to override non-standard values with standard values”, or basically just say, “I will only accept standard values”. So, there remains that feature for callers that want specifically that behavior. But unless you specify that, the non-standard sighash value will no longer get overridden by a standard value, which could create a transaction verification issue later. So, that’s the final item and that completes the newsletter.

Mike Schmidt: Great, thank you Gustavo. We also want to thank our guests for today, Moonsettler, Níckolas, Optout, and Sadiq who’s still on with us. Thank you also, Murch, for co-hosting, and for all of our listeners for listening. We’ll hear you next week. Cheers.

Bitcoin Optech Newsletter #420

2026-08-28T00:00:00+00:00

This week’s newsletter relays advance notice of a planned Core Lightning security release, summarizes a discussion about opt-in replay protection for potential future forks, notes that the Hardware Wallet Interface (HWI) project will enter maintenance mode, and describes a request for comments on using block-range filters. Also included are our regular sections announcing new releases and release candidates and describing notable changes to popular Bitcoin infrastructure software.

Action items

● Prepare for an upcoming Core Lightning security release: Christian Decker described a forthcoming CLN v26.06.7 point security release, noting no vulnerability is known to be actively exploited. The project plans an embargoed release within about 24 hours, publishing binaries but withholding the source code for 14 days to slow any attacker from reverse-engineering the fixes. Once the source code is made available, CLN’s reproducible build system will let users verify that the binaries match the source code. Operators who prefer to wait until the source code is available to update should restart with the --offline flag (which stops the node from making or accepting peer connections while retaining onchain enforcement against potential cheating peers).

News

● Discussion on universal opt-in replay protection: Moonsettler posted to Delving Bitcoin to discuss the possibility of introducing an opt-in replay protection mechanism in case of future forks. The idea followed recent events in which a minority chain was subject to replay attacks, a type of attack in which a valid signed transaction on one chain of a fork is rebroadcast on the other, unintentionally spending the equivalent coins on both networks. The author proposes to use the taproot annex by committing a 34-byte payload that includes the previous block hash (i.e. <0xFAF0><32-byte-prior-block-hash>).

Discussion followed with Anthony Towns proposing to use the block height and a hash suffix of the block instead, so as to reduce the amount of data to 6 bytes. Moonsettler agreed on the approach and added that it would be valuable for nodes to annotate UTXOs with the block commitment to provide that information to users. The author also proposed a limit on new commitment depth, ideally the assumevalid height, and for nodes to keep track of the commitment for up to 100 blocks. Moreover, Towns proposed to add a mechanism similar to a maturity constraint by setting an explicit nLocktime to prevent a transaction from being mined before a certain number of blocks to account for block reorgs.
● HWI repository to enter maintenance mode: Ava Chow (achow101) announced that the Hardware Wallet Interface (HWI) project will scale back to maintenance-only work and eventually be archived. HWI, which lets Bitcoin Core and other software communicate with hardware signing devices, has been developed almost entirely by one person and has received little new development for several years. Chow said it achieved most of its original aim of bringing hardware wallet support to Bitcoin Core, but that its Python codebase has held it back from the goal, since it cannot be reproducibly built and bundled with Bitcoin Core.

Before entering maintenance mode, the project will finish its in-progress MuSig2 support and issue what is expected to be its last release. It will stop taking new features and support for additional devices, aside from MuSig2. Chow named BHWI, a work-in-progress Rust implementation from Wizardsardine, as a potential replacement.
● Request for comments on using block-range filters: Optout posted to Delving Bitcoin a request for comments (RFC) on a proposal to use block-range filters to reduce the total download size when using compact block filters. Instead of downloading all the individual block filters, filters for ranges of blocks could be created. If a script is found inside one of those ranges, the individual block filters are downloaded and the process works as described in BIP157. Although both range and block filters are downloaded for matching ranges, savings in size are obtained by avoiding downloading all the block filters in the other ranges.

Preliminary results seem promising. The author ran simulations using different range sizes on simulated data of around 30k blocks. Two different sets of scripts were used, one with a very low transaction count (4-6 transactions) and one with a higher one (20-30 transactions). The total block-range filter size decreases as the range increases. However, most of the savings are canceled when increasing the range too much. According to the author, the best trade-off seems to be found at 256-block range which reduced the total download size by about 70–80% for the tested sets of scripts.

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.3 is a security release of this self-hosted payment processor. Users are encouraged to upgrade, especially if their servers are shared by multiple users.
● Eclair 0.14.2 is a security release for this LN node implementation. It fixes payment failure and channel handling bugs (see Newsletter #418), missing channel reserve checks (see Newsletter #419), and on-the-fly funding issues (see Newsletter #419). It also limits resources consumed by gossip queries (see Newsletter #419) and pending incoming connections, and includes onion message and Tor configuration changes. Upgrading is strongly recommended because malicious nodes could exploit some of the fixed bugs. Operators should run bitcoind on the same machine as Eclair or connect through an encrypted, authenticated tunnel, and review the release notes for configuration changes.

Notable code and documentation changes

● Bitcoin Core #34075 incorporates a mempool-based fee rate estimator next to the existing confirmation-based block-policy estimator. The new estimator uses the chunk fee rates in the middle and at the last quartile of the next block for conservative and economical estimates, respectively. If there are too few transactions waiting for confirmation, it falls back to the higher of the minimum relay feerate and the mempool minimum feerate. By default, estimatesmartfee now returns the lower of the mempool and block-policy estimates, so mempool conditions can lower fee rate estimates but not raise them. The new fee_rate_estimator option can be used to get estimates based on just one of the approaches.
● Bitcoin Core #35730 adds a -rpcmaxconnections configuration option (default 16), which limits the number of clients that can simultaneously connect to its HTTP server (see Newsletter #411). Once the limit is reached, additional connections remain in the operating system’s socket queue without consuming application memory until a slot becomes available. Bitcoin Core can now limit and track the file descriptor usage of these connections, addressing a longstanding issue in which heavy RPC usage could exhaust the available file descriptors, causing unrelated operations to fail. This change also improves connection handling by accepting all queued connections up to the limit during each I/O loop iteration, instead of accepting only one connection per iteration.
● Bitcoin Core #35580 fixes a block template construction bug that compared a transaction chunk’s sigops-adjusted weight (see Newsletter #416), rather than its actual BIP141 weight, against the maximum block weight. The sigops-adjusted weight ranks chunks by effective feerate, while block validity separately constrains actual weight and sigop cost. Therefore, the previous behavior could have incorrectly excluded a sigop-dense, high-fee-rate chunk even when it satisfied both limits, thereby reducing mining revenue.
● Bitcoin Core #35665, #36025, and #35516 fix several issues when combining or joining PSBTs. The first fix addresses an issue when merging two global xpub records. Previously, Bitcoin Core grouped records by key origin (fingerprint and derivation path), even though PSBT serialization identifies them by xpub. This resulted in the same xpub with conflicting origins being serialized as duplicate keys, creating an invalid PSBT that the decodepsbt RPC rejects. The second PR fixes the analogous mismatch for tapscript records, which are grouped by leaf script internally but serialized by control block. Previously, the merge could create duplicate keys when one control block was associated with different scripts, or it could discard valid control blocks for the same script. The third PR resolves the issue of the joinpsbts RPC dropping the global xpub and metadata records by shuffling the merged PSBT in place rather than constructing a separate shuffled PSBT that omits some global metadata.
● Bitcoin Core #35933 and #34697 fix several MuSig2 PSBT processing and descriptor issues. The first PR prevents invalid or inconsistent MuSig2 derivation metadata from causing the analyzepsbt, finalizepsbt, and descriptorprocesspsbt RPCs to abort. Hardened public derivation now fails normally while a mismatched aggregate key is skipped so that another matching key can be tried. The second PR improves the detection of duplicate keys in descriptors by using the available private-key information to compare key expressions with hardened derivation during descriptor parsing. Previously, different expressions could both fail to resolve and be falsely treated as duplicates, which would reject valid musig() descriptors that reuse the same participants with different derivation paths. It also prevents a reused MuSig2 participant’s key origin from being prepended twice to taproot derivation metadata stored in a PSBT.
● Core Lightning #9374 fixes a channel state error that could occur when an earlier RBF attempt for a dual-funded channel confirmed instead of the latest attempt (see Newsletter #418 for a similar bug on Eclair). Previously, if the peer reconnected while Core Lightning was still catching up with the blockchain, it could assume that the latest RBF attempt was the one that confirmed and lock the channel to an unconfirmed funding transaction. Now, Core Lightning records the funding attempt that actually confirmed as soon as its block is processed and uses that attempt when reestablishing the channel.
● Eclair #3342 implements the option_onion_messages_only_channels feature bit specified in BOLTs #1343 (see Newsletter #416). When configured to relay onion messages only for peers with channels, Eclair now advertises this feature bit. When relaying for all peers, Eclair advertises the option_onion_messages feature bit.
● Eclair #3321 implements support for the optional fulfillment_payload field added to the update_fulfill_htlc message as specified by BOLTs #1344, extending attributable failures to successful payments (see Newsletter #416). Eclair can relay fulfillment payloads and authenticate them as part of the attribution data, and can decrypt them when it is the payer, but does not yet originate them when it is the payment recipient. The PR reports interoperability with LDK, which previously added attribution data to the successful-payment path (see Newsletter #364).
● LND #11008 fixes a deadlock issue in LND’s PSBT channel-opening flow. Previously, if PSBT funding verification and cleanup for a canceled channel reservation ran at the same time, each operation could wait on resources held by the other. This could cause LND’s single reservation handler to get stuck, preventing the node from opening or accepting channels and leaving newly funded channels stuck until a restart. The fix changes the order in which the shared state is accessed, preventing the two operations from blocking each other indefinitely.
● HWI #841 extends the displayaddress command to display on a hardware device an address for a registered BIP388 wallet descriptor policy, selected by address index and receive or change branch. The command accepts the registration information returned by the registerdescriptor command and adds support for BitBox02, Coldcard, Jade, and Ledger devices, building on the descriptor registration support described in Newsletter #419.
● HWI #849 updates Coldcard support to display single-signature taproot addresses on Coldcard Edge devices. It also preserves PSBTv2 format when signing with Coldcard firmware that supports it, instead of always converting the PSBT to version 0. The PR adds Coldcard Edge simulator coverage, restores single-signature transaction signing tests, and updates the tested Coldcard firmware to version 5.6.0.
● Rust Bitcoin #6755 fixes segwit v0 signature verification for transactions using nonstandard but consensus-valid ECDSA signature hash (sighash) values. Previously, EcdsaSighashType mapped those values to standard sighash types with equivalent ALL, NONE, SINGLE, and ANYONECANPAY behavior, losing the original value. Because the exact value is also included in the segwit v0 signature hash, this could cause Rust Bitcoin to compute the wrong sighash and fail to verify signatures from transactions that are consensus-valid and already confirmed. The new representation preserves the original value, while callers that require standard sighash types can continue using from_standard (see Newsletter #138).

Bitcoin Optech Newsletter #419 Recap Podcast

2026-08-25T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Bastien Teinturier, Salvatore Ingala, and spacebear to discuss Newsletter #419.

The Bitcoin Optech Podcast and transcription content is licensed Creative Commons CC BY-SA 2.0

Download audio

News

● Reorg vulnerability in LND channel closes (1:13)
● Draft BIP for `rawtr()` output script descriptor (1:14:36)

Changes to services and client software

● Payjoin Dev Kit (rust-payjoin) 1.0.0 released (55:33)
● Silent payments sender plugin for Electrum (1:21:41)
● Superscalar implementation announced (1:22:34)
● Cofund multisig wallet announced (1:24:57)
● Lexe adds human-readable addresses and LNURL-withdraw (1:25:55)
● Ledger Bitcoin app 2.5.0 adds human-readable policy descriptions (37:17)
● Bark 0.5.0 released (1:27:34)
● Bitcoin-PIR for private UTXO queries (1:28:16)
● OP_TEMPLATEHASH Ark demonstration (1:29:44)
● libshrincs formally verified hash-based signatures (1:34:00)

Notable code and documentation changes

● Bitcoin Core #32784 (1:38:08)
● Bitcoin Core #35797 (1:40:45)
● Bitcoin Core #35531 (1:44:14)
● Bitcoin Core #35889 (1:48:44)
● Bitcoin Core #35605 (1:51:06)
● Eclair #3352 (12:15)
● Eclair #3351 (20:31)
● Eclair #3345 (23:16)
● LND #8754 (1:54:23)
● LND #11065 (1:55:47)
● HWI #842 (1:57:04)

Transcription

Mike Schmidt: Welcome everyone to Bitcoin Optech Newsletter #419 Recap. This week, we’re going to be talking about a reorg vulnerability in LND; we’re going to talk about a draft BIP for a rawtr() output script descriptor; and then, we have a few items from our monthly Services and client software segment, that we have Payjoin, we have some Ledger updates, among others; and we also have no Releases this week, but we do have our weekly Notable code segment. This week, Murch, Gustavo and I are joined by some guests. We’ll have them introduce themselves briefly. T-bast?

Bastien Teinturier: Hi, I’m happy to be here. I’m CTO at ACINQ, I’ve been working on the LN, its specification, and Eclair, one of the implementations, for many years, and on the Phoenix Lightning Wallet.

Mike Schmidt: Salvatore?

Salvatore Ingala: Hello, I do Bitcoin stuff at Ledger.

Mike Schmidt: Spacebear?

Spacebear: Hello, I’m a maintainer of the Payjoin Dev Kit.

Reorg vulnerability in LND channel closes

Mike Schmidt: Awesome. Thank you all for taking your time to join us today and talk about your news and software updates that you’ve been working on. For listeners, we’re going to go a little bit out of order for our guests. We’ll start with the first news item though, which is, “Reorg vulnerability in LND channel closes”. Bastien, you posted the responsible disclosure of a vulnerability in LND, fixed back in February in version 0.20.0. But you work on Eclair. So, maybe you can explain what you found, what the impact is, and how you found it as well?

Bastien Teinturier: Yeah, and it’s interesting because it may be the last time we do that kind of thing; a vulnerability that was not found by AI. So, it feels quite low tech, it’s interesting. So, it was about a year ago when we were working on splicing, on some splicing stuff related to onchain confirmations, where we started a discussion about whether we needed to scale the number of confirmations that we wait for an onchain transaction, based on the amount in that transaction. Because initially, many implementations did that for channels. When the channel was big, we would wait for more confirmations than when the channel was small. But with splicing appearing, splicing made it more murky, because actually, if you have a small channel that then you splice to a bigger one or the inverse, an attacker could actually use the lowest of the two confirmations number that you use to attack you, basically. And we were questioning the fact that scaling confirmations made sense entirely.

At the end of the discussion, I came to the conclusion, and others seem to agree, that a static value was better. There was no need to scale for 12 or 13 confirmations with a weird mathematical formula based on the amount. And just using six, eight, or ten confirmations was good enough. And it’s a security parameter that we’re explicit about. If there’s a longer reorg than that, then there may be dragons and you have to make sure that it just doesn’t happen. Otherwise, it’s hard to protect from. And while I was looking at that, I was also making some tests around closing. And right after that discussion, I was doing an end-to-end cross-compat test between Eclair and LND for a new type of closing protocol. And I just ended up in an issue. It’s a new closing protocol that actually lets you RBF. And while doing that, I inadvertently found that LND was forgetting the channel entirely after only one confirmation. And I think I just messed up a manual test that I was doing and it gave me weird results, so I looked into it deeper and then I realized that, yeah, they were actually forgetting the channel after only one confirmation.

So, I reached out to Laolu, because I found a to-do in their code where there’s an explicit hard-coded one with a to-do for Laolu to fix that had been there for years. And they patched it quietly because at that time, you could patch things quietly without AI actually figuring out that you were patching a vulnerability. So, it took a while before we announced it, because they were also doing a lot of refactoring in that area. So, it took a while between the time I found the vulnerability and it was actually shipped to LND. So, that’s why we’re discussing on it now, something that was actually found, I think a year ago, around that time. And yeah, it’s interesting because it showed that this is something that you think you never mess up, that we all know that we need to wait for absolutely more than one confirmation, that it’s completely unsafe to wait for just one confirmation. But still, it can just slip in your codebase and you just forget about it, if you defer to later handling that correctly.

So, we’ve had a discussion on Monday at the Lightning Spec meeting to add a new PR to the spec to make sure that everywhere we talk about onchain transactions, we make it very explicit that you have to wait for enough confirmations all the time, regardless of a transaction. Don’t try to be smart and think, “Okay, that transaction is low value, so maybe I can do something more smarter; or maybe I can let the node operator configure a low-confirmation count”. That’s just a bad idea, just don’t do it. So, that’s it.

Mark Erhardt: Yeah, especially this year when we finally had a two-block reorg for the first time in almost 10 years or something; no, over 10 years, 12 years. So, yeah, you need to wait for more than one confirmation. One confirmation is not enough because one-block reorgs happen somewhat frequently; two-block reorgs about once every 20 years maybe. Who knows? Yeah, so the way I understood this vulnerability was when a channel gets closed, LND was just seeing the confirmation and then forgot about the channel ever existing. And if that happens on a reorg block, they would be unable to react to the channel counterparty broadcasting an old state in the reorg branch, and thereby stealing the entire funds – or if all the funds were on one side at some point, they could, without repercussion, steal the entire funds of the channel.

Bastien Teinturier: Yeah, exactly. And maybe what happened is that this happened because this codepath is for what we call cooperative closure, where the two nodes honestly cooperate to create a closing transaction that has no delays and everything; whereas they could also unilaterally close, which is the more nasty, faster scenario. And maybe since this is cooperative close, not much care was given to it, thinking that this is an honest scenario. So, we probably don’t need to look into it much, but you can actually turn a cooperative close into a unilateral close afterwards. So, there’s no path where you can be completely sure that your peer is honest. You should never trust them and always think that they could turn malicious at any point.

Mike Schmidt: T-bast, what does it mean to forget a channel? What are the mechanics like within Eclair or LND when a channel is forgotten? Is it like all records of that are purged from all data stores, or is it stop monitoring for certain activity onchain or in the mempool?

Bastien Teinturier: Yeah, it’s only the monitoring part, because I think everyone keeps a record of every channel, even after it’s closed, because it’s useful to remember channels that you had in the past with some people, for example, just for accounting. But it means that people stop watching the chain and stop watching for transactions that would spend the channel outpoint, thinking that it has already been spent, that it’s fine; but actually, it has not, and it could be spent by something else. So, you definitely need to continue watching the channel output. And I think that the most conservative behavior is, I think CLN (Core Lightning) is doing something where even if they’ve seen six confirmations of a channel spent, they still watch the output for 100 blocks, just in case something happens to be able to react. And Eclair, LDK, and LND just watch for the configured number of confirmations, which is six in LDK, eight in Eclair. And in LND, it seems to be still based on the amount. But yeah, I’m trying to get them to change that and just use a static value that is either six, eight, or ten, or configurable by the node operator, but never less than six.

Mark Erhardt: Yeah, 100 seems very conservative. Six seems very reasonable as a minimum.

Bastien Teinturier: Yeah, I think so too.

Mike Schmidt: T-bast, anything else you think folks should know about the discovery and disclosure of this one, and how Lightning nodes handle these sorts of things?

Bastien Teinturier: No, but on a related note about vulnerabilities as a whole, just a reminder to everyone that the past four weeks have been basically, everyone has been busy fixing bugs found by AI. So, you should be on the lookout for new releases of your software, and you should try to update as soon as possible because, yeah, right now is not a good time to stay on an old version for too long, because it’s become really hard to hide fixes or vulnerabilities. For example, this one was fixed in February and nobody discovered it and it didn’t seem to be exploited. But nowadays, if you’re not too dumb and you’re an attacker, you would scan every commit made to every codebase, asking an AI to search for vulnerabilities that were fixed in the commit. And even if you hide it, an AI will find it nowadays. So, you cannot assume anymore that people are able to covertly fix things in open-source software. So, you should upgrade as soon as there is a release that’s coming out.

If you’ve been looking, all implementations have been making a lot of minor releases for the past few weeks, and I think this is going to continue for the next few months. So, make sure you update whenever it comes out if you want your funds to be safe.

Mike Schmidt: So, maybe a slightly more aggressive updating for users. I’m curious if there’s something you’d like to share on the developer side of things. Like, obviously, you’re getting these reports and making fixes. Does that mean the release cadence in projects will be a little bit quicker, or are there other behavioral changes on the maintainer side?

Bastien Teinturier: Yeah, release cadence is increasing and I think we’ve been seeing that for all implementations. And coordination with the security disclosure has been really nice so far. It’s really nice that there are a few teams that are scanning Bitcoin projects using AI and giving funding a lot of tokens to allow that. And they’re providing very high-quality disclosures and reports. So, this is really nice. I think the process has gone very smoothly, way smoother than I would have expected when we started seeing AI finding vulnerabilities. So, this is really nice. And as a developer, it just means whenever you get something, maybe nowadays you’ve been a bit swamped by too many reports and it’s hard to pass, but it’s really important to make sure that you go through everything, that you answer to people who disclose the vulnerability, and that you fix everything because, yeah, this is an exceptional time. I think this is going to cool down in a few months. We’ll reach a stage where we fixed all the important things and we will be more careful and we will proactively use AI to make sure that we don’t introduce new vulnerabilities like that. But the next few months are going to be quite busy. But afterwards, it will get better, I’m pretty sure. So, just make it through that phase and then we’ll be okay.

Eclair #3352

Mike Schmidt: Good context and potentially a good segue to some of the Eclair PRs from the newsletter this week. T-bast, Eclair #3352, which I believe was the missing channel-reserve checks PR.

Bastien Teinturier: Okay, this one was actually found not by AI but by fuzzing, and it was just found that we were not exactly following the spec. So, we were a bit more lenient than the spec for some channel-reserve requirements. It isn’t an issue in practice, because it only happens if people accept very small channels with large dust limits, weird cases that other defaults in the implementations reject anyway. But yeah, Murch, you have a question?

Mark Erhardt: Yeah, could you maybe first say what exactly the issues were? You’re jumping into details.

Bastien Teinturier: Yeah, sure. So, when you open a channel right now, there’s a concept of channel reserve, where you cannot completely empty your channel by default. We make sure that each peer in the channel always still has something at stake in the channel, which means that they always have an incentive to publish the latest state. They always have funds in the channel basically. So, it’s a way to make sure that they have no incentive of trying to cheat when they don’t have any stake in the latest version of the channel. And this value is actually configurable. And in the spec, we make sure that it cannot be smaller than the dust limit, because the dust limit, contrary to Bitcoin, is something that you can configure on the channel. You can set a higher dust limit than the actual onchain dust limit to make sure that some small HTLCs (Hash Time Locked Contracts), for example, you could decide that your dust limit is 2,000 sats, and anything that is below that, you don’t want it to materialize onchain, even though you could potentially spend it onchain if the feerate was low. If the feerate is high, you actually can’t. So, you can decide from the start that you don’t want to materialize those, and then you keep your commitment transactions smaller. And the combination of using a large dust limit and a small channel reserve was a way for attackers to potentially make their output of a commitment transaction disappear and thus have no stake in a state of a channel.

In practice, since everyone has some same defaults where you don’t accept channels that are smaller than, for example, 100,000 sats, or even higher than that, and you don’t accept dust limits that are too high either, you cannot run into these edge cases. But we were allowing some edge cases if the channel was very small and the counterparty was using a large dust value. But that couldn’t happen with the default configuration values in Eclair, but it could happen if you tried to configure your node to accept very small channels. But yeah.

Mark Erhardt: I have a lot of questions. So, one of the criticisms with the channel reserve is that I think it’s, by default, 1% of the channel. So, often it is actually a very small stake compared to what could be taken by an attack. And this sort of ties in the argument whether LN-Symmetry without a penalty is safe or not. So, seeing people have more time to debate covenants now again, given that other debates might be subsiding, are you still excited about LN-Symmetry? Is that something that the ACINQ team would be looking forward to?

Bastien Teinturier: Yeah, I think so. Yeah, I would be I’m excited about that. And I honestly don’t think the channel reserve is a very good mechanism, because it hurts UX and it hurts channel usability. And I think it’s quite a weak disincentive. You can only play that trick once. Even if we didn’t use a channel reserve and you had a peer that chose to try to use a revoked commitment while they didn’t have any funds in the channel, and tried to game that thing, basically as long as you watch the chain, they can’t steal money anyway. And you can blacklist them and you can say, “I’m never going to accept or open a channel with that node anymore”. So, I don’t think we really, really need that channel reserve. I think it was a defense-in-depth mechanism, but I’m not sure the trade-offs are really worth it anymore now that we have mature implementations and we can detect that your counterparty is being malicious and blacklist them.

So, I would be more in favor of going the LN-Symmetry route, where you just react to whatever your peer puts onchain and there’s no need for a channel reserve for that. And you just make sure that in case they publish something, they still pay some onchain fees so they still have a cost. And most of the time, they will have been the one opening a channel to you anyway in the first place, so they will have paid onchain fees at that time as well. And if they want to empty the channel, they will have had to send payments through the channel to you. So, you will have collected routing fees as well. So, there’s a cost for the attacker; there’s benefits to you because you’ve earned some fees as well. So, I think this can be made good enough so that we don’t need the channel-reserve mechanism anymore. But that’s arguable. Maybe others disagree with that.

Mark Erhardt: Well, I know one person at least will disagree with that. But maybe that’s a debate we can have another time then. I have one more question. So, we haven’t had you on in a while, but late last year the default feerates dropped quite a bit. And I was wondering, talking about the dust limits and so forth, and you were saying at high feerates the dynamics change, I was wondering how much have Lightning dynamics changed by feerates dropping?

Bastien Teinturier: I’m not sure. What’s nice is that we haven’t had to feel the pain of a high-feerate situation basically. We’ve had time to fix a lot of force-close issues that started appearing when nodes disagreed on feerates. So, we are more ready to a high-fee environment than we were a few years ago. So, I think we should be more robust if a high-fee environment arrives today. The main thing that it has enabled, having a very low feerate, is that nodes have been very more aggressively reallocating liquidity frequently, basically. And activating on your node, we’ve activated on our node something that we’ve spent years debating whether it made sense or not, or would be just wasting money, basically algorithms and heuristics to constantly monitor our channels, decide where liquidity is needed and where liquidity is idle, and proactively close channels or splice channels and open new channels to proactively have liquidity where it makes sense. And this is something that we’ve activated in March or April, and it’s been running really well on our node. And what makes it very easy to be economically viable is that the onchain feerate is really low. So, it’s really easy to earn more fees by doing that with your routing afterwards than the fees you’ve paid for the onchain transactions.

If the onchain fee was maybe even 10 sat/vB (satoshis per vbyte), it would be already way too much for the frequency at which we move liquidity around. And by default, our algorithms stop if the feerate is too high. But that let us experiment a lot with that liquidity allocation heuristics, and that was really nice. And I think we’re not the only implementation that has something like that. So, it was really nice to have a low-fee environment for a long time. And it’s nice if it continues, except for miners and maybe security eventually, but at least it gave us time to make sure implementations were robust enough to work well in a high-fee situation, even though some things are still more annoying or less efficient if the onchain feerate is too high.

Mark Erhardt: Yeah, I see that TRUC (Topologically Restricted Until Confirmation) transactions have rolled out now too, to some implementations at least. Thanks for sharing details on what’s going on in the background.

Bastien Teinturier: Sure, my pleasure.

Eclair #3351

Mike Schmidt: We have Eclair #3351, which was the PR around on-the-fly funding fixes. Yeah, and this one was definitely vulnerabilities found by AI, but in a feature that nobody uses except us with Phoenix. On-the-fly funding is the feature we use when some Phoenix user is going to receive an HTLC but they don’t have enough liquidity. We have a feature where we on-the-fly create a new channel or splice the existing channel and negotiate fees with the Phoenix user before accepting the payment. And since we also use zero-conf, we can increase the size of the channel with the zero-conf splice, and then forward the HTLC through. And there were a few edge cases in there where malicious Phoenix users basically could have stolen funds from us. All of those are quite nasty edge cases. You really have to look at the code deeply and figure out a way of stopping the protocol at some point, and then restarting and abusing it in some ways. But there were bugs. There were things that we should have caught and we could have caught without AI if we’d been smarter, basically. But it’s really nice that AI caught them and gave us an opportunity to fix all of those.

Since it’s a feature that only our node uses, it was easy to just patch our node and then do a commit on master, because then we don’t care if an attacker discovers the issue, it’s already been patched on our node. And there was no issue on the Phoenix side. It was only Phoenix that could be malicious and steal money from our node, and it hasn’t been the case, we haven’t lost any funds with that. But we’ve still put this feature on master, because a few years ago, there was a somewhat equivalent protocol that was created years ago for LSPs (Lightning Service Providers). I think it was called LSP Spec-something. There was an effort to create LSP standards. And at the time, we explicitly said that the Lightning protocol was not ready, and the way they were doing it was not a good long-term idea. And I think it was three years ago that we sat down together and I convinced them that it should have been done differently. And on-the-fly funding is the protocol that should be used onwards by all implementations when they want to do on-the-fly funding with an open LSP spec.

But I think that right now, LDK has been working on an implementation but has not shipped it yet. And nobody is actually running Eclair with that feature on. So, that’s why it felt safe to just publish it on master without trying to hide it.

Eclair #3345

Mike Schmidt: All right. We can move to the last Eclair PR, which is #3345. This was around gossip query resource limits.

Bastien Teinturier: And I think there have probably been a lot of similar PRs in all implementations, because gossip is basically the part of Lightning that nobody loves. Everybody says, “Yeah, we’ve done that thing. It was the easiest way to get the job done, but it’s not elegant, it’s not efficient, and we should rework it entirely and just drop everything we have at some point”. But the nicer way to do it in the future, we’ve never been able to find the right set of trade-offs without adding too much complexity. It’s been progressing recently. But still, it’s going to take time before we can entirely remove the existing gossip protocol. But that gossip protocol gives a lot of opportunities for abuse basically and for DoSing parts of your node, and every implementation had issues with that. So, this is basically getting rid of a lot of those potential DoS vectors that could be abused by attackers.

In Eclair, we have something that I don’t think other implementations have, is that we have a cluster mode where you can actually run Eclair on multiple machines. So, there’s a backend machine and frontend machines, and you can elastically increase the number of machines you run in the front. And all the gossip is managed at the front, so you are somewhat resistant to DoS, but just up to a point. If the attacker still has way more resources than the number of machines that you are ready to throw at the problem, they can still DoS you. And in this PR, we’ve basically batched a lot of fixes around gossip that were found by AI. And we knew we had them for years, and we always thought, “Yeah, but nobody is going to bother exploiting that. It cannot be used to steal funds”. At least most of them cannot, because in Eclair, the gossip part cannot take up all of your CPU and all of your bandwidth. You will still be watching channels and making sure that you react to channels being closed. But still, it can prevent you from running your node efficiently and relaying payments efficiently. So, it was high time we fixed all of these.

Mike Schmidt: Yeah, we had Gustavo, who covered the LND adding similar protections a few newsletters ago, and then some, I think it was last year. And then, we even talked about rate-limiting, relay and Bitcoin Core, I think it was last week. So, I guess similar-ish kind of handling on the L1 side. Yeah, Murch?

Mark Erhardt: I was wondering, could you maybe tell us in a few sentences how the gossip protocol has been evolving in order to improve?

Bastien Teinturier: Not much! That’s the issue. It hasn’t been evolving much. So, we started with a very dumb, very easy gossip protocol, where there’s an announcement for every channel, and then each side of a channel can make an update for their fee parameters basically. When the channel is created, you announce it with this channel announcement. It happens only once. It can rehappen afterwards if you do a splice, then you can announce that splice. But channel announcements are things that don’t happen often. But channel updates are things that can happen often, because you update your fees if you see that you are not attracting payment enough, or attracting way too many payments and could earn more money. And initially, we just started with a very dumb protocol where on connection, you can tell your peer when you connect to them, “Please just dump everything, send me everything”. So, this is the first issue, because if, as the other node, you accept sending all of your gossip to anyone who connects to you, you use a lot of bandwidth potentially and people can abuse that. So, you have to limit how many people can be asking for the whole gossip from you. And then, the other mechanism is that whenever you receive new gossip, you queue everything for 30 seconds; and every 30 seconds, you send the new gossip you recently received to all of your peers. And that part is actually what works well enough and what guarantees that usually, you don’t need to have a full sync at the beginning.

But then, to be more efficient, we added two extensions to gossip that were called channel queries. I think both of them were gossip queries and gossip queries extended. And those are somewhat slightly more complex messages where you can say, “Send me the gossip that happened between that block height and that block height”. But actually, that protocol wasn’t very well designed, and it’s really hard to implement, while handling all the edge cases, where an attacker doesn’t behave according to the spec and actually asks you for redundant things or overlapping ranges, that kind of stuff, and they can make you waste bandwidth that way. So, that’s the things we’ve tried to fix. But overall, this whole protocol is quite prone to abuse, because there are a lot of edge cases in the way it was designed. It helped up to a point. It helped us get rid of, “Just dump the whole graph on connection”. We can be a bit smarter and dump less than the whole graph. But it’s still way too noisy and wasting way too much bandwidth compared to what we could do if we were really smart. But nobody really wanted to tackle that problem, because that was basically a low-priority issue. It still works, and as long as everyone is honest, it doesn’t use that much bandwidth. But it only becomes a problem when too many people start being malicious and start trying to attack your node, which is something that we may see happen now.

So, it becomes more important that we fix these things, and potentially move to a different gossip protocol that makes more sense and is more DoS-resistant.

Mark Erhardt: This was reminding me of some discussions I had with Sergio about Erlay over the years, and I was just wondering, since there are frequent gossip updates and the gossip also has to traverse the entire network, but each peer only wants to tell the other peer if they don’t know about it yet, would there be some sort of potential to use something like Erlay to just reconcile what you would be announcing to each other instead of sending all the data?

Bastien Teinturier: Yeah, definitely. And there was some effort, I think even five years ago, looking at Erlay and figuring out how we could use sketches like that for our Lightning gossip. We had early designs, but nobody actually wanted to spend enough time to ship it. But very recently, I think this year, it started, JHB, Jonathan Harvey-Buschel, started working on that again, and he’s made some progress. He’s shared where he was at, so this is getting revived. And maybe with the rise of people trying to DoS nodes, people will prioritize that more. I think one of the reasons people were reluctant to touch gossip is that we only wanted to change gossip when we also had an opportunity to include taproot channels, which we couldn’t include before; and also, to avoid pointing in our gossip at the exact onchain outpoint for the channel, because this is a huge privacy leak, and we’ve always said that we need to fix it at some point. But the issue is that nobody wanted to touch that gossip to do only part of the things we wanted to do. And everyone said, “Oh, we should take this opportunity to do everything”, but everything was way too much, so we actually never did it.

But I think there’s some progress and we are potentially more ready to accept that we’re only going to do part of the thing, like do the sketch-based reconciliation, without yet removing the link to the onchain outpoint and maybe doing it in another phase. So, I don’t know. It really depends on what other implementations also want to do. But I think we may actually see this progress and potentially ship in the next couple of years. I hope so, because it’s a much nicer way of handling gossip, and it’s cool math. So, it’s cool.

Mike Schmidt: We covered the Gossip Observer and JHB’s work in Newsletter #396, and we actually had JHB on to talk about that and the equivalent podcast as well. So, if listeners are curious as to what t-bast and Murch are talking about, you can dig into that a little further. Anything else? Any other Eclair things that are interesting since we have you on? Phoenix?

Bastien Teinturier: There’s a lot of things happening. I think, for the past four weeks, us and all other implementations have mostly been able to ship a few specification stuff. For example, the fulfillment payload mechanism that LDK and Eclair worked on. That’s interesting and that’s something that is shipping and that will be helpful in the future. But apart from that, we’ve mostly done bug fixes and defense-in-depth, and making sure that we remove technical debt in many places in the codebase. But yeah, that fulfillment payload is interesting. In a nutshell, we had a mechanism when you send an error. So, payments in Lightning are onion-encrypted, so it goes through multiple hubs and every hub has an encryption layer for them. So, when you have a sender and you receive a response, anyone in the path could have potentially modified that response. And for our messages, what we do is that the recipient creates an error encrypted for the next node; the next node re-encrypts for the node before them, and before them, and before them. And then, if everyone was honest on the route, the recipient is able to decrypt an error message that comes from the recipient to figure out if the payment reached the recipient, and why it failed. But anyone on the route could actually modify that and you wouldn’t know who modified it, so you cannot 100% rely on it.

But then, one or two years ago, Joost studied an interesting protocol addition that’s called attribution data, where you also include a ton of HMACs (Hash-based Message Authentication Codes) basically for many combinations. And if someone cheats along the route, as the sender, you are able to discover which pair of nodes is responsible for dropping the error. So, potentially, you can decide to just ban these two nodes, and this way you’re pretty sure that you’re going to avoid malicious nodes in the future. And at that point, we realized that we were sending a message back from the recipient to the sender only for failures. But it actually also made sense to do the same thing for fulfills. When the payment actually succeeded, it actually makes sense that atomically, while sending back the preimage to the sender, you can also include just a blob of data that could be reused by many applications. For example, one of the applications that wanted to use that was zaps that would get all the way to the sender. And we never did that before because we didn’t have a mechanism. We couldn’t rely on it and we had no mechanism to figure out which pair of nodes was potentially tampering with that data or dropping it. But combined with attribution data, it’s actually a handy way to get data back from the recipient when the payment succeeds in a way that is not 100% reliable, but can be used in potentially many cases, at least in happy cases, and can improve UX.

Mark Erhardt: Right. So, when the data comes back, you know that it is authenticated and it must have come from the recipient. When the data does not come back, it is sometimes difficult to assign exactly where it failed. But now, with attributable data, you know that it was a specific hop. So, either the node before or after the hop, right?

Bastien Teinturier: Exactly.

Mark Erhardt: So, you can narrow it down to the pair, but you can’t assign which of the two?

Bastien Teinturier: Exactly. Having that is really interesting because if we didn’t have that at all, people could cheat without being detected. So, they potentially had an incentive to continue cheating and they would not get caught and they would stay in payment paths. But now that you can narrow it to two nodes, if everyone starts actively routing around these nodes, eventually they lose a lot of traffic. So, it incentivizes everyone to just be honest. And if everyone is honest, the feature works perfectly, and you are able to get data back from the recipient on fulfills. So, this can be interesting, and it’s a kind of general mechanism where for now, we’re just transmitting a blob of bytes that can be used for anything in the future. So, that’s the only interesting feature that was shipped in the past month between implementations. And the rest, if you look at it, is mostly defense-in-depth, bug-fixing, DoS-resistance, and hardening all implementations, which is a good thing to do, because we always say that it’s a good thing to just pause, do less features, and more hardening and making sure that nodes are more reliable and secure.

Mike Schmidt: Yeah, and of course it’s not just Lightning implementations. I saw BTCPay Server posting similarly that the next few releases or so are going to be focused on cleanup, hardening, security, these sorts of things. T-bast, thanks for walking us through those PRs and the News item. We appreciate your time.

Bastien Teinturier: Thanks for having me.

Ledger Bitcoin app 2.5.0 adds human-readable policy descriptions

Mike Schmidt: Yeah, cheers. We’re going to jump to the Changes to services and client software segment for our next two guests. First one, “Ledger Bitcoin app 2.5.0 adds human-readable policy descriptions”. Salvatore, you’re here to represent this item. Tell us about 2.5.0 and maybe just quickly, what is the Ledger Bitcoin app? And then we can get into the features in here.

Salvatore Ingala: Well, yeah. The Ledger Bitcoin app is the application that runs on the device. So, whenever you send a transaction with the Ledger device, like for each cryptocurrency, there are separate applications. So, in the Ledger system, there is a distinction between the OS and the applications. So, the firmware is not monolithic. And so, all the features that are relevant for Bitcoin are implemented in the Ledger Bitcoin app, which is what I work on. And yeah, in this release, finally, I had the first version, which will not be the final version, but it’s the first version that I’m comfortable releasing, which I think also the UX is good enough and it will be a good improvement, and I can release in a version that gives me some comfort about some potential risks of implementing this feature. And we can talk about why this feature is not trivial to implement.

So basically, for any wallet that is not a single-signature wallet, whether it’s multisignature or something more complicated, like miniscript, all hardware wallets require an additional step, which you do only once, which is the registration of this descriptor or wallet policy on the device, which basically allows to teach the device exactly how that wallet works and how the addresses for the wallet are generated. And this is an important step in terms of security, because that descriptor or that wallet policy describes exactly what all the addresses of that wallet are. And so, if you send money to an address which is not derived by the correct script, or money goes elsewhere, then you will not be able to spend. And especially in the case of miniscript, it’s more complex than for multisig, because there could be more complicated schemes of how you’re protecting your funds. So, you could have alternative spending paths. So, you could have, for example, one primary policy, which is a 2-of-3; but then, you have some recovery path, which is a 1-of-3, but it’s only active after six months, something like this. And you can make arbitrarily complicated schemes.

We have seen a bunch of wallets and companies that are kind of pioneering these kind of schemes, like there is Liana, of course, which specializes exactly in this scheme, where you have a primary spending path and you have a recovery path. There is AnchorWatch that is using miniscript to provide a wallet that, together with the wallet, they provide an insurance service on the funds. And there are a few more. There is Keeper and there is Nunchuk that are mobile wallets, and probably a few more. So, I apologize for anybody I’m not mentioning. At this point, there are several. So, all these wallets provide these innovative features. But from the point of view of hardware signing devices, what we care about is that nothing can happen that the user is not aware of. So, we have what is called Clear Signing. So, whenever you sign something, you know exactly what you’re signing. And in the case of the registration of multisig or miniscript policies, well, there is another aspect, which is we want to know exactly that what you’re registering is what the user intended. Because the registration step is something that you do only once before you start sending funds to the wallet. So, if you do it incorrectly and you send funds to the wrong wallet, you might discover it later that something went wrong.

So, there are two potential risks here. One is in common with multisig, and one is more specific to miniscript. So, in the registration step, for something like multisig, the only thing that matters is that you have the full backup of all the other xpubs that are involved in the multisig. So, the cosigners will share with you an xpub, and you will register those are part of the wallet policy. So, it’s not enough to have enough cosigners to be able to satisfy the policy, but you also need to make sure that you have a backup of the policy. So, you need to have all the xpubs.

Mark Erhardt: Maybe let me jump in here briefly to just explain this. If you have a multisig that is hash-based, the output script only commits to the hash of the input script or the underlying spending conditions, and it’s not revealed onchain. So, if you do not have the backup of the xpub with all the public keys, even if you have enough signing keys, so let’s say we have a 3-of-5 here and you have three of the signing keys, but you don’t know the public keys for the fourth and fifth key, you would be unable to reproduce the spending script. And thereby, you would be unable to spend your funds because you cannot show what the script was under the hood that you would be signing for, even if you can sign for it.

Salvatore Ingala: Yeah, thank you. And yeah, so with other signing devices, we are in an adversarial setting where we don’t trust even the software wallet that is setting up the actual registration on the device. Because here, a potential attack that we’ve not seen happening in practice, but of course, with more people using these schemes, we might in the future see happening, and so we want to think about this in advance, is that malware could replace even just a single xpub of your wallet. And so, when you have a backup of a descriptor, but then one of the xpubs is wrong, because you didn’t check it compared with what you saw on the screen, at a later time when you try to recover from your backup, the funds are not exactly in the same place where you thought they were going, and you don’t have a backup at all.

Mark Erhardt: Right, so basically, on display in your computer with your companion app, it shows you, “Yes, absolutely, I’m using the wallet that you have been inputting”. But then, what it sends to the hardware device over cable would be a modified output script. For example, you said a 1-of-5 instead of a 3-of-5. And because the hardware signers have such a limited interface, you need to verify what the hardware signer received and look at the display of your hardware signer to verify that what it is registering is what you intend for the hardware signer to participate in. Because otherwise, the companion app, if it is malicious, could make you think that you registered something else than your hardware signer actually sees.

Salvatore Ingala: Yeah, precisely. And for simple multisig, the only ambiguity, apart from the threshold of course, 3-of-5 or 4-of-5, the user is likely to notice if a number changed. So, the only real ambiguity that is kind of easy to trick a user is on the xpubs; while for miniscript, when you register a miniscript wallet policy on the device, it shows two things. First, it shows the general structure of the spending policy, which is what are the different spending conditions. And then, it shows you all the xpubs. So, the second part is the same as for multisig, while the first part is specific to more complicated schemes, because you could have many alternative spending paths. And so, until now, what was shown on the screen was what BIP388 calls the descriptor template. So, probably more people are familiar with the descriptor. The descriptor template is just the descriptor template once you strip all the xpubs out, and that helps to make it a little bit more readable already. But still, once you start using more complicated miniscript, potentially with multiple spending policies, with several recovery paths, this starts to become bigger, especially on taproot. And so, this stream becomes hard to read. Even for technical people, it’s actually not that easy to read. And definitely for non-technical people, we can tell them to compare with their backup. But if the backup is already wrong, because the wallet policy means something else which is not what they intended to register, they might not notice. So, this is kind of a potentially increased risk that we don’t have with multisig and we want to address.

So, what this new release does is a feature that only works for taproot miniscript. There is a number of reasons why it’s actually much easier to solve this problem in practice on taproot. And so, for a number of patterns that are common for taproot miniscript policies, it explains all the alternative spending paths in a clean way. And so, it will list all of them. So, there are some screenshots in the post that is linked in the Optech. It will list all the alternative spending paths in a human-readable way. So, it will tell you, like, one of them is a multisig 2-of-3; if there is a timelock, it will tell you how many blocks or how long in the future will be, so there is a clear description. And so, there is quite some work that people don’t see that doesn’t necessarily matter this much for this release of the app. It might matter more for a future version of the app, because right now the app shows both the clear text description and the descriptor template. So, the instruction for the user will still be to compare with their backup the descriptor template.

But one thing that I was worried about is that the moment you start to show the clear text, people might be more likely to skip the second step. And for a future version, it might actually be interesting if we could actually keep it secure even if they don’t check the descriptor template, they only check the meaning of the policy. So, this is a challenging problem because one risk that we didn’t mention is that it’s not only a problem if malware changes the policy with something that is a completely different policy, but there could be a very large number of policies potentially that have exactly the same meaning; so, the script onchain is completely different, but the actual meaning is the same. So, the moment you show the clear tech description of the policy, what they see on screen is basically the same, or it could be actually exactly the same. But there are potentially a very large billions of scripts that actually are different onchain, but they have the same meaning.

So, some work that was done in the published crate, which is experimental, it’s not production-ready, but was good enough for me to convince myself that this risk is bounded on the kind of policy that we are showing clear text for, is that for those policies, I actually can estimate how many descriptor templates will have exactly the same clear text policy. And there is a grid that actually can enumerate all of them. So, we know that if the user knows the meaning of the policy, even if they lost the descriptor template, we will be able to brute force all the possible policies and find which one. So, this is not something that the app does or needs to do. But knowing that the recovery tool is available, for me, I don’t feel comfortable releasing the feature without having that, let’s say. And so, for a future version that might potentially make it safe to not show the descriptor template at all, I decided not to try this approach for now, because you cannot do that without opt-in from the software wallets, because you want the software wallets to also show the same thing.

So, I think we can get, let’s say, 80% of the UX benefits of the feature in this version that does not require any change in software wallets, and it already vastly improves the experience of the users. Because the nice thing of the registration in miniscript policies is that you only do it once. So, it’s actually a very small amount of time in the whole lifetime of your usage of the wallet. But it’s something that you have to do at the beginning, right before you start using your wallet. So, especially for non-technical people, it can be a scary step. So, making the UX better and more friendly in this part, I think it matters a lot and it might convince more people to use these kind of schemes that are actually much more secure in practice.

Mark Erhardt: Yeah. I was wondering, with UX-focused changes like this, do you do user testing? Do you put this in front of some potential Ledger users and see how they interact with it?

Salvatore Ingala: I mean, mostly my user testing was pestering Liana team and pestering Rob to show the feature and everything. Yeah, and that’s why also this version of the feature, I’m much more comfortable releasing it, because it’s just a clear improvement in the UX, and we can still change it if people suggest improvements. Because it doesn’t require coordination with any other wallets, we can still improve it after we see how people use it, if they find it comfortable. Like, if there are things that people find confusing, if there are some other ways of presenting the same things, like I made quite a few iterations on how we present these things to the users. This is one thing that with byte-coding becomes nice, you can easily rewrite prototype things. So, I probably had ten different versions that I went over and over changing things before I decided, “Okay, this is the version”. And so, I’m quite convinced that the UX is much better and is pretty good. It’s not perfect probably, we’ll see, and there is definitely room for improvement, and we will definitely improve in the future.

I mentioned already that it does not cover all miniscripts. That’s kind of a problem that I don’t know if it’s solvable to cover all miniscripts, but I think it will cover the vast majority of the miniscripts that people are already using in practice. And we can always extend the coverage in the future with more policies. So, the reason this problem is actually easier to solve on taproot is precisely because on taproot, people naturally will tend to put the alternative spending paths in different leaves, which make the typical leaf quite small. So, the typical leaf often, with a few more exceptions, but typically it’s either a single-sig or a multisig or a MuSig now, or these things with a timelock. And there is not much more that you might want to do in a single leaf, generally speaking.

Mark Erhardt: Although there are reasons to use an IF statement occasionally.

Salvatore Ingala: Yeah, sure. But actually, I’m not sure if any of the miniscripts that would have the IF statement is covered in clear text actually, because they don’t occur a lot in practice.

Mark Erhardt: Don’t undermine me now, but yeah, I know. Thanks for keeping me honest! It was more meant as a joke.

Salvatore Ingala: Yeah, I should check, actually. I don’t remember if any of them, because there are several fragments that have the OP_IF inside, and I don’t remember if any of them is in any of the patterns that are covered by the current scheme. But yeah, I think we covered most of the things that were to be said.

Mike Schmidt: Salvatore, are you familiar with the Cofund multisig wallet?

Salvatore Ingala: Not a lot, actually. I’ve seen it on Twitter, but I didn’t dig it exactly into the details.

Mike Schmidt: We cover it later in the newsletter and just wasn’t sure how much you were aware of that, just since it was a similar-sounding policy-based taproot architecture.

Salvatore Ingala: Yeah, I think for policies there, they mean something like cosigner policies, which is not the same meaning as wallet policies here, because wallet policies here are passive, meaning once you define the wallet, it’s done; while that one is for a cosigner, it’s online and it checks your transaction before signing. That was my understanding.

Mike Schmidt: Makes sense. Salvatore, I guess the call to action, since this is released, is if folks are using the Bitcoin app to update, and if there’s somebody who tinkers around and wants to create a new wallet, go for it. And obviously, new users that would go through that flow will just probably not be listening to this, but they’ll get that benefit?

Salvatore Ingala: Yeah, for users, if there are any technical users who see this, of course any feedback on potential improvements is appreciated. And for developers especially, well, look it up and try it out and see how it fits in your wallet because, yeah, potential future versions might need opt-in from wallets. So, if you’re interested in this kind of development, please do reach out and let me know.

Mike Schmidt: Awesome, Salvatore, thanks for joining us. We appreciate your time. We understand if you have other things to do, you’re free to drop. Cheers.

Salvatore Ingala: Always a pleasure.

Payjoin Dev Kit (rust-payjoin) 1.0.0 released

Mike Schmidt: We’re going to jump to the Payjoin item, Payjoin Dev Kit 1.0.0 being released, and we have spacebear here to talk about that a bit. Spacebear, the Payjoin Dev Kit project, you shipped your first stable 1.0 release. Congratulations. You can come here and do your victory lap. But maybe before you do that, maybe remind listeners what Payjoin is and how Payjoin Dev Kit fits into that ecosystem, and then we can get into what’s all in that 1.0 release.

Spacebear: Thank you. Yeah, I’m happy to be here. So, Payjoin is really the simplest form of interactive transaction construction between a sender and a receiver. If you add a round of interaction, you can build a transaction together before broadcasting it. And this basically allows the two parties to consolidate their transaction intents. So, for example, as a receiver, I could consolidate some UTXOs of mine while I receive a payment from a Payjoin-supporting sender. Alternatively, I could do something like do some output substitution to essentially, for example, if I have a Lightning wallet, I could fund a Lightning channel by substituting the output script. And then, I don’t need to have two separate transactions, where I first fund my Lightning wallet onchain and then open a channel in a separate transaction. So, yeah, that’s kind of Payjoin at its base level. And then, if you carefully construct that transaction, you can also break the common input ownership heuristic. Essentially, all the inputs in that transaction don’t belong to the same owner, which is a very common heuristic used by chain analysis companies to essentially create these clusters of outputs. Yeah, Murch?

Mark Erhardt: Yeah, maybe even more general, a Payjoin is a transaction where the sender and receiver construct a transaction together and they both contribute inputs. So, it’s sort of a very simple multiuser transaction.

Spacebear: Yeah, exactly. So, that’s the fun thing, is the input contribution is kind of optional. Like, you could do something as simple as just substitute the output script, and then you don’t even need to contribute an input. So, in the case where you want to, for example, do a funding channel or even do like an Ark funding transaction, you could do that and just substitute the output script. And then, in this situation, there’s not actually any new inputs being added to the Payjoin.

Mark Erhardt: Oh, that’s cool, I hadn’t even considered that. Basically, you just do the transaction cut-through portion of it. So, instead of making another transaction that spends the output that you receive in the first payment, you immediately make your second payment, but you don’t even contribute an input.

Spacebear: Yeah, exactly. So, yeah, like you call it, it’s a transaction cut-through use case. It’s a pretty cool use case. But as far as when people talk about Payjoin, in most cases they’re talking about receiver as an input. It’s kind of like the simple Payjoin use case. So, yeah, because this transaction construction is interactive, the Payjoin Dev Kit tries to abstract away a lot of the internal validation and other operations that each party needs to take. And one big part of that is the ability to resume sessions or survive restarts, or your counterparty going offline and then being able to pick up where you left off. And also, the ability to tell, “Is the ball in my court?” if your server went offline, or if it’s the counterparty’s turn and you’re just waiting. And with BIP77, this can be implemented without having to actually run your own server. So, the server part is delegated and both sender and receiver don’t have that liveness requirement or that online requirement.

Mark Erhardt: Right. So, this is the third coinjoin proposal that we track in the BIPs. BIP79 proposed Bustaay; 78 was the synchronous payjoin; and 77 is the asynchronous payjoin, where the server is a third party, an untrusted third party, that is used to facilitate an asynchronous communication, where the payjoin provider or the recipient doesn’t have to run their own server. So, for people following along, the numbering is odd here because it counts down rather than up in a sequence of time. So, maybe since the asynchronous part is the cool thing, could you elaborate a little bit on how 77 works differently than 78?

Spacebear: Yeah. So, 78 was a pretty naïve implementation in that essentially, the receiver just ran a server themselves, and then there was some communication between the sender and the receiver that was going through that server, which is simple enough to implement, especially in a use case like if I’m running my own BTCPay server instance, I’m already running a server. So, it’s just adding functionality to that existing server. But for mobile wallets or just even a desktop wallet, where you’re not necessarily running a receiver or you’re a less technical user, you won’t be able to run a server. So, BIP 77 delegates that server responsibility and now you have an untrusted third-party server. And it essentially just passes messages back and forth between the sender and the receiver. It uses two open standards. The first one is HPKE (Hybrid Public Key Encryption), which essentially encrypts all the data that goes through the server, so the server can’t see the contents of the message; and the second standard is OHTTP (Oblivious HTTP), which obfuscates the source and destination of the messages, so the server can’t see who’s sending messages. And it accomplishes that via kind of like a one-hop tour. So, there’s another relay server that stands between the directory and the client.

So, one other library that we may maintain with the Payjoin Dev Kit is what we call the mailroom. And so, the mailroom is one binary that combines the directory and the relay. So, you run that one thing and now you’re reachable as both a relay or a directory. It has some loopback protection so that if someone tries to use the same mailroom instance as relay and directory, it will block that because that defeats the purpose of OHTTP. So, yeah, the idea is to have many mailroom instances, and you can just kind of pick and choose which ones to use as relays and which ones to have as directories.

So, yeah, for the first release, I mean really what the bulk of this release is, is having a commitment to the core payjoin state machine, meaning that a session that you started today, if you upgrade the software version, you’ll still be able to replay those sessions in future versions. And so, a lot of that work happened over the last 18 months or so. And we had prior versions that implemented early versions of this persistence, but a lot of the kind of edge cases outside of the happy path, that’s where the bulk of the work was, getting graceful error-handling and kind of easy UX where you can resume a payjoin and no, like, “Oh, maybe I should cancel this payjoin now and broadcast the fallback transaction”. So, the fallback transaction is just like a naïve regular Bitcoin transaction where the sender pays you; so, having these kind of easy-to-use checkpoints for implementers, where you know what the state of the payjoin is and what you should do with it, even if something went wrong.

Mark Erhardt: Right. So, maybe tell us a little bit about how the Payjoin Dev Kit would be used by, I presume, wallet developers?

Spacebear: Yeah. So, currently we have Bull Bitcoin Mobile and Cake Wallet that are actually using the Payjoin Dev Kit. And so, the Payjoin Dev Kit, so we have rust-payjoin, which is the core library, and that’s where we just released the 1.0. It’s actually rust-payjoin. And then, we have language bindings for Dart, Python, C#, and JavaScript that are supported now, and we plan to add more. But so, both Cake Wallet and Bull Bitcoin Mobile are using the Dart bindings. So, if your wallet uses any of these languages plus Rust, then you can basically grab the payjoin package that’s on those languages’ respective package manager sites, and then you can plug that into your wallet. So, I feel like the way to do this today is to give your cloud instance the link to the payjoin library and tell it to go vibe code a draft implementation. The nice thing is that because the type state machine is very strict and it’s all validated in Rust, there are very few footguns that are still actually viable for an implementer, because there are all these checks that are mandated. And so, even in a kind of vibe-coding scenario, of course with review, but all these checks are mandated, so you’re not going to, like, skip a crucial payment amount check or something else like that.

Mark Erhardt: So, does it come with an implementer’s guide or something, or is the BIP the implementer’s guide?

Spacebear: Yeah, right now we have a reference implementation, the payjoin-cli, which is essentially like a plugin on top of bitcoin-cli. So, if you have a bitcoin-cli wallet, you can just install the payjoin-cli tool, and that gives you additional send-receive commands that support payjoin. And the goal with that is to serve as a reference implementation that has all the best practices and demonstrates those edge case paths, like canceling or broadcasting a fallback transaction, and all these other things. Another thing that we’re focused on now is actually writing up case studies on how other wallets use PDK, like Bull Bitcoin Mobile, and coming soon is more exchange integrations; so, for always-online servers, how to actually implement this safely.

Mark Erhardt: So, let’s say I had a wallet that supports payjoin and I’m interacting with a recipient that supports payjoin, how would they discover that they could do a payjoin?

Spacebear: So, I mean, assuming the payjoin setting is on, essentially it’s a parameter in the Bitcoin URI. So, you have your regular Bitcoin URI with the address and maybe the amount, and there is an additional parameter in there, that’s PJ, with the URL of that server. So, in BIP77, it’s the directory URL. And then, it also encodes some additional parameters like the public key, the receiver public key, and yeah, all the parameters necessary to do that communication via the directory.

Mark Erhardt: Right. So, when you read the QR code or copy the URI that the exchange or whoever is providing you, your wallet would parse and see, “Okay, here’s the bog-standard payment that I could make. And if I want to do something more complicated, like join into a payjoin, here is the web directory that I should be contacting through a mailroom, and I should encrypt my messages to that recipient public key”, and then I could start negotiating a payjoin?

Spacebear: Yeah. And ideally, most of that complexity is abstracted away with good UI. So, already, if your wallet doesn’t support payjoin, it will just ignore that parameter. If your wallet does support payjoin, it should autodetect it, and then maybe there’s some user configuration where you have a preference for privacy or a preference for consolidating UTXOs. And there’s all these cool preferences that could be built in as well.

Mark Erhardt: I do see a future in which a user looks at, “Hey, I tried to pay my exchange and what the heck is this transaction?” But I mean, that’s maybe a good problem to have.

Spacebear: Yeah, a big part of it is definitely getting good UX in it, and that’s also where having this persistent state machine helps, because you can easily replay a session and even go back to a checkpoint. And so, it’s very easy to get back to previous states and be like, “Okay is actually the amount that was getting transacted. These inputs are mine, these outputs are mine”. But at the end of the day, it’s a lot of UX and UI work that needs to be clarified, and we need to have best practices, and all those things. So, there’s still a lot of work to be done.

Mike Schmidt: Spacebear, I’m curious, and you’ve sort of gone through some of this with Murch in terms of the value, especially since this is an interactive protocol, you sort of have this network effect that you’re trying to build up, right? So, you need more software and service adoption of payjoin, and then it becomes exponentially more useful. And for all the good benefits that people would get out of it, I think that would be a good thing. You mentioned the bindings, you mentioned maybe doing some case studies to get more information out there to other potential providers and wallet software to integrate this.

So, it sounds like you guys are doing a lot of the evangelism that would need to be done. I’m curious, to the degree that you’ve been involved with outreach to wallets and providers, what’s the feedback been on, “Oh, yeah, we definitely got to get this on the roadmap”, or are there specific objections, or how has that been, or have you been waiting for the stable release to do that?

Spacebear: Yeah, in the last couple of years, were a lot more actively involved with integration, so going into existing wallets, pulling the code, forking it, and then writing the payjoin implementation as kind of up for review. Now, with AI, it’s a little bit easier to not have to introduce ourselves into the development process, and we can just open an issue like, “Hey, you guys should try implementing payjoin”, and it’s a lot easier to just have those proof of concepts up and running quickly. So, yeah, like you said, our role has shifted more into evangelism and more just getting the library and the documentation and all development resources in a place where it’s as easy as possible for an interested developer to actually go ahead and implement this. But until then, yeah, I think the issue we were struggling with was there was too much demand that we couldn’t match. And now, we’re trying to kind of change the approach a little bit so we actually can have all the language bindings that would be required. We have still a few mobile wallets that are interested that we don’t have language bindings for, so we need to get React Native out, we need to get C#, which are kind of still in a beta state, Kotlin also, there’s a bunch of stuff to do with hardware wallets. So, there’s some work in flight to get no_std for the payjoin library to be actually runnable on embedded hardware. So, there’s still a lot of work to do basically to remove these barriers to implementation so that when the demand is there, it can be met.

Mike Schmidt: Great. Thanks for your work on this, spacebear, and it sounds like this is a great milestone, and you guys are in the process of now getting it more out there. Look forward to more wallets and services supporting this, and it sounds like you guys are doing good work there as well. Anything else for our listeners as we wrap up this item?

Spacebear: Yeah, thank you guys for having me on. I would say just if you’re an implementer out there, just check it out. Try implementing payjoin and if for any reason you can’t, then open an issue.

Mike Schmidt: Great. Thanks again for your time, spacebear, we appreciate it.

Spacebear: Thank you, guys.

Draft BIP for rawtr() output script descriptor

Mike Schmidt: Cheers. We’re going to jump back up to the news. We have a second item that we want to wrap up, which is, “Draft BIP for rawtr() output script descriptor”. We weren’t able to get the author, Jean, on the show today. So, Murch, Gustavo, and I will go through this one. But he posted to the Bitcoin-Dev mailing list a draft BIP for a potential rawtr() output script descriptor. And maybe as a quick primer, the descriptor is essentially this standard language that a wallet uses to record how an address was built so that it knows which outputs it owns and then how to spend them. Don’t worry, Murch, I have a note in here, “I’ll pause for Murch”!

Mark Erhardt: Okay! Well, I would say a descriptor is a way of defining the pattern of a wallet. So, while you can have descriptors that only express a single output script, generally they describe a whole set of output scripts, a range. So, a very simple descriptor would define, for example, P2WPKH outputs, output scripts that follow a sequence of derived keys. And you would sort of define where the sequence of keys start and then how they plug into the output script; so, which part of the output script is the variable part that the key sequence plugs into. And the really nice thing about descriptors is, where xpubs only describe the sequence of keys, the descriptor describes the entire script. So, if you use a custom script or you want to do miniscript or you want to do a multisig or you do anything else that isn’t exactly this key derived at that path, where you sort of have the meta information be not explicitly defined, the descriptor allows you to explicitly define all that meta information. So, it is a whole backup of the wallet, rather than just a backup of a key sequence.

Mike Schmidt: So, maybe, Murch, before we talk about rawtr(), we can talk about tr() descriptor, or taproot descriptor. So, the proposal here, or the draft BIP, is for rawtr(). So, for the taproot descriptor currently, I believe it takes a few different things: an internal key; mix in the script tree according to, I think, BIP341 tweaking; and then out comes this final output key, right? And so, that’s existed, that’s documented, I believe, has a BIP and everything. But rawtr() or raw taproot was shipped in Bitcoin Core quite a many versions ago. I think we had 24.0 in the newsletter, so for four years, but it never had a BIP. So, other people trying to do that were sort of maybe guessing or poking around at different other BIPs to say what it should do. And then, you had this wallet backup containing the rawtr() descriptor, which maybe wasn’t portable to other software, etc. And so that’s, I guess, the motivation for rawtr(). I guess maybe we’ll pause there. Does that make sense so far?

Mark Erhardt: Right, so as we hopefully have established on this show and elsewhere, taproot outputs can be spent in two different manners per the keypath, where you just use the key that is already onchain by the output script being paid in the output, and then providing a signature. That’s the keypath spend. And for the scriptpath spend, you have to reveal, “Oh, wait, this was a tweaked key. Here is a branch to a script in the script tree. This is the script and the leaf script”, and satisfy the conditions of the leaf script. So, with the scriptpath, you have one or multiple different leafs in a tree that you can satisfy. So, to document a wallet pattern that uses a complex taproot construction, you need all this information. You need the script tree description, you need the internal key that was used to create the tweaked key, the external key. And so, for anyone that wants full knowledge of the wallet pattern, they would need a public version, or even the private key descriptor for the complex version.

But sometimes you might want to share only a description of the keys that go onchain with someone. So if, for example, someone were to pay you to a sequence of keys, you were sharing what would have been an xpub with them so they can pay you multiple times, you might only want to reveal to them the external keys, the sequence of external keys, without showing them what’s going on under the hood, without revealing that there is a script tree or what the spending conditions are, or anything like that. So, rawtr() allows you to export a more complex script tree to the boiled-down public version of it and just reveal the sequence of the external keys. I think it had been referenced in a couple of other BIPs before, and Bitcoin Core had implemented it in v24, as we said, but it hadn’t been formally described. So, what this BIP does is it sort of fills in a documentation need for a feature that already exists and formally specifies how rawtr() works.

Mike Schmidt: And that is in BIPs #2251, I believe. And so, that’s this draft BIP that closes that gap with a formal spec. I think there’s also some test vectors as well. So, if this is on anyone’s radar in terms of wanting to implement it or having tried to implement it in the past and not figuring out what spec to reference, listeners should check out that discussion and participate. Anything else, Murch?

Mark Erhardt: That’s all I had.

Silent payments sender plugin for Electrum

Mike Schmidt: Okay, we’re going to continue back to the Changes to service and client software monthly segment with, “Silent payments sender plugin for Electrum”. This is a post from Ali Sherief about a plugin released for silent payments sending, but not receiving, for the Electrum desktop wallet. This is for single-signature software wallets specifically. We’ve covered a slew of these earlier in the year of folks integrating different components of silent payments. This is the send-only, which is obviously the easier one, because the receive, as we’ve talked about with Craig Raw and others, is very intensive with the scanning. And so, this is just an easy way to look up that silent payments identifier and then create a transaction from that wallet to the recipient’s silent payments receive wallet.

Superscalar implementation announced

“Superscalar implementation announced”. This was an interesting one. It was actually on Delving, I think, and user 8144 with some numbers, but identified as Cubist_Roy, announced an implementation of Superscalar. So, we spoke with ZmnSCPxj’ and we had a Superscalar deep dive, I think that was in 2024, for this design of a sort of channel factory that he had, which is the idea of sharing many self-custodial Lightning clients using a single onchain UTXO without having to do a soft fork. And so, he came out with that design, and it’s sort of been a little bit quiet on a Superscalar front until this announcement of an implementation, or the documentation of announcement of an implementation, by Cubist_Roy here. Murch, have you had a chance to look at that one?

Mark Erhardt: I have not.

Mike Schmidt: Superscalar and ZmnSCPxj ideas are cool, yet sometimes hard to grok.

Mark Erhardt: Yeah, so basically, I think it’s sort of trying to do a channel factory without any consensus changes at the base layer. That was my takeaway, I think. And because it doesn’t get new covenants or LN-Symmetry or APO, or whatever, a lot of it is based on presigned transactions and pretty complicated scripts, and it was a very long Delving post or so from a few years ago. So, interesting that someone went and implemented it. But I think I would put it at maybe beyond Lightning complexity to get running. Although if there were some coordinator, it might get a little easier. I haven’t looked too much into it, just purely gut feelings.

Mike Schmidt: So, check out the Delving post, it’s actually quite a comprehensive Delving post. It’s not necessarily an announcement of a product or anything like that, it’s just some code. So, there is a GitHub, there’s explainer docs, there’s different plugins, and yeah, there’s a few pages of this person’s implementation summary.

Cofund multisig wallet announced

Next piece of software, “Cofund multisig wallet announced”. I was referencing this earlier. This is a self-custody multisig wallet based on P2TR. It’s got this idea of multi-vendor key registration, hierarchical multisig. And I mentioned earlier policy. It sounds like this is the policy language, Murch, to be paired with miniscript. Do I have that right?

Mark Erhardt: Presumably, yes.

Mike Schmidt: Cool. So, we linked to their Twitter announcement thread, but they also have a website that I don’t know if I was aware of at the time or didn’t link to. So, look, I think it’s like, getcofund where they have a website. And obviously, listeners of the show will also be curious of their GitHub repository. So, jump in there and see what they’re up to.

Lexe adds human-readable addresses and LNURL-withdraw

I actually don’t know how to pronounce this, I’ve read this several times. Lexe, do you know, Murch? “Lexe adds human-readable addresses and LNURL”. We haven’t covered Lexe before, I don’t think, so this was a good excuse to. Oh, Murch is saying that we did. Maybe we did.

Mark Erhardt: I’m pretty sure we must have covered them. So, Lexe has been around for a couple, maybe three years now, I’m not entirely sure. They’re running a self-custodial Lightning wallet, I think based on LND, but you get a light client because the always-on server part runs into a trusted execution environment (TEE). And thereby, well, you trust the TEE and the software obviously, but you don’t trust the third party that runs the Lightning server for you. So, it’s pretty interesting. They’re based here on the West Coast.

Mike Schmidt: Yeah, that’s what I have in my notes as well. They run each user’s node. So, if you’re using, let’s say you have this backend that’s in this TEE, it stays online. You don’t have to worry about running an always-online node yourself. And then, I wasn’t sure we covered it before, but the reason I sort of shimmed it in, and I thought we hadn’t covered it before, was this BIP353 human-readable Bitcoin addresses, which also double as Lightning addresses, and also this LNURL-withdraw feature, which I thought was pretty cool. Check out Lexe.

Bark 0.5.0 released

“Bark 0.5.0 is released”. We’ve talked with Steven Roose a few times, from Second, about Bark and their Ark implementation. This particular release adds a couple of capabilities that are notable: being able to restore a wallet’s full offchain balance, including UTXOs, from its mnemonic; Lightning receives to an external Ark address, which enables non-custodial Lightning-address servers. If you’re curious about our discussion with Steven, we had him on, I believe it was in Podcast and referencing Newsletter #410.

Bitcoin-PIR for private UTXO queries

Next piece of software, “Bitcoin-PIR for private UTXO queries”. Weikeng Chen announced Bitcoin-PIR, and PIR stands for Private Information Retrieval. It’s a PIR system that actually has a choice of four different backends for the implementation of PIR. So, I won’t go through those because I don’t understand what they are. But the idea here is that a light client can check for private information from a server; in this example, for example, the UTXO set for looking for your own addresses, without revealing to the server which address you’re actually interested in. So, it’s pretty cool. There’s some wild different types of moon-math techniques to let you essentially query a database in a way where the database operator cannot tell what you’ve asked for, which is pretty cool. I think I remember BlueMatt talking about these sorts of systems five or six years ago, about how something like this could be done. So, it’s cool that we have this implementation, and you can see there’s like a web-based version that you can click around on and query, using each of these different PIR, I guess, algorithms or backends to query addresses and pull back coins that are yours without the operator knowing.

OP_TEMPLATEHASH Ark demonstration

Next piece of software, “OP_TEMPLATEHASH Ark demonstration”. This again was Steven Roose. He’s launched a signet demo of Ark, and I believe it’s using that 0.5.0, running against OP_TEMPLATEHASH, which is the taproot-native CTV-style covenant opcode, and we’ve been talking about this for a while. I think we had instagibbs on discussing the BIP with us in #397. I think Bitcoin Inquisition activated OP_TEMPLATEHASH, and I think we covered that in Newsletter #415. And now, this is like a real second-layer Ark protocol demonstrating the prototype of running it, which is good to see. I think there’s probably feedback on the proposal coming from the proof of concept. The proof of concept can maybe drum up some interest in this sort of opcode, and build some sort of interest in actually using the end products that would be available from these covenants, which I think is important, as some people push for this sort of activation. Yeah, Murch?

Mark Erhardt: Sorry, I was a little distracted because I was double-checking myself. You are correct, we had never mentioned Lexe before. So, it’s time we gave them a shout out!

Mike Schmidt: There we go. Did you get a chance to look at this proof of concept, the OP_TEMPLATEHASH Ark demo on signet?

Mark Erhardt: Very briefly. I was looking at why it was called templatehash, and that is the website. I feel like that is a bit of a name collision with the opcode, but oh well. I think it’s pretty cool that there are a bunch of people working on different proofs of concept to make use of templatehash. So, I’ve seen recently a statechain proof of concept that is based on templatehash, which then makes the statechain be possible to have infinite replacements without the locktimes counting down. And there’s this Ark here. There is, of course, a description of how to do LN-Symmetry with the re-bindable signatures package, and so on. So, I think it’s cool that there are some prototypes being developed from different directions here.

Mike Schmidt: Well, I think the idea, at least from Antoine and Greg, who I know are working on the proposal, is that this would sort of be, I don’t want to say strictly, but somewhat scoped towards improving these L2s. And so, these layer 2s actually implementing these as proof of concepts, working out the kinks, maybe proving out some usability challenges, or whatever is going to come from actually building the thing that people are going to use, seems like a good idea if that’s the scope of a potential soft fork proposal.

Mark Erhardt: Yeah, I mean that’s exactly what should be happening if there is interest for a covenant proposal, that people demonstrate that there is enough interest that they work on prototypes. Just to be clear, Steven Roose is the third author on that package of BIPs. So, yeah, stuff coming from Greg, from Antoine, and Steven is also probably motivated because they wrote the BIP.

Mike Schmidt: Yeah, that’s fair. Well, hopefully other people can listen to this, check out the templatehash.com website, check out what the proposed opcode and bundle of opcodes do, and maybe someone from outside of the author of the BIP can also do some prototyping.

Mark Erhardt: I mean, for example, the statechain proof of concept is not from one of those three.

Mike Schmidt: Good.

Mark Erhardt: That’s from w0xlt. But yeah, I think there’s also interest from other people. I hope there’s going to be more interest, but tentatively there seems to be a little momentum here.

libshrincs formally verified hash-based signatures

Mike Schmidt: Yeah, excellent. Last piece of software that we highlighted in this monthly segment, libshrincs, which is formally verified hash-based signatures. I did not ask Jonas Nick or remix7531 to come on, because while this segment came up and it was convenient to cover it for this because it is a library, so it fits in this segment, I think it probably also warrants maybe a coverage in the Changing consensus next month. And so, maybe we can get those guys on and talk about that more in depth. But libshrincs is a C implementation, it’s a post-quantum hash-based signature, machine-checked security proof written by remix7531. So, very cool. We obviously had Jonas on a few times, but in, I think it was Newsletter #399, talking about SHRIMPS. I think we’ve had him on other times talking about SHRINCS. We had remix7531 on talking about his formal verification work. And so, this is sort of like a combination of the two. You have the actual C implementation, you have some formal verification in there as well, which is, I think, pretty cool to see that we’ve gotten there already with these proposals.

Mark Erhardt: Yeah, it sounds like if you know what libsecp is, this is sort of the post-quantum library that would take the place of libsecp implementing these post-quantum hash-based signature schemes. This, of course, ties into the debate about being worried about quantum computers. SHRINCS was the first proposal from Jonas Nick and Mikhail Kudinov, I think, right? This would be sort of the single-sig variant that is fairly blockspace-efficient, but wait, no, it doesn’t need state and is not that efficient. It’s pretty big, 3,000 bytes for public keys and 2,000 bytes for signatures or so, if I remember right. SHRIMPS was the combination of that with an expectation that the signer keeps track of state and then can make smaller signatures, but has to remember that they signed before, or it could become unsafe, if I recall that correctly. To toot our own horn a little bit, members of the Localhost Research team have been working with researchers to propose PRAWNS, which is a multisig scheme, a threshold signature scheme that is based on – we’re sticking with the shellfish analogies here. This is a paper coming out that we recently announced on our blog.

Mike Schmidt: Very cool. I want to quote from the Delving Post here, “The main goal of libshrincs was to determine whether machine-checked proofs of functional correctness and security could be practical for a cryptographic library of this kind. Until recently, producing both proofs would have been prohibitively difficult because of the specialized expertise and engineering effort required. The large language models available in 2026 changed that”. So, somewhat echoing what we heard from Keags a few weeks ago, in that the LLM is actually quite good at this sort of work and some of this checking work. So, it’s interesting that they put this out. I suspect we’ll talk more about it in the coming weeks. So, I think it’s a bigger topic than just the one shimmed in here in this monthly segment.

All right, we can move to not Releases, because there are none this week, but Notable code and documentation changes, authored and summarized here by Gustavo. Hi, Gustavo.

Bitcoin Core #32784

Gustavo Flores Echaiz: Thank you for the intro. So, this week, we have five different items from the Bitcoin Core repo. The first one, #32784, is a new RPC command called derivehdkey, which allows you to derive an xpub at a specified derivation path. You can also optionally derive an xpriv from the wallet if you specify that option, but the main goal here is to derive an xpub at a specified derivation path to be used for a multisig wallet, where each participant provides an xpub. Yes, Murch?

Mark Erhardt: Yeah, so if you have hardened derivation steps in your derivation, you cannot do these without having the underlying private key, right? So, the idea here is if your path that you want to use in a multisig descriptor has any hardened derivation steps, in order to for you to for you to participate and have a sequence of keys that tie into the descriptor, you would need to derive the public key below the hardened derivation step first, from which the key sequence derives. And this was possible before by, well, really understanding the command line very well and how Bitcoin Core worked. And with this RPC command, you can basically point out which derivation path you want to use and then derive that public key at the right spot, even if there are hardened derivation steps along the way. And as you said, you can either produce the corresponding xpub or xpriv at that point. And that enables you especially to do more complicated miniscripts or multisigs more easily.

Gustavo Flores Echaiz: Exactly. So, the multisig tutorial in the Bitcoin Core repo was also updated, part of this PR. And also, if your wallet has multiple HD keys, you can also specify which one you want to use by providing, like, the head xpub that the descriptor uses to identify that wallet. And the goal there is simply for Bitcoin Core to know which HD key you want to derive from.

Bitcoin Core #35797

So, the next item, Bitcoin Core #35797. Here, basically the issue that was going on is that when processing PSBTv2 with the descriptorprocesspsbt RPC command, if it didn’t have any inputs as it’s allowed in PSBTv2, it would basically run into a bug. The Bitcoin Core implementation was expecting PSBTv2 to function as PSBTv0, where PSBTv0 is an unsigned transaction with the inputs and the outputs. However, PSBTv2 can optionally have no inputs. So now, the code behind that RPC command, specifically the method UpdatePSBTOutput, it was trying to use the first input, but it would fail because it had no inputs. So now, it will build a temporary transaction containing a dummy input when populating the output metadata of PSBTv2. So, instead of changing the code to not force the existence of an input, Bitcoin Core will simply create a temporary transaction with a dummy input to populate the PSBTv2 output metadata. Yes, Murch?

Mark Erhardt: Did Gustavo just freeze or is that just on my end?

Mike Schmidt: I think he froze.

Mark Erhardt: Okay. So, PSBTv0, if I remember correctly, was basically based on the assumption that the entire transaction was already put together. The inputs were just missing the signatures and you were going to parse around the PSBT to collect those signatures. However, PSBTv2 was created in order to make that more flexible, so that updaters to the PSBTv2 would also be able to provide inputs or change outputs, and so forth, so that the transaction creation itself would be distributed, not just the signatures. So, PSBTv2, which, for example, is used by payjoin that we talked about earlier, and I think also is used by many multisig setups these days, where previously different wallets and services had their own formats, it is now getting adopted as sort of an exchange format for people to collaborate on transaction creation, PSBTv2 allows you now to have outputs before any inputs exist. And there was a bug that caused the software to crash if you were trying to update the outputs without any inputs on the transaction, which is fixed here now.

Bitcoin Core #35531

Gustavo Flores Echaiz: Thank you, Murch. I fixed my connection, so I shouldn’t have a problem with this connection anymore. So, the next two items are about performance optimizations inside Bitcoin Core, so quite interesting changes. The next one is #35531. Here, the disk space used by the -txindex option is considerably reduced. The author’s test saw the index shrink from 66 GB to 26, and indexing time fall from 1 hour 50 minutes to 1 hour 19 minutes in his machine. And basically, the structure of the data is changed. Instead of storing the whole txid and the disk position of the transaction, the txid as the key and the transaction disposition as the value, the new format instead uses a five-byte prefix of a salted SipHash of the txid, so the txid is hashed and some SipHash is also added onto it to basically make it so that the result cannot be predicted. And in the key space, it also includes the block sequence number and the transaction offset, both in a compact six byte suffix. So now, the value is empty and basically now Bitcoin Core will start by finding the block location using the block index, so it doesn’t need to point to the transaction disposition, it can only reference to the block index and that’s how it can find the transaction specifically where in the disk.

Mark Erhardt: Right, so Bitcoin Core stores the blockchain in blocks of, I think, 100 MB. And whenever you receive block data, it is just shoved into these block files. But it remembers where each block starts in these 100-MB blobs of data. So, it sounds to me that the -txindex is not storing less information now, it is just smarter about how to reference where that information appears and then reading it from the disk directly from the blockchain data. And so, the prefix is just an identifier, and the suffix is where to look for it. And with the prefix, you have enough information that there will not be collisions, is my understanding. So, it gets significantly smaller, more than half the size less, and faster to index, and I think also faster to look up things, which is really nice.

Gustavo Flores Echaiz: Yes. So, technically there are collisions. So, he tested, he did find like 894,000 two-way collisions, 395 three-way collisions and one four-way collision, in the sense that there were four transactions that had a collision. But however, after scanning the entries, the shared prefix and finding the block location, it will then verify the full txid to safely handle the collisions. And even if this format has more collisions than the previous one, it’s still way more performant. So, that was a limitation that was found, but it was accepted as a fair trade-off because of how it was still way more performant. If someone updates, like, it’s not forced to update to the new format, you don’t have to re-index, but you do have to if you want to reclaim your space. However, with the new version, the new entries will get written in the new format. However, if you rebuild the txindex and you downgrade your Bitcoin Core version, you will also need to rebuild the index when downgrading, because previous Bitcoin Core versions simply don’t understand this format.

Mark Erhardt: However, if you have a txindex, you are required to have default blockchain. So, this is no downloading, it’s just recalculating from data you have already.

Bitcoin Core #35889

Gustavo Flores Echaiz: Totally. Next item, also performance-related, #35889. So here, the gettxspendingprevout RPC command, which allows you to check whether an outpoint was spent, either in a mempool or through a confirmed transaction, the performance of this RPC is considerably improved so that the author’s benchmarks, for example, in a system with a Ryzen 7 3700X, this large mempool-only request batches completed 9 times faster and 31 times faster on a Raspberry Pi 5. So basically, what is happening here is that previously, Bitcoin Core, let’s say it has a list of outpoints that it wants to verify whether they were spent first in the mempool and then in confirmed transactions, it will go through that list and as soon as it finds one that was spent in a mempool transaction, it will erase it from the middle of the vector from that list, and all the remaining entries will have to shift positions. So, it was just a very costly operation, because every time you found a match of an outpoint that was spent by a transaction found in the mempool, you would have to shift all entries. Basically, the erasement of that value would just be a very expensive operation.

So now, instead, what it does, once it scans the list and it finds that one was spent via a transaction in the mempool, it will simply create a new list, called results, and it will reference the position of that outpoint instead of removing it from the initial list. Later on, it will rerun a second scan for transactions to see if those transactions were spent in confirmed transactions to the optional txospenderindex, so it can also build a separate worklist for that lookup, instead of having to shift the entries in the initial list.

Bitcoin Core #35605

Next item, Bitcoin Core #35605. So here, we deprecate a wallet RPC called removeprunedfunds, which was added alongside importprunedfunds. So, importprunedfunds is an RPC command that allows you to add a transaction that your wallet should know about, but it doesn’t know about either because your node was pruned and it doesn’t have that block data. So, you could manually add a transaction that your wallet should know about. And the logic around adding removeprunedfunds next to it was that I could add that transaction to my wallet, and then I could also delete that transaction back. However, the problem with removeprunedfunds is that it wasn’t limited to the transaction were added via importprunedfunds, it could simply delete any transaction belonging to my wallet. And that would just simply fall outside of the wanted scope of the RPC command and it could also lead to just dangerous behavior.

Also, this command seems to be a maintenance burden, since in Newsletter #391, we covered a bug when removing transactions via this RPC command, where removing a transaction marked all of its inputs as spendable again, even if a wallet contained a conflicting transaction that also spent the same UTXOs. So, the decision was simply to deprecate the RPC command and to schedule it for removal in the next release; one, for the dangerous behavior, but also the second one, because there was simply no known useful purpose for this command, and then because it was also a maintenance burden. Yes, Murch?

Mark Erhardt: So, this follows the removal of the legacy wallet, because for the legacy wallet, there were situations where that was a handy way of fixing a wallet issue. But now that we don’t have the legacy wallet anymore, there are no known uses for it anymore. And yeah, enabling your users to fudge with what transactions our wallet knows about just introduces a big set of footguns. So, now that we don’t need to have this manual fix anymore, it is being deprecated.

Gustavo Flores Echaiz: Exactly. So, the next three items, we’re going to skip them because they were all from the Eclair repo and they were discussed at the beginning of the episode. Also, I want to say that t-bast mentioned an interesting feature at the very end of when he was covering these PRs. I believe it was about a new feature that was developed in Eclair that is going to get covered in the next newsletter. So, it was added to Eclair after the deployment of this newsletter, which means that it will be in the next one. So, the next two items after the Eclair ones are from the LND repo.

LND #8754

So, the first one, #8754. Here, an experimental outbound connection mode is added for the remote signer. So, the remote signer is a setup where the private key operations are delegated to a separate signer server. And in Newsletter #172, which means about five years ago, we covered that LND had added the ability for an LND node to delegate private-key operations to a remote server. However, that required the remote server to have inbound connections to accept requests from external servers. And that created a sort of security risk, which this item basically addresses by creating an outbound connection mode, where the new mode changes only how the two connect; and instead of the signer listening for an inbound connection, it initiates the connection to the LND node. So, in Newsletter #326 we covered work that was required for this to happen, which was about deterministic macaroon generation, which enabled this new experimental mode.

LND #11065

The next item, also from the LND repo, item #11065. Here, a new experimental RPC, called XCreateAccount, which when building LND requires a user to enable this feature, so it’s experimental, it’s not enabled by default, this allows a user to create separate accounts from keys that are derived from their LND’s wallet master key. So now, onchain funds can be segregated in different accounts. This doesn’t apply for funds in LN channels, but only applies for onchain funds of this Lightning node. So, this allows for easier coin selection, address derivation, and simply scoping funds to specific accounts and isolating pockets of funds. I also want to add that if you choose a selected address type for the account, that is going to be permanent, you cannot change that after the fact, and it will always default to taproot.

HWI #842

The next item and the final one, from the HWI, Hard Wallet Interface, repo item #842, which curiously is sort of related to what we discussed about the Ledger update earlier in the episode. So here, what happens is that a new command called registerdescriptor is added, which allows HWI to register an output script descriptor with a hardware signing device before signing transactions from that wallet. So, similarly to what we discussed at the beginning about the Ledger app change, here this command allows a wallet using HWI to basically register a descriptor with a hardware signing device before signing the transaction, simply for the user to have visibility via his hardware wallet device of the descriptors he’s going to later be signing on. Also, BIP388-compatibility is also added, where the descriptor is sort of converted into something that is more user-friendly to view, by separating the wallet descriptor template with the key information vector.

So, this also works, from what I saw, with stateful and stateless devices. So, you could also use it with a stateless device, which doesn’t necessarily keep the descriptor registration, but HWI can basically have that state to later be recovered by the signing device. Yes, Murch?

Mark Erhardt: Right, so BIP388 is the wallet policies BIP by Salvatore, who we had on the show earlier. This is basically a subset of descriptors that have wallet patterns that can be boiled down to easier descriptions. It limits miniscript to a smaller subset that Ledger directly supports, and others can implement support for too. So, for wallets that don’t have a registration on the hardware device, so they cannot remember whether they have committed to an output script descriptor, they provide an attestation. So, when you register, they return basically a signature that says, “I have seen this descriptor before and this was signed off by my user”. And then, when the companion software communicates with the hardware signer, they will provide back this attestation, and thereby the device knows that this is registered by getting the output script descriptor again and the signature by itself, showing that it had seen it previously. That way, even a stateless device can register wallet policies.

Gustavo Flores Echaiz: Right. That makes sense. Thank you, Murch. So, that’s the final item, and that completes the newsletter and the episode. Thank you.

Mike Schmidt: Thanks, Gustavo. Thanks, Murch. And we also want to thank our guests this week, Salvatore, t-bast, and spacebear for joining us, and for you all for listening. We’ll hear you next week. Cheers.

Bitcoin Optech Newsletter #419

2026-08-21T00:00:00+00:00

This week’s newsletter summarizes the disclosure of a fixed reorg vulnerability in LND’s channel closes and describes a draft BIP for the rawtr() output script descriptor. Also included are our regular sections describing recent changes to services and client software and notable changes to popular Bitcoin infrastructure software.

News

● Reorg vulnerability in LND channel closes: Bastien Teinturier posted to Delving Bitcoin the responsible disclosure of a vulnerability that affected LND versions before 0.20.0, which fixed it in February 2026. Operators running an older version should upgrade. To Teinturier’s knowledge, no one was affected by the vulnerability.

Before that version, an LND node would forget about a collaboratively closed channel immediately after the first onchain confirmation, losing the protection against chain reorgs. In case of a reorg, an attacker could publish an old, revoked commitment transaction for the channel and because the node had already forgotten the channel, it would not publish a penalty transaction, letting the attacker drain all of the channel’s funds.

The vulnerability was discovered in February 2025 and fixed in LND #10331 (see Newsletter #389). The patch makes a node wait for more confirmations before considering a channel close final (at least six, following BOLT5’s reorg-safety handling). Teinturier’s post includes a regtest reproduction and a timeline of the disclosure.
● Draft BIP for rawtr() output script descriptor: Jean Pablo posted to the Bitcoin-Dev mailing list about a BIP proposal for the rawtr() output script descriptor.

A rawtr() descriptor can be used to express a P2TR output directly by its output key, without needing an internal key or a script tree. The key is used as the taproot output key without applying the BIP341 tweak. This is useful, for example, when the internal structure isn’t known, or the script tree hasn’t been revealed by the owner.

This descriptor has been available in Bitcoin Core since version 24.0, but had not yet been specified in a BIP. Several implementations route around the problem by either not supporting it, or quoting other BIPs. The proposal aims to close this gap. The BIP draft and test vectors are available and being discussed under BIPs #2251.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

● Payjoin Dev Kit (rust-payjoin) 1.0.0 released: The Payjoin Dev Kit project released the first stable version of rust-payjoin, supporting both synchronous BIP78 payjoins and asynchronous BIP77 payjoins with resumable, persisted sessions.
● Silent payments sender plugin for Electrum: Ali Sherief released a plugin that adds silent payments (BIP352) sending (no receiving) to the Electrum desktop wallet for single-signature software wallets.
● Superscalar implementation announced: 8144225309 announced an implementation of Superscalar, ZmnSCPxj’s channel factory design that puts many self-custodial Lightning clients behind a single onchain UTXO without a soft fork (see our Superscalar deep dive podcast).
● Cofund multisig wallet announced: Cofund announced a self-custody multisig wallet built on a policy-based taproot (P2TR) architecture with multi-vendor key registration and hierarchical multisig.
● Lexe adds human-readable addresses and LNURL-withdraw: Lexe, a self-custodial Lightning wallet that runs each user’s node in a trusted execution environment (TEE) so it stays online without the operator taking custody, announced support for BIP353 human-readable bitcoin addresses (which also function as Lightning Addresses) and LNURL-withdraw.
● Ledger Bitcoin app 2.5.0 adds human-readable policy descriptions: Salvatore Ingala announced version 2.5.0 of the Ledger Bitcoin app, which displays a human-readable description for many taproot miniscript and multisig wallet policies during registration, instead of only the opaque descriptor template. This makes it easier for a user to verify a policy and catch a malicious substitution (such as a 3-of-5 replaced with a 1-of-5) before registering it.
● Bark 0.5.0 released: Second released version 0.5.0 of Bark, its Ark implementation, adding restoration of a wallet’s full off-chain balance (VTXOs) from its mnemonic and support for Lightning receives to external Ark addresses, which enables non-custodial Lightning-address servers.
● Bitcoin-PIR for private UTXO queries: Weikeng Chen announced Bitcoin-PIR, a private information retrieval (PIR) system that lets a light client check the UTXO set for its own addresses or scriptPubKeys without revealing to the server which ones it is interested in. It offers a choice of four PIR backends: DPF-PIR, HarmonyPIR, OnionPIRv2, and an ORAM scheme backed by a trusted execution environment (TEE).
● OP_TEMPLATEHASH Ark demonstration: Steven Roose launched a signet demonstration of Bark, Second’s Ark implementation, running against OP_TEMPLATEHASH, a taproot-native CTV-style covenant opcode. The demo is built from the templatehash branch of the Bark repository.
● libshrincs formally verified hash-based signatures: Jonas Nick announced libshrincs, a C implementation of post-quantum hash-based signatures with a machine-checked security proof, written by remix7531.

Notable code and documentation changes

● Bitcoin Core #32784 adds a derivehdkey wallet RPC command that derives an xpub and, optionally, an xprv from an HD key known to the wallet at a derivation path specified by the caller that contains at least one hardened step. This is useful for coordinating multisig wallets, in which each participant provides an xpub derived from a different path than the wallet’s default single-signature descriptors. Since hardened derivation requires private key material, the RPC is unavailable for watch-only wallets, and encrypted wallets must be unlocked.
● Bitcoin Core #35797 allows PSBTv2 output metadata to be populated before any inputs are added when using the descriptorprocesspsbt RPC (see Newsletter #253). Previously, UpdatePSBTOutput used the first input of the PSBT’s unsigned transaction when traversing an output script, which could fail when a PSBTv2 contained outputs but no inputs. Now, it uses a temporary transaction containing a dummy input for metadata traversal without modifying the PSBT.
● Bitcoin Core #35531 reduces the disk space used by -txindex option (see Newsletter #161) by changing how transaction identifiers and positions are stored. Instead of storing each 32-byte txid and transaction disk position, the new format uses a five-byte prefix of a salted SipHash of the txid and encodes the block sequence number and transaction offset in a compact six-byte suffix in the database key, with an empty value. Lookups scan all entries that share the prefix, determine each candidate’s block location using the block index, and verify the full txid after reading the transaction from disk, safely handling collisions. In the PR author’s mainnet tests, a fully rebuilt index shrank from about 66 GB to 26 GB, while indexing time fell from about 1 hour 50 minutes to 1 hour 19 minutes. While existing indexes remain readable, they must be rebuilt to reclaim space. After rebuilding, older Bitcoin Core releases cannot read the new entries and will also need to rebuild the index when downgrading.
● Bitcoin Core #35889 improves the performance of the gettxspendingprevout RPC when checking large batches of outpoints. Previously, when a transaction that spent an outpoint was found in the mempool, the outpoint was erased from the middle of a vector while the mempool lock was held, forcing the remaining entries to shift. Now, the RPC scans each request once, stores the resolved results at their original indexes, and collects only the unresolved outpoints in a separate worklist for lookup through the optional txospenderindex (see Newsletter #394). This makes the mempool pass linear instead of quadratic. According to the PR author’s benchmarks, large mempool-only request batches completed about 9 times faster on a Ryzen 7 3700X and 31 times faster on a Raspberry Pi 5.
● Bitcoin Core #35605 deprecates the removeprunedfunds wallet RPC and disables it by default. Users who still require it must use the -deprecatedrpc=removeprunedfunds startup option. The RPC is scheduled for removal in the next major release. It is being removed because it exposes dangerous behavior without offering any known useful purpose: it can delete any transaction belonging to the wallet, including transactions that were not added through the related importprunedfunds RPC. It is also a maintenance burden; see Newsletter #391 for coverage of a previous bug involving the RPC.
● Eclair #3352 fixes missing BOLT2 channel-reserve checks when Eclair is the fundee of a single-funded channel, ensuring that neither party’s dust limit exceeds the other party’s channel reserve. Without these checks, a peer could spend its balance down to a reserve below the applicable dust limit, causing its output to be omitted from a commitment transaction and leaving it with no onchain funds at risk when publishing a revoked state. The PR also adds a configurable eclair.channel.max-funding-satoshis channel size limit, which defaults to 5 billion satoshis (50 BTC). This restores an upper bound after support for wumbo channels allowed channels above the previous protocol limit.
● Eclair #3351 fixes several bugs in on-the-fly funding (see Newsletter #323), a feature currently used by ACINQ’s Lightning Service Provider (LSP) node in Phoenix Wallet. Specifically, after a restart, Eclair could fail to recognize that an HTLC had already been fully cross-signed because it only checked pending channel changes. This could potentially cause the same payment to be relayed twice. Eclair now also checks the current commitment states before relaying. Additionally, the PR resolves several timeout and on-chain failure paths to prevent Eclair from paying a downstream peer after failing the corresponding upstream HTLC.
● Eclair #3345 limits the resources each peer can consume when requesting and synchronizing channel announcements through BOLT7 gossip queries. A configurable rate limit, set to 5 requests per second by default, applies per connection across query_channel_range and query_short_channel_ids. Eclair waits until a query’s replies have been sent before accepting additional work to preserve transport backpressure. Eclair ignores duplicate short channel IDs (SCIDs) to prevent response amplification and rejects malformed or overlapping queries. It also limits memory usage during synchronization by capping each peer to 2,000 queued query_short_channel_ids requests. Similar resource management protections were previously added to LND (see Newsletters #366 and #417).
● LND #8754 implements an experimental outbound connection mode for the remote signer (see Newsletter #172), in which private-key operations are delegated to a separate signer server. The signer still does not independently validate the requests it receives, so it will sign any request the watch-only node sends. The new mode changes only how the two connect. Instead of the signer listening for an inbound connection, it initiates an outbound connection to a dedicated RPC listener on the watch-only node, allowing it to operate without accepting inbound connections. This setup was previously discussed in Newsletter #326 in connection with deterministic macaroon generation.
● LND #11065 adds an experimental XCreateAccount RPC and a corresponding lncli wallet accounts create command, to create a named, fully spendable account whose keys are derived from LND’s wallet master key. This is different from the existing ImportAccount RPC (see Newsletter #144), which imports a watch-only xpub. Coin selection, balances, address derivation, and change can be scoped to the account, providing isolated pockets of funds within one wallet. The selected address type is permanent and defaults to taproot.
● HWI #842 adds a registerdescriptor command for registering a named output script descriptor with supported hardware signing devices before signing transactions from that wallet. Implementations are added for BitBox02, Coldcard, Jade, and non-legacy Ledger devices. For devices that use BIP388 wallet policies (see Newsletter #302), HWI converts the descriptor into a wallet descriptor template and key information vector, it also returns any device-specific registration data needed for later signing.

Bitcoin Optech Newsletter #418 Recap Podcast

2026-08-18T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Michael Ford (fanquake) and Martin Zumsande to discuss Newsletter #418.

The Bitcoin Optech Podcast and transcription content is licensed Creative Commons CC BY-SA 2.0

Download audio

News

● Conditional message transfer contract to solve jamming (33:07)
● Static Bitcoin Core binaries available for testing (1:19)
● Replacing per-peer transaction rate-limiting with global rate limits (18:44)

Releases and release candidates

● BTCPay Server 2.4.2 (43:16)
● LND v0.21.2-beta (45:45)
● LND v0.20.3-beta (45:45)

Notable code and documentation changes

● Bitcoin Core #35493 (48:10)
● Core Lightning #9150 (50:57)
● BIPs #2248 (54:13)
● BIPs #2225 (56:07)
● Eclair #3346 (58:50)
● Eclair #3341 (1:02:22)
● LND #11019 (1:05:18)
● LND #11023 (1:09:03)
● Libsecp256k1 #1904 (1:11:49)
● HWI #839 (1:13:58)

Transcription

Mike Schmidt: Welcome everyone to Bitcoin Optech Newsletter #418 Recap. Today we’re going to be talking about static Bitcoin Core binaries available for testing; we also have a discussion about transaction rate-limiting in Bitcoin core; a proposed contract protocol for mitigating Lightning channel jamming; and then we’ll get into a critical BTCPay Server security release with some action required for operators. And then, we have our weekly Notable code and documentation changes. This week, Murch, Gustavo, and I are joined by two guests. I’ll let them introduce themselves. Mr Michael Ford?

Michael Ford: Hi, yeah, I’m Michael Ford or fanquake on GitHub and Twitter, one of the Bitcoin Core maintainers. I’ve been hacking around on that project for quite some time now.

Mike Schmidt: And Martin?

Martin Zumsande: Hi, I’m Martin Zumsande. I recently joined Brink as a full-time contributor, and I work on Bitcoin Core, mostly on P2P code. And yeah, nice to be here.

Static Bitcoin Core binaries available for testing

Mike Schmidt: Well, thank you both for joining. For listeners, we’re going to go a little bit out of order in the News section in deference to our guests. So, we will start actually with, “Static Bitcoin Core binaries available for testing”, News item. Fanquake, you announced test builds for static Bitcoin Core binaries. And maybe one place to start would be just conceptually, what is a static binary? And then we can talk a little bit about the call to action around folks testing those types of builds. What is a static binary? Why is it valuable? Why is having a non-static binary potentially dangerous or problematic?

Michael Ford: Sure, so Bitcoin Core today ships, I guess what you could call sort of semi-static or nearly-static binaries where all of the sort of nonsystem related dependencies, so I think Boost or libevent or ZeroMQ, when we compile our release binaries, we sort of bundle all that code into the binaries. And then, when a user downloads Bitcoin Core to run on their system, our binary will reach out to their OS and load a few libraries from disk. So, that’s glibc, used to be libgcc, maybe a few others. What I would like to do, in terms of making our binaries fully static, is that when a user downloads bitcoind and runs it on their system, the bitcoind doesn’t reach out for anything. Basically, we would, as part of our release process, bake everything that we need to run as bitcoind into the binary that the user downloads.

So, you asked about potential upsides or downsides. So, obviously, one downside of reaching out for things on the system at runtime is that if there was, for example, malicious code in one of these dependencies that you’re reaching for on the system, maybe you could pull that into your binary and bad things could happen. If we’re reaching for things on the system, we also don’t fully know how bitcoind will behave at runtime, because obviously, depending on the user’s system, their version of glibc is likely different, it might have different bugs, they might have it configured or compiled in a different way. So, having a static binary, where we essentially know all of the code and all of its behavior ahead of time when we actually build it for a release, means we can have a much better idea of how these binaries will behave at runtime. And essentially, or ideally, they should all behave the same way on everyone’s systems at runtime, if there’s no external or runtime dependencies.

Mike Schmidt: Have there actually been issues in the past around this sort of behavior, or is it just mostly a known thing that there could be this deviation in behavior, based on versions?

Michael Ford: Off the top of my head, I don’t think we’ve had these kind of issues. Historically, we’ve always been bundling dependencies statically as much as possible, just generally to avoid this kind of problem. I mean, my work on this has mostly been just because I think this is sort of the, I guess, a kind of north star for how we can ship our binaries. Essentially, we create one nice little bitcoind blob that is fully self-contained and we ship that off to people, and it can hopefully run in as many different environments or on as many different operating systems as possible and as uniformly as possible.

Mike Schmidt: Are there objections to this sort of approach, or is it just sort of a universally endorsed good?

Michael Ford: I mean, so far on the PR that is open, there’s been no definite objections. I think in general, most people would agree that static binaries are nice. Yeah, I mean, there could be some objections. Obviously, when you bundle everything statically, okay, your binary gets slightly bigger, so it might go from 10 or 11 MB to 12 or 13 MB. In the context of Bitcoin, when you’re downloading hundreds of GB, an extra couple of MB to get going probably isn’t terrible. One of the pushbacks may be obviously, if we are bundling everything and, for example, there was a bad bug in something like glibc that did affect bitcoind, so maybe in some code used to resolve DNS addresses, or something, historically users would receive that bug fix via their OS package manager or similar, and they would maybe they get that fix the day after that bug is announced. Whereas if we’re bundling glibc, then obviously we actually have to push out a new release with the new bundled glibc code to fix that.

So, there are some trade-offs here. Maybe you get slightly bigger binaries; you’re trading off the risk of what if there is a bug in something like glibc that would affect us, how fast can we fix that or how bad might that be? But I think in general, there isn’t necessarily a lot of pushback. Maybe some pushback from people who are running maybe more customized service setups or home setups, and this could possibly interfere with their networking configuration or other things. But that’s also one of the reasons I’m trying to push for as much testing and exposure as possible for these binaries to try and figure out where are all these edge cases, what might break? Yeah.

Mark Erhardt: So, generally, I think I would expect a statically-linked binary to be more portable. So, how could this break networking code? I didn’t see the connection there.

Michael Ford: So, historically, glibc has always assumed that it can load code and modules, or I should say modules or plugins from disk at runtime. And so, if a user was relying on some of that behavior, or as part of their networking setup, it’s possible there could be some breakage here. But yeah, we’re yet to see anything like that in any of the users or developers who have tested any of these binaries. So, I’m hoping that’s very unlikely to be the case, but that’s one possibility.

Mike Schmidt: Is the idea that this would be one option for download, or the only option for download if you’re downloading the binaries? And then maybe also, a vision of what systems could eventually be compatible with static binaries? Like, would this be something that could happen on Windows or macOS, etc?

Michael Ford: I mean, so we’re obviously doing it for Linux initially. I’m not sure if it’s even possible for us to build fully static macOS or Windows binaries. I don’t think that’s actually doable currently. But yeah, we’re certainly doing it for Linux. I think in the ideal scenario, we would switch to these being sort of the default and sort of only binary to download, obviously unless there were some major issues or there are enough people coming out of the woodwork to say that these binaries are going to be incompatible with whatever their setups are, or however they’re running bitcoind or some other unforeseen problems. And ideally, these binaries are going to make it possible to run bitcoind in more places than it is possible to run it today. Because currently, we ship a release binary that has a runtime requirement of glibc 2.31 or later, which means you have to be running Ubuntu 20 or later, or Fedora version whatever or later; whereas the statically-built binary with glibc baked in can run, I think I’ve tested back to Ubuntu 12.04, or now you could run it on musl-libc-based systems like Alpine, which ship with musl libc, but you couldn’t run our bitcoind on those previously. You could run bitcoind in a container with essentially no operating system, like a scratch container. I think people have said they’ve tested it on NixOS, which you could previously run bitcoind on, but you had to use like a nix-ld wrapper to sort of make the runtime libraries work properly. But now, that’s also no longer applied.

Mark Erhardt: So, trying to sum up some of the different trade-offs here, it sounds to me that the static binary is an awesome offer for systems that currently struggle to run it, Linux systems, that is, like containers or other operating systems that are not directly served through the release usually. But then the bug-fix thing, especially in our times right now where the LLM advancement is so rapid that we’ve seen numerous changes in how security engineering works lately, it seems to me that it would be best if both were offered in parallel, static for those that need it, and for operating systems where you would prefer to get the glibc from the system, to keep it that way. I know you touched on it previously, but could you elaborate on that again?

Michael Ford: Yeah, if there was demand for us still delivering both, that’s obviously something we could do. Yeah, I mean we could also think about maybe changing how we produce releases, if it became apparent that there were so many bugs being found in glibc that we had to ship a new release every other week. That’s certainly something I guess we could try and think about and try and combat. I mean, the amount of code that we do use in glibc is certainly not enormous. So, at least if there are bugs there, generally the likelihood of them affecting us is not super-high. But yeah, there’s nothing set in stone here and we can certainly offer both binaries in parallel, if there was a demand for that.

Mike Schmidt: What does this mean for reproducible builds? Is this an improvement in that department or basically the same? How should folks think about that?

Michael Ford: I mean, hopefully the same, if not slightly better; the same in that obviously these builds will still continue to be 100% reproducible. That’s something that is never going to change. And then, if anything, they’re slightly better in that, I guess, the entire sort of binary or the entire runtime of the binary is now encapsulated in the reproducible build. All of the code that we are shipping to the end user that is going to run as part of bitcoind is now built inside the reproducible build environment, or produced from that environment, as opposed to previously or currently, we are producing a bitcoind that goes to the user fully reproducible, which then reaches out to the system and grabs some library that we haven’t reproduced or haven’t built.

Mike Schmidt: We have listeners that I suspect would want to help you out with this. Hearing fanquake is calling out to the community to test this out, our audience might be prime testers for something like this. What’s the process? They’re listening right now. Where do they go to get these test binaries? How should the testing go? Where do they report their results back to, positive or negative?

Michael Ford: Yeah, we want to hear all the results, positive and negative. I posted to the Bitcoin-Dev mailing list I think early last week and sort of linked to some test binaries that I had uploaded. Or obviously, people are also completely free to Guix-build the binaries themselves and check the hashes against mine and then run and test those binaries. So, you can track down the mailing list post, and probably starting there is the best place. It links to the PR on GitHub where you can leave feedback. You can obviously leave feedback directly on the mailing list as well. As of a couple of hours ago, I built a new suite of test binaries and put them up on my GitHub, and I’ll update the mailing list and the PR shortly with links to those. But yeah, that’s about it. Obviously, you can email me directly as well or ping me on Twitter. I don’t really mind how the feedback shows up.

Mike Schmidt: And in terms of testing, they build or they grab these binaries, and is it just run the thing and if it loads in any state and doesn’t crash, that’s good; or do you have specific things that should be done beyond just getting it to run bitcoind one time on signet, or whatever?

Michael Ford: Yeah, I guess obviously, don’t go and drop these binaries into production, but putting them into environments that represent production and your production networking configuration or your production OS, taking the binaries there, sure, you could run an IBD (Initial Block Download). But just running them in any capacity is probably going to be 90-ish% of the work, in terms of figuring out if the binaries are compatible with that environment, figuring out if they start up correctly, if DNS queries are working properly. A lot of what is going to be affected by the static builds is sort of happening in the first few seconds of bitcoind running and like booting. So, if you grab this binary and you throw it into a new container, which is the same version as your production OS, and you can sort of IBD signet or something from scratch, that would be a good indication that bitcoind is going to work there, I think.

Mike Schmidt: Murch, Gustavo, Martin, any other questions for fanquake? All right. Well, I think we have our call to action for our listeners here. Fanquake, we appreciate your work on this and joining us today to talk about it. If you have other things to do, we understand, you’re free to drop.

Michael Ford: Awesome. Thank you for having me.

Replacing per-peer transaction rate-limiting with global rate limits

Mike Schmidt: Cheers. Second news item this week titled, “Replacing per-peer transaction rate-limiting with global rate limits. Martin, I saw you were involved with this discussion and the PR that I think we covered back in Newsletter #416. But Bitcoin Core just merged a redesign of how nodes sort of paste their transaction announcements to peers. Maybe it would be helpful for you to articulate how that’s done currently and how it will be done in the future? And then, maybe we’ll have some questions for you based on that.

Martin Zumsande: Sure. So, let me first say that I am not the author, I was just one of the reviewers, and it has also been a while since I’ve reviewed this. So, I’m maybe not into it that much. But maybe I’ll just begin with a philosophy like, why do we have transaction rate-limiting in the first place? In principle, I would say our goal is that each node receives each transaction that has paid enough fees. But the important thing is what happens if we get a bunch of transactions at the same time. If we would announce these transactions to all of our peers all at the same time, we would have a huge surge in traffic, and that is something we don’t really want to do. So, that is why, and it’s been the case for many years, we have some kind of rate-limiting; but rate-limiting in the sense that we just delay it and smooth it out over time, but we don’t throw away any transactions. And yeah, another thing that the rate-limiting helps with, that if a low-priority transaction, like the low fee, for example, is rate-limited and delayed to send later, and then it gets replaced by another transaction, then we even save some traffic, because that transaction has never been announced.

So, yeah, that’s why rate-limiting exist in the first place. And so, far it was on a per-peer basis. So, whenever we receive a transaction and accept it to a mempool, then we would put the transaction into a queue of all of our peers, and each peer had a separate queue. And then, whenever this peer has its turn, then we would process some transaction according to the rate-limiting and announce the transaction to them. And by announcing, I just mean like announce the txid. We don’t send the entire transaction yet. But given that all of the transactions are happening for all of them, it’s still a lot of traffic if you sum it up. Question?

Mark Erhardt: Yeah, just very briefly. So, we would have separate queues for every peer. And then, we would walk over the queues and in turns, like each peer has its own timer. I don’t remember exactly what the timing is, but you can maybe fill that in. And then, we sort and send the highest feerate transactions first, right, just up to the limit?

Martin Zumsande: Exactly, yeah. That’s the important thing. We want to send the most important transactions first, like the one that are most likely to get mined. So, we sort them by feerate. And that happens for each peer every time. And that is what has caused the problems in the past, because what happened was, like in 2023, there were a huge amount of transactions coming because of some rune or inscription stuff. And as a result, we had a very large queue, like of 100,000 transactions, or something, in some cases, and we had to sort it for every peer every time, and that was a lot of sorting. And it basically resulted in a CPU DoS. So, most of the nodes became very slow at the network. And back in 2023, we fixed this a little bit ad hoc, I would say, like we would make it adaptive so that if there was a big backlog, then we would send that peer more transactions. But we will still do it on a per-peer basis. And then, there was another thing that improved it somewhat. We would just increase the rate that was merged, I think in 2025, also by AJ Towns, the author of the current PR. But it also just changed the rate and it didn’t address the problem at its root.

So, now we come to the PR that got merged now, that I would say really addressed the problem at its root. And what it did was it changed it such that we had only one global queue where all of the transactions go in and not one queue for each peer. So, what happens now is when we receive a transaction, we put it into the global queue basically. And then, every now and then, we drain this queue. And depending on whether the rate limit is reached or not, then we put some of the transaction into a separate queue for each peer. But that separate queue is very small, so sorting it and doing things with it is very fast. But the large one where all the backlog is, that is only one. Or, if we want to be more specific, there are actually two: one for inbound; and one for outbound. But yeah, that’s the idea of the change.

Mark Erhardt: Right. So, basically, we keep track of all the things that we want to announce in one global queue, and we keep only that global queue sorted. And then, whenever we want to refill what we announce to peers, we take the top of the global queue and put it into all of the peer buckets. And I think we flushed the entire peer queue each time when we announce to the peer; is that correct?

Martin Zumsande: Yes, we do. I mean, I think we still check if the peer still needs it. Maybe it has sent us the same transaction in the interim, so we can remove it from the per-peer queue. And I think we also sort it again, because maybe we have put things twice in there and then they’re not in the same order. But this is all very fast because the queue is, by definition, not large. But then, whenever the peer gets his turn, then we send all of the transactions we can and we always empty the queue, and that’s how it works now.

Mike Schmidt: What rate of transactions, roughly, would begin to cause an issue in the old way of doing things? I think it would be helpful for people to kind of wrap their mind around what sort of volume actually triggers where the CPU starts becoming an issue and you can observe it on the network?

Martin Zumsande: I would have to look up numbers, but if I remember correctly, the old rate that was allowed or by which we would drain the queue was 7 transactions per second. And I mean, what would happen would that this rate need to be exceeded for an extended time. Like, if someone just dumps 100 transactions or something, that’s not much happening, because this will sort itself out quickly. But if over a period of days or weeks, this rate is exceeded, then the transactions will just pile up over time. And then, they can get to these crazy numbers, like 100,000 that were seen in 2023.

Mark Erhardt: Yeah, I think this is 2023 April. Was that the runes launch? Or I think the runes launch on the halving. And a bunch of the people that wanted runes wanted to be in the first block in order to claim new rune names, and stuff like that. So, we also saw the highest fee block, I think 13 bitcoin or so in fees. And there were just thousands of transactions being added per minute. And then, that happened for hours or days, and then because the outflow of the queues was limited, the queues grew much larger. And eventually, the sorting of each peer queue became so much work that it wouldn’t be done by the time the next peer was supposed to get their message, and the CPUs just fell behind on weaker machines.

Martin Zumsande: Yeah, maybe another thing that is interesting is that usually, like when both of the peers relay transactions, then both of them work together and help to drain the queue. So, whenever my peer has sent me a transaction, I don’t need to send it to them. But what made it much worse, like in 2023, was that there were some peers that do not send any transactions themselves, but only one, ours, like spy nodes or monitoring nodes. And all of these would make the problem much worse because they would have the biggest queue, because in that case, only one side would drain the queue and not both sides, as in other cases.

Mike Schmidt: And maybe just a point of clarification the fact that it was around the halving and it was some spam scheme, or whatever it was, the content of the transaction doesn’t really matter. For example, if people just got really scared and decided to do a bunch of withdrawals from exchanges and the exchanges weren’t doing batching, and they had to send out each withdrawal separately, you’d get the same sort of concern and behavior around limiting in CPU on the network, right?

Martin Zumsande: Yes. I think in a way it was good that it happened organically, because if there had been some kind of attack, then the attacker could have not stopped or made it worse probably. But since it happened naturally in a way, at some point, I guess, the rune craze was getting a little bit lower, or whatever happened there; I didn’t really follow that. But at least at some point, the spam got a little bit less, and then the whole problem kind of fixed itself before the actual fix could be rolled out, because that takes always a couple of months, or weeks at least.

Mark Erhardt: Yeah, so I think at first, the limit was increased from 7 to 14 transactions per second that would be relayed. And then, yeah, we’ve had a series of other fixes now, and especially now with the one global queue, the sorting problem specifically is, of course, no longer a multiplied problem by peers times transactions, but only linear in the number of transactions, although it gets repeated. And yeah, so I think this is now the last piece of that series of fixes that comprehensively addresses the issue.

Martin Zumsande: Yes. Like, one small detail is that the doubling from 7 to 14 didn’t happen initially, it only happened last year. Initially, we did the other fixes, then the doubling, and now the final fix basically, well, hopefully.

Mark Erhardt: I think there’s also now a dropping transactions. If you’re getting too much from one peer, you stop accepting submissions from them. Do I remember that right? Do you know about that?

Martin Zumsande: I don’t think so. Maybe I forgot something. But as far as I know, as long as we accept the transaction and they have enough fee, we should …

Mark Erhardt: Well, maybe I’m making that up. Never mind then!

Mike Schmidt: And in terms of folks who are running a node, obviously, I guess the intended behavior is there’d be no change in behavior or anything that they need to do. They get a version of Bitcoin Core that has this PR in it, and they’ll just be, I guess, less susceptible to this CPU DoS when there’s high transaction relay on the network, right, nothing else for folks to actually do?

Martin Zumsande: Yes, exactly. This is all something that happens under the hood, and the normal user shouldn’t notice anything except that, I mean this year, there was a small dump event, or something, in February, or something, and some nodes would experience some, not as bad, but some increased CPU again, and that hopefully would not happen anymore.

Mike Schmidt: Well, we did cover this PR previously, it was #416. This is AJ Town’s PR I believe, who also did the post to Delving Bitcoin with a full writeup to have a discussion around it. We appreciate that, Martin, you took the time to join us today on the show to explain it for folks. But if anyone’s curious about more of the details, check out the PR itself, as well as the Delving discussion around it that we linked to from the newsletter this past week. Anything else, Martin?

Martin Zumsande: No, thank you. Thank you for having me.

Conditional message transfer contract to solve jamming

Mike Schmidt: All right, thanks for joining us, we appreciate your time. Cheers. Our last News item, which was the first News item chronologically, “Conditional message transfer contract to solve jamming”. This was a post to Delving from Antoine Riard, and maybe more of a brainstorm than a proposal, but he is trying to help mitigate channel jamming on the LN. It’s been a little bit since we talked about this, Murch, but we did have a flurry of activity, what was it, a year, year-and-a-half ago, talking about different channel jamming mitigations, and we talked about this idea of fast jamming and slow jamming. So, a Lightning node has resources that are scarce. There’s obviously the liquidity that you’re moving back and forth in these channels, and there’s a scarcity there, and then there’s also the scarcity of the actual HTLC (Hash Time Locked Contract) slots. And so, when someone is trying to fast-jam you, they’re trying to fill out those scarce HTLC slots; and when they’re slow-jamming you, they’re trying to hold on to that scarce liquidity.

We talked about different mitigations on both sides. On the fast-jamming side on the HTLC, the proposed defence was some sort of an upfront or unconditional fee to take up that HTLC slot; whereas slow jamming was a bit harder. We talked about different proposals around reputation of the peer who’s giving you the HTLC, HTLC endorsements, there’s this notion of accountability, all intended to help mitigate slow jamming. So, instead of directly charging for the amount of time that that HTLC and that liquidity is held, nodes were trying to identify traffic that has behaved well in the past and maybe give that traffic better access to those resources. Yeah, Murch?

Mark Erhardt: Yeah, to be clear, I think the concrete way this happens is that you set aside about half of your forwarding capacity, both in HTLC slots and in balance, and you only use that for reputable peers, so peers that have previously behaved well and closed their multi-hop payments quickly. Those over time would get reputation with you, and then you would let them allow the second half of your resources; whereas unknown peers, or anyone really on the network, can use the first half of your balance and HTLC slots. So, this would make sure that the reputable LN participants that you’re connected to would always have access to resources, because they’re generally kept aside.

This proposal now by Antoine seems to specifically address slow jamming, or it attempts to address slow jamming. Did you want to do it? I only read a little bit earlier.

Mike Schmidt: Go ahead, you’re going, I’m not going to stop you.

Mark Erhardt: All right. So, my understanding is that it tries to keep track of how long funds were held in a multi-hop payment, or in an HTLC, by making transaction commitments that record at what block height the channel partners communicated. And these updates would then eventually allow one of the channel peers to close the channel and take a fee, or close the HTLC or close the channel, I’m not entirely sure; but take fee depending on how long the HTLC was held. And the longer it was held, the more fee would be collected. And it uses basically the Bitcoin blocks as a universal time to record when the channel partners communicated, and use that as a measure for the amount of fees that are due. So, this would address slow jamming, because slow jamming, of course, is based on creating an HTLC and holding it for a long time, thereby denying the affected node’s resources. And if you get more fees over more time, that would make slow jamming more expensive and thereby mitigate the problem. Did you read more about it?

Mike Schmidt: No, I think that’s a good summary. He calls this conditional message transfer contract (CMTC) that will let the two peers, as Murch said, you can have cryptographically-verifiable states associated with the different Bitcoin block heights. And I think that there’s some maybe messaging between the two peers there to sort of sign off a long time that, “Hey, I don’t have it yet. Okay, now I do have it”. And then, there’s sort of a cooperative case, which would be they both agree that the person held for this many blocks and therefore the fee should be this. And then, there’s two failure branches in the conditional contract as well. I think the two branches are if either peer doesn’t respond, although I would assume within there is also if they’re uncooperative with the contract in some way.

Yes, so an attempt to mitigate slow jamming using hold fees, which we’ve talked about before. I think John Law had some stuff on this, but there was just never an idea of how to enforce the hold fee. And maybe to reiterate, the idea is this is liquidity that’s being held, and it’s sort of like you want to have a charge for that, because otherwise your liquidity could be elsewhere. You could be splicing it into some other higher-volume channel where you can make fees, or whatever you might be doing with it. And so, sort of like a little bit of an interest rate for holding that and then trying to use the Bitcoin block height as the timestamp for how long that that was held. One part, and I think it was Lloyd that brought it up, he was the one who responded in the Delving thread, and maybe, Murch, you can elaborate on this.

Mark Erhardt: I think it was waxwing, actually.

Mike Schmidt: Oh, waxwing. Block time, roughly ten minutes, but LN activity can be quite a bit faster. And so, I think what he brought up, at least in one of his points, was, “Is this granular enough to have it being basically ten-minute chunks that you’re trying to penalize against?” And I thought that was a good point. I don’t think there’s been a response to that yet, but Murch, do you have thoughts?

Mark Erhardt: I think that’s why I meant that it’s probably only going work for slow jamming. For fast jamming, the upfront fee is pretty simple and I think still being pursued. For slow jamming, the problem is that you either give people access to the resources or not, with the solution that is being pursued so far. But you can’t really charge more if an HTLC is held longer. And the strength of this proposal is that you can charge a different price for an HTLC depending on the duration. And yeah, I think HTLCs, by default, usually timeout within a day. Sometimes the maximum for stuff is, I think, two weeks. So, 1 block or 10 blocks or 100 blocks are big enough differences that you could have tiers of pricing that scale with the blocks. I think that could work. The proposal does strike me as relatively complicated. I think the construction is similarly complicated as HTLCs in the first place. We’ve had numerous bug fixes over the years with HTLCs being resolved incorrectly, and so forth.

I’m not sure if the complexity here is not maybe too high of a cost. That would be my bigger concern. Yeah, and then it seems fairly complicated, because it has to account for when one of the peers disappears or stops responding. And so, you still need this timing information, but then you need to be able to resolve when a peer gets disconnected. You have to also handle when the peer becomes reconnected and was just organically disconnected briefly, and so forth. So, I think this is a pretty early-stage idea, and I haven’t seen much interest from other Lightning developers so far.

Mike Schmidt: Yeah, I think the call to action here would be obvious then. This is an early stage idea to mitigate channel jamming, check out the Delving thread, participate in the discussion if it’s something that you’re curious about. That would be, I think, our call to action here. I think we can wrap it up.

BTCPay Server 2.4.2

All right. We can jump to Releases and release candidates. And the author of this segment, as well as the Notable code segment, is Gustavo, who’s going to walk us through these segments, starting with this BTCPay Server 2.4.2 security release. Hey, Gustavo?

Gustavo Flores Echaiz: Hey guys, thank you for the intro. So, this week we have three releases, all security focused. The first one, BTCPay Server v2.4.2, we had briefly discussed it in the last week’s episode. This is a security release that fixes a critical vulnerability that affects all releases before this version. And it specifically is related to nodes that run BTCPay Server instances that run LND nodes. When you update to the new version, your LND node will also update to at least v0.21.1, and your macaroons, which are your credentials to your LND node, will automatically be rotated. However, you can also manually update your macaroon credential files if you want to be extra careful. This was reported by Craig Raw after he was vulnerable to this attack. So, there are reports of this being exploited and funds being stolen, which indicates how urgent updating to the new version is.

There’s also a few other items included in this release, as discussed in last week’s newsletter, related to how TOTP (time-based one-time password) were also failing in the Greenfield API. So, an attacker could bypass this two-phase system using the Greenfield API, so there’s also fixes related to that. But the main reason for this security release is the LND issue. It’s also important to clarify that this doesn’t affect any user that was running any other implementation of Lightning, just LND. And also, onchain wallets are also secure, and not exposed to this risk.

LND v0.21.2-beta

LND v0.20.3-beta

The next releases are both from the LND repository. You have v0.21.2 and 0.20.3. Both of these releases are very similar. The difference between them is that one is for v21 and the other is for v20. The one that is for the v21 includes additional fixes of features that didn’t exist in v20, such as related to auxiliary channels, which are also known as Taproot Asset channels, and also onion message handling that also was added in v21, so it’s not included in the maintenance release of v20. A lot of these fixes, we’ve covered them previously in the newsletter. For example, one that we’re going to talk about in a second is related to a data race in a cooperative close state machine flow. But there’s other things, such as onion message decoding, payment migration, invoice updates, HTLC expiry and resolution. So, a lot of small fixes.

Another two we covered last week are also included in this release. So, one was about when forwarding a blinded payment, LND was unable to identify a node through its node ID, it was simply able to identify nodes through their short channel ID (SCID). So, that is also part of this maintenance release, if users are recommended to update to these new versions. And also, v21, the maintenance release for v21 doesn’t introduce new database migrations, but it includes important fixes to existing database migration paths. So, that is also important for users of LND to be aware.

Bitcoin Core #35493

Now, we start with the Notable code and documentation changes section. Once again, this week is very heavy with bug fixes. We start with the Bitcoin Core repo item #35493. Here, the background is that the importdescriptors RPC command was not properly updated when introducing MuSig to descriptors. So, in Newsletter #366, we covered how Bitcoin Core was now able to import MuSig to descriptors and how that was implemented. However, there was a bug where Bitcoin Core would treat this MuSig to descriptors similarly to how it would treat other type of descriptors. So, for example, it would always be looking for all corresponding private keys for every public key produced when expanding the descriptor, which would include the MuSig aggregate key, which obviously doesn’t have a standalone private key since it’s the aggregation of multiple other keys. However, Bitcoin Core was looking for that inexistent private key, and returning an error message indicating that there was a missing private key. So now, importdescriptors RPC is updated to not return an error when all private keys are present. Yes, Murch?

Mark Erhardt: Just to be clear, I think it is a warning that is being returned, not an error. So, as you said, a MuSig2 public key is an aggregate public key and doesn’t have a private key. The signature is produced by using multiple private keys together to create an aggregate signature. And so now, the import descriptors RPC correctly recognizes if the private key to that aggregate public key doesn’t exist. But if all the underlying private keys that are used to compose the signature are present, it no longer shows the warning. But it will show a warning if some of the private keys are there and not all. But yeah, it’s just a warning; it was a false warning that has been fixed.

Gustavo Flores Echaiz: Thank you for clarifying.

Mark Erhardt: Also, did you check, I think that was not released yet, right? So, this is not a bug fix in a released piece of software. I think this is just in the development branch, to be clear.

Core Lightning #9150

Gustavo Flores Echaiz: Right. Thanks for that, I didn’t check exactly, but that makes sense. Thank you for the clarifications. So, the next item, now we jump into the Core Lightning repo, item #9150. Here, the RPC command askrene, which we covered first in Newsletter #316, which is a new command that allows a Core Lighting (CLN) user to basically find minimum cost pathfinding based on an improved implementation of Pickhardt Payments. So, this is really about finding the most efficient path for a payment. And here, the update is that when making failed payments, the liquidity information of askrene would get updated. So, when later trying to find a path, it would know that a payment failed through this route and it would update in consequence. However, when making successful payments, askrene would not get updated at all. So, if the liquidity of a channel was consumed, there was no way for askrene to know about that.

So, the update here is to introduce something called impressions, which is a new type of information that records successful payments on askrene to adjust its liquidity estimates for subsequent attempts. And the goal here, as marked in the PR description, is to later introduce an RPC command, called repeatpay, for repetitive payments, which required having this first.

Mark Erhardt: So, for example something that you can learn is if you tried a channel before and the channel didn’t have enough capacity in a direction to route a payment, you would record that the channel wasn’t able to forward the payment in that direction, and that impression would then, over time, be discarded. I think also the same is true for channels where it did work, where the estimated capacity would then be set to at least the amount, or increased in the estimate.

I wanted to issue a correction on what I said just earlier about Bitcoin Core #35493. Importdescriptors was present in the 31 release. What I was thinking of was the import descriptors interface PR that we’ve been talking about recently in our office, not the importdescriptors RPC. Sorry about that.

Gustavo Flores Echaiz: Great, thanks for clarifying. So, that’s the main of CLN. However, there’s also another item, which is that now, when generating BOLT12 offers denominated in another currency, they now have a ten-minute expiry by default, because exchange rate fluctuates. So, you can lock in your exchange rate for a ten-minute period by default, which is obviously customizable.

BIPs #2248

The next two items are now from the BIPs repository. So, the first one, #2248, updates BIP3, which defines all the BIP Editors to remove Luke Dashjr following discussion on the mailing list. So maybe, Murch, you want to add extra context here?

Mark Erhardt: Yeah, I proposed that we remove Luke Dashjr from the BIP Editors. This follows a period of time in which he has contributed very little BIP Editor work, and then most recently has announced that he doesn’t want to have anything to do with Bitcoin. He calls it a different name. And I think it doesn’t make sense to have a BIP Editor that doesn’t want to contribute to Bitcoin anymore, especially privileges should only be held by people that use the privileges in order to provide the service that they have the privileges for. The principle of least authority is that people who have privileges that they don’t use lose those privileges. You should only have as much privileges as you need to do your job. If you’re not doing a job, you don’t need privileges. So, there had also been a few other things where people had a mixed bag of strong or less strong feelings about it. But after basically five years of not contributing to the BIP Editor work, we removed the BIP Editor privileges of Luke Dashjr. And this update just reflects that change, because it lists the BIP Editors in BIP3. And since Luke doesn’t have BIP Editor privileges anymore, he was removed from the list.

BIPs #2225 and #2245

Gustavo Flores Echaiz: Thank you, Murch. Next one, also from the BIPs repository, combines two different PRs, #2225 and #2245, both related to BIP110, and both following its unsuccessful activation attempt and its fork into a minority proof of work chain. The status has now been updated to ‘closed’ since this was unsuccessfully attempted. Anything you want to add here, Murch?

Mark Erhardt: Yeah, so I think we might have talked about this a while ago, but someone recently discovered that in February, the RDTS (Reduced Data Temporary Soft fork) implementation got a change that clarified that they meant P2A inputs to never have witness data, which is a different interpretation than the P2A BIP proposed, which suggested that Bitcoin Core would treat P2A inputs without witness data as standard but didn’t forbid witness data, because obviously an input that spends an output is a correct input, and inputs with witness data that spend a P2A output are still consensus-valid. So, they added this consensus change in the February update to their RC, or sorry, I think it was actually an activation client, and that was never documented in BIP110. So, that had been under discussion for a few weeks in the BIPs repository, but people couldn’t agree on the exact phrasing of how to record that additional consensus rule. So, the PR that got merged just added a line that said that RDTS clients would reject P2A inputs if they had witness data.

So, anyway, that got merged. And then, because the BIP110 activation attempt was unsuccessful and obviously so, with now, I think they found a fifth block last night, but we’re about 1,000 something blocks ahead, and it’s pretty clear that the Bitcoin Network didn’t adopt BIP110. So, it doesn’t look like anyone who’s working on Bitcoin is still working on BIP110, and the BIP was closed.

Eclair #3346

Gustavo Flores Echaiz: Thank you, Murch, for clarifying. Now we move to the Eclair repo. So, we’ve got once again bug fixes here. The first one is #3346. This combines about four different adjustments that could have resulted in bugs. So, the first one is that Eclair could obtain payment failure message from a recipient, but could interpret it as if it was a routing hop in, and then would then interpret the message as being a routing failure, when in fact it was an issue with the recipient. So, now Eclair verifies that the decrypted payment failure corresponds to an intermediate position before using it as routing information, since either a malformed or a maliciously crafted failure message from the recipient could have led Eclair to believe that it was an intermediate position and adjust its routing information; and even potentially, this could have caused an out-of-bounds access that could crash a specific component of Eclair, the payment lifecycle actor.

Also, when trying to RBF or simply when trying to broadcast a nonchain transaction, if Eclair received the response from Bitcoin Core an error message that it couldn’t classify, that it couldn’t properly map and recognize the error message, it could simply stop retrying to broadcast the transaction. However, as we know in Lightning, there are time-sensitive transactions. So now, Eclair is basically going to retry the broadcast of the onchain transaction, if it cannot properly map the error message it receives from Bitcoin Core. That’s the second fix included in this item. And the third one is when using CPFP when fee bumping to basically confirm a zero-fee commitment transaction that was broadcast by a peer, it wasn’t properly accounting for the full package weight, it was simply looking at the parent’s weight and not at the child’s transaction, which when doing CPFP, you have to look at both the parent and the child, both of their weights, to calculate a proper fee. So, that is now fixed.

Finally, the last fix is that when RBFing, when fee bumping a funding taproot channel transaction using MuSig2, Eclair would always assume that the latest RBF attempt was the one that confirmed, and would register the MuSig2 nonce that was used in that latest attempt, even though a previous attempt might have confirmed. So now, Eclair ensures that it will use the nonce associated with the attempt that actually confirmed when sending channel_ready instead of always assuming that its latest RBF attempt was the one that got confirmed.

Eclair #3341

Next item, still in the Eclair repo, #3341. This is more of a preparation for potential features rather than Eclair making a bug fix. But if it wasn’t properly addressed, it could have become an issue later. So, in BOLT7, there are message flags and channel flags, which are specific positions in a gossip message, are currently undefined. So, if Eclair received a bit of either those message flags or channel flags that was set to one, because these are undefined in BOLT7, it would simply discard that value and encode the bit as zero when forwarding a channel_update. However, this would modify the signed message and invalidate the signature. It’s not a problem because these are undefined and unused, but if later they would become defined and used for other features, then Eclair was modifying the signed message and then validating the signature. So now, Eclair, when forwarding a channel_update gossip message, will simply not touch these undefined bits, even if they’re set to values that it doesn’t recognize, so it will preserve the unknown flag values when decoding and recoding the channel_update message. So, this allows an Eclair node to relay these updates containing these flags, even if it doesn’t yet understand it. So, probably doesn’t have an immediate effect on the network, but if someone was to start using these bit positions as defined features, now Eclair will properly relay the channel updates without touching the bits that it doesn’t recognize, specifically what are called message flags and channel flags.

Mike Schmidt: I don’t think that this item was motivated by it, but I think the last Eclair item that includes those four bug fixes, I think tbast did a shout out to Rob Hamilton and the Red Team, that are doing a bunch of AI discovery on Bitcoin repositories and sending out responsible disclosures to those parties. So, it looks like some Bitcoin-related infrastructure is quickly making those fixes and rolling out the changes. So, shout out to the Red Team there.

LND #11019

Gustavo Flores Echaiz: Totally, that’s exactly right. Thank you, Mike. So, the next two items are from the LND repo. The first one, #11019, was part of the maintenance release that we discussed earlier in this episode, and you can find in the Release section of this newsletter. So, this is about a data race, a specific race condition, when following the legacy cooperative-close flow, where the link goroutine, which tracks the channels HTLC and commitment state, and the peer goroutine, which processes close messages from a remote peer, they advance concurrently and they could potentially clash. This could have led theoretically to disconnecting from a peer because you processed incorrectly their message, or you sent an incorrect message, or even theoretically it could lead to closing a channel or even crashing the node.

So now, instead of the link goroutine, which is what tracks the channel’s HTLC and commitment state, instead of advancing to the flow itself, it will report to the other goroutine, to the peer’s channel manager, to inform it that a channel has been flushed, that all the pending HTLCs have been drained, which is a step when making a cooperative close in the cooperative-close flow. So now, this one reports to the other instead of having both advance independently and potentially ending in a race condition.

There’s also another fix in this PR, which ensures that what’s called the RBF cooperative-close path, which is something that we’ve covered before – you can see in Newsletter #347 for when LND added it – it used to not check if a peer’s delivery script was valid when no upfront shutdown script was negotiated. So, what does that mean? When negotiating a channel, BOLT2 defines that a peer can define an upfront shutdown script, basically specify what his withdrawal address will be when they will close the channel. So, if a peer had specified this upfront shutdown script, LND was properly verifying that the delivery script, where the funds were going to go after the cooperative close, it matched the upfront shutdown script. But if no upfront shutdown script was present, LND was simply not verifying at all the peer’s delivery script, and was not even verifying that it was using an accepted output type. So, this was potentially causing failures in LND. So, this is now fixed. LND will simply always now verify the peer’s delivery script, even when no upfront shutdown script was negotiated and was present, to ensure that it uses the accepted output type for this type of transaction.

LND #11023

The next item in the LND repo as well is about basically putting limits to how much can a channel mailbox grow or also, how many update fee messages are stored. So, for example, when one Lightning peer, specifically the funder of the channel, communicates to his fellow peer to update the fee that will be used in the commitment channel updates, in the commitment transactions, because the onchain fees in its onchain node has changed, well before, LND would keep all update fee messages in storage. So, for example, if I told my peer every second to update the fee, my peer would simply keep all of those messages in storage. However, BOLT12 defines that this has a replaceable state model, so he only needs to keep the latest update fee message; an LND node doesn’t have to keep all the update fee messages stored. So now, LND is updated to simply only keep the latest message, to prevent redundant uncommitted fee updates from growing the update log. Of course, if a newer fee update arrives before the previous one had been included in the commitment transaction, LND now replaces the fee value.

There’s also a second part to this PR, which is limiting the size of channel mailboxes, which were previously uncapped. So now, you have 1,000 queued messages as one limit, and 4 MiB of serialized data as another limit. And also very important, LND could previously simply drop a message and then process the next one. But it’s important to keep the order of the channel state messages that you receive. So now, if LND reaches a limit, it will simply disconnect the peer instead of dropping the single message. And then, it will reconnect to the peer and re-establish the channel, which will trigger all the messages in the proper order.

Libsecp256k1 #1904

The next item is from the libsecp256k1 repo. We have a PR #1904. So, this is a follow-up to something we discussed in Newsletter #396, and which was also discussed in last week’s newsletter, when mentioning the latest release of libsecp. So, in PR #1777, as covered in Newsletter #396, libsecp added a new API endpoint which allowed applications to supply a custom SHA256 compression function at runtime. However, the test suite around these compressed functions was not as extensive. It was simply about hashing a single 63-byte message. So now, the test suite is expanded to cover multiple real situations where libsecp would use such a function, for example processing multiple blocks or using the SHA256 state of one block into another block. So now, the new test suite uses different message lengths and input alignments and has, of course, expected values that the external function has to arrive at the same results.

So, this is also very efficient. I believe in the PR description, yeah, when measured locally, this takes 0.05 milliseconds, so this is barely noticeable, while ensuring that an external provided function actually works in all the different situations that libsecp would handle it.

HWI #839

And finally, we have a fix in HWI, the Hardware Wallet Interface repo, item #839. Here, several issues are fixed about PSBT parsing and transaction reconstruction issues. So, these were first some test-vector suites that were present in BIP174 and BIP370 for a long time, but also some updates based on some test-vector suites that were added in the last few months, or at least in the last year, I believe. So, very technical detailed things, such as when reconstructing a transaction from a PSB2v2, HWI now applies the computed locktime instead of leaving it at zero when an input omits PSBT_IN_SEQUENCE. Also, for PSBTv0, HWI will now reject v2-only input and output fields. So, it ensures that v2 fields are not present in v0 PSBT. Also, it strictly parses the global unsigned transactions using non-witness serialization. So, yeah, I don’t know if someone wants to add here anything. Maybe, Murch, you have some comments because this relates to BIPs? No? So, if anybody’s curious, they can look at all the updates. There’s a few other ones, but they’re just fixes to match the HWI implementation to the test-vector suites of both the BIP174 and BIP370, which define PSBTv0 and PSBTv2. And that’s the last item from this list, and that completes the newsletter. Thank you.

Mike Schmidt: Great. Thanks, Gustavo, and thanks for co-hosting with Murch and myself, and we want to thank Martin and fanquake for joining us earlier, and for you all for listening. Cheers.

Bitcoin Optech Newsletter #418

2026-08-14T00:00:00+00:00

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

● 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.