This week’s newsletter summarizes continued discussion about using TCP hole punching to make nodes behind home routers reachable and describes a draft BIP for standardizing the spending policies that co-signers enforce when emulating covenants. 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

• ● Continued discussion of TCP hole punching for home nodes: Following our May summary of 0xB10C’s Delving Bitcoin thread on using hole punching to let nodes behind home routers accept connections from each other, 0xB10C posted that work has resumed on a specification and an experimental Bitcoin Core implementation. Home nodes can usually only make outbound connections, and turning on NAT-PMP port mapping by default in Bitcoin Core 30.0 did not make many more of them reachable as hoped. Hole punching, in which two home nodes open connections to each other at the same moment so that each router lets the other’s traffic through, would be a best-effort supplement to port forwarding. More reachable honest nodes would make it harder for attackers, whose nodes are easier to reach, to fill a node’s outbound connection slots.

  0xB10C recapped the four designs discussed so far and proposed a new option that needs no coordinator: a node announces its punchable address and a temporary public key in a new addr v2 type, and each pair of nodes derives the same candidate list and punch timing from their shared secret and each new block. In response to Anthony Towns’s objection that an attacker could flood the scheme with real addresses, and after later finding that unreachable nodes receive such announcements far less reliably than listening nodes, he sketched a “message board” alternative in which listening nodes hold the verified addresses of home nodes looking for a peer.

  Towns questioned whether random inbound connections help home nodes at all and argued that hole punching makes it easier for an attacker to reach honest nodes directly while doing little to guarantee a connection to an honest one. He estimated that an attacker advertising about 10,000 addresses would be an early match for most honest nodes and suggested short-lived connections to random peers as a lower-risk alternative. Jonathan Harvey-Buschel cited data showing honest nodes are less reachable than attacker-controlled ones and favored coordinating through a node’s own Tor service. Towns later asked whether recent TCP and protocol vulnerabilities make not accepting inbound connections the safer default for home users. Discussion is ongoing.

• ● BIP draft for standardized co-signer spending policies: Luke Carriere posted to Delving Bitcoin about his proposal for standardizing the spending policies enforced by co-signers when emulating covenants. Several recent designs, including Johan Halseth’s blinded co-signers and chain code delegation, each define their own policy, so a wallet built for one cannot use a co-signer or oracle built for another. Carriere is not requesting a BIP number for the draft and asked whether this is the right layer to standardize.

  The draft follows several design principles:

  • Anything that can be enforced by Bitcoin script must be enforced there, with co-signer policies only defining what script cannot.

  • At least one spending path that needs no co-signer must always be available.

  • How a co-signer verifies a spend, and what backs its honesty, are pluggable profiles chosen per policy.

  • Co-signers must accept oracle attestations in the DLC format so that already-available oracles can be reused with no modifications.

  A policy has five parts. The output defines the taproot descriptor that holds the funds, the co-signer group tells which co-signers take part and how many must sign, templates list the transactions the co-signers may sign with their exact outputs, conditions state what must be true before each template can be signed, and profiles name the verification mode, evidence formats, and any accountability scheme. Some points remain open, such as whether to use JSON or TLV for serialization, whether blinded verification should be specified now or wait for more implementation experience, whether to specify statement attestation format in the proposal or in the DLC specifications, and whether the fallback path must be timelocked.

  In the discussion that followed, PREDGE pointed out that one of the evidence profiles, called statement-v0, lacks a finality flag, meaning that a co-signer could act on a provisional attestation later corrected. Moreover, tehiyadu stated that the policy hash should commit to the exact verifier semantics to prevent different implementations from accepting the same bytes while enforcing different conditions. Carriere agreed with both points and said he would add a finality flag and pin down the verifier rules.

Changing consensus

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

• ● Continued discussion of BIP54: Antoine Riard posted to the Bitcoin-Dev mailing list about his perspective on the state of the consensus cleanup soft fork (BIP54). Forbidding transactions whose witness-stripped size is exactly 64 bytes is still the most contested rule. A Bitcoin Core implementation is under review and testing and is the reference implementation linked from the BIP (Bitcoin Core #35793). The PR enables the new rules on regtest with no mainnet activation. He also pointed to interoperability work in btcd (btcd #2537) and said he knows of no libbitcoin implementation. In his view what remains is more review and testing, documentation so wallets know about the proposed limit of 2,500 signature operations in pre-segwit script and about the 64-byte rule, and, only later, activation logic. Speaking only for himself, he thought it could be realistic to start considering activation in the second half of 2027 if the community agrees by then.

  Pieter Wuille updated his Delving Bitcoin thread on how the two BIP54 timestamp rules bound chain length (see Newsletter #425). The top post now includes the accurate formula for the lower bound on work, and both that formula and the decimal approximation are now proven in the linked Lean code.

  Riard followed up on an objection raised during the design of BIP54: that fixing the time warp bug would make a consensus change in the style of Mark Friedenbach’s forward blocks impossible for the rest of Bitcoin’s future history. Because the fix constrains timestamp manipulation rather than removing it, a much more limited forward blocks proposal could still be implemented. He estimated that the 7,200-second window still allowed by the fix could lower difficulty by roughly 0.60% per retarget period, and raise the block rate by about as much, far short of the capacity increase of the original proposal. Riard also argued the idea is unsound even with the old rules: validators would process transactions once on the forward chain and again when they are synchronized onto the compatibility chain, for the same fees unless users paid twice, and nodes that had not upgraded would still have to download the extra data. Riard will propose a short BIP54 footnote making that case, and ask Friedenbach for counter-arguments.

• ● Opt-in replay protection prototype: Sjors Provoost followed up on the Delving Bitcoin thread about opt-in replay protection for a chain split (see Newsletter #420) with a prototype that uses a new witness version. An annex whose payload starts with the byte 0x01 names a block by a 4-byte height, and every signature on that input commits to the block’s hash on the desired chain. The hash itself is not present in the transaction. He put the extra cost at 1.75 vbytes. The named block must be at least 100 blocks old, the same horizon as coinbase maturity. He said that if hashrate were split evenly, the wait before coins could be split would be two days at worst, because the rule only has to hold on one side. He suggested shipping the witness version together with another proposal that needs one, such as CISA (BIP460), BIP360, or a P2TRv2-style output with a keypath that can later be disabled.

  Anthony Towns replied that a new witness version is unnecessary, and that a new public-key encoding for a taproot signature check, in the style of BIP118, would be enough. Provoost answered that he had considered that encoding and thought it a hack, and that as he understood it, it would not work for a keypath spend.

  Moonsettler questioned whether requiring 100 blocks is desirable in the split where the feature would matter most, and suggested keeping that delay as a policy rule that could be relaxed. Provoost replied that after coins move on the faster side and gather confirmations, the slower side no longer needs the protection. Provoost also wrote that he expects the rule to be deployed before a contentious hard fork, so both sides inherit it, and that neither side can easily drop it: the block hash is only in the signature message, so removing the rule means changing transaction serialization to carry the hash.

• ● QSAVE for unmigrated coins: James Tagg posted to the Bitcoin-Dev mailing list five draft BIPs for QSAVE (Quantum Secure Asset Verification and Escrow), a post-quantum transition that does not burn coins. He described these as an alternative to BIP361 and to Hourglass. From an enforcement height, which could be activated as a soft fork at any time, any input that is not on a registry of known post-quantum types would be treated as unmigrated, including unknown and future script types. An unmigrated input would still need to satisfy its locking script, and also a second factor: either a zero-knowledge proof that one seed derives both the spent script and a post-quantum key, or a post-quantum binding committed before a cutoff. If any unmigrated input in a transaction lacks that second factor, every spendable output must be a recovery output. In QSAVE, there is no sunset, so a missing second factor does not destroy the coin. An onchain proof can always spend it directly, with no third party. Otherwise he described an offchain lost-property process, whose legal and economic treatment he placed outside consensus, in which a set of decentralized custodians would hold the recovery outputs, with a backup custodian and a veto controller, and the funds could earn a conservative 0.5% return directed to charity. The drafts also specify pre-cutoff watermarks, an optional ML-DSA-87 key he called QD5, and a zk-STARK spend leaf for BIP360 (P2MR) outputs.

• ● Proof-of-decay for unmigrated outputs: bitKingAE posted to Delving Bitcoin a sketch for shrinking post-quantum-exposed outputs, such as early P2PK coins, that are not moved within a grace period. After the grace period expires, the output’s value would fall on a schedule with block height. The lost satoshis would be burned or paid out as mining rewards rather than the coins being frozen or left for whoever can produce a signature. The post’s example was a small percentage of the balance every 50,000 blocks. Vinicius Cestari replied with three objections: a quantum attacker can wait until the grace period ends and sweep exposed outputs before the decay has done much; a sudden improvement in quantum attacks can drain them even earlier; and the schedule reduces the balance of a passive owner, including one whose keys were already stolen.

• ● BIP300 bundle censorship: Ori Newman argued on the Bitcoin-Dev mailing list that a miner with 26% of hashrate can censor a valid withdrawal bundle in the drivechains proposal (BIP300) indefinitely. He wrote that if the 26% miner sends an ALARM in every block it mines, each of those blocks lowers the score of every pending bundle by 1. If the other 74% of hashrate upvotes a bundle in every block, its expected score would be 12,624 at the end of the 26,300-block window, short of the 13,150 required. He suggested forbidding ALARM and any other downvote, which would restore an honest majority assumption: a bundle supported by 51% of hashrate would almost certainly pass, and one supported by 49% would almost certainly fail. If the current rule is intentional, he asked that the BIP instead state a 75% honest majority assumption. He called that a strong departure from Bitcoin’s security model, and said one argument for it is that stealing funds would be harder for an attacker with less than 75% of hashrate.

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.

• ● LND v0.21.6-beta and v0.20.7-beta are security releases for the 0.21 and 0.20 branches of this popular LN node implementation. Both include the mitigation for the Linux kernel vulnerability CVE-2026-98432 described under LND #11456 below. Linux operators should upgrade, disable MPTCP on the host to protect other services, and install a patched kernel, since the LND mitigation does not fix the underlying vulnerability.

• ● Core Lightning 26.06.10 is a security release of this popular LN node implementation. It fixes vulnerabilities in dual funding, splicing, onchain HTLC resolution, access controls, and other components. Source code for the security fixes is available, while associated tests are temporarily withheld to give users more time to upgrade. The project strongly recommends upgrading.

• ● BTCPay Server 2.4.7 is a security release of this self-hosted payment processor. It fixes 85 security findings reported by Anthropic’s OSS Scanner program, including issues affecting payout limits, access to other stores’ data, authentication, and resource exhaustion. It also fixes payment-accounting and reliability issues. Updating is strongly recommended, especially for servers shared by multiple merchants.

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 #36539 restores the PSBTv0 format for unsigned transactions and fee bumps exported from the GUI. Bitcoin Core 32.1 exported these PSBTs using version 2, preventing users from signing them with tools that only support version 0. The separate external-signer workflow configured with -signer (see Newsletter #138) continues to use PSBTv2, so those users need an external signer that supports it, such as HWI 2.1.0 or later.

• ● Bitcoin Core #35714 fixes a bug where the node could update its block index and UTXO database after failing to flush block or undo data to disk. Although the failure signaled the node to shut down, the code handling these writes could still update the databases before the node stopped. If these updates succeeded, the databases could record a state for which the supporting block or undo data had not yet been safely saved. This could leave the node’s local state inconsistent and complicate recovery. The code now skips those database writes during the failing flush attempt. This complements earlier flush ordering protections for optional indexes covered in Newsletter #414.

• ● Bitcoin Core #35492 fixes a bug where bitcoin-wallet dump (see Newsletter #130) could report success after writing an incomplete wallet export. Previously, the command checked if it could open the destination file but did not detect subsequent write failures, such as running out of disk space. Consequently, users could mistakenly believe that the export was complete, only to discover missing data when trying to restore the wallet. Now, the command verifies the writing, flushing, and closing of the file. It reports failures and removes incomplete dump files.

• ● BIPs #2205, #2210, and #2212 add three draft specifications for cross-input signature aggregation. BIP458 specifies non-interactive half aggregation, combining n existing BIP340 signatures into 32 × (n + 1) bytes instead of 64 × n bytes. BIP459 specifies DahLIAS, an interactive protocol that produces a single 64-byte aggregate signature for multiple keys and messages. BIP460 proposes using these schemes for keypath spends of new witness-version-2 outputs, while retaining individual signatures for scriptpath spends and allowing keypath inputs to opt out. Since the proposal was covered in Newsletter #417, opted-out inputs have been changed to use ordinary BIP341 signatures without a special marker, allowing wallets to adopt the new output type while reusing their existing signing logic. This would reduce transaction weight and fees for transactions with multiple participating inputs, including coinjoins and payjoins. Deploying the proposed transaction aggregation would require a soft fork. BIP460 leaves the activation mechanism and parameters unspecified.

• ● Core Lightning #9419 adds an optional failure_reason field to the listforwards RPC and forward_event notifications for locally failed forwarding attempts. Previously, several distinct problems shared the same protocol failure code, which made it difficult for operators to determine why forwarding failed. The new field distinguishes between causes such as insufficient outgoing liquidity, an offline outgoing peer, and limits on the number or total value of pending HTLCs.

• ● Core Lightning #9592 updates xpay (see Newsletter #330) to avoid a forwarding node for the remainder of a payment after it twice returns unknown_next_peer. Previously, each failure excluded only the reported channel, so successive attempts could keep selecting other channels through the same node until the payment’s retry time expired. Now, after the second failure from the same node, xpay excludes it through the payment’s private askrene routing layer. This heuristic can exclude usable channels, but limits repeated attempts through the same node.

• ● LDK #5089 updates fee bumping during force closes of channels with anchor outputs. If LDK cannot obtain the necessary funds for a CPFP child transaction that spends an anchor output, it now broadcasts the commitment transaction alone. Previously, this failure could leave both transactions unbroadcast, delaying recovery of channel funds. The commitment already includes a fee, which may still be sufficient for confirmation if the fee estimate was conservative or network demand falls. However, this fallback excludes zero-fee commitment transactions, which require a fee-paying child transaction for relay. The issue was reported by Project Loupe.

• ● LND #11456 disables Multipath TCP (MPTCP) listeners by default to mitigate CVE-2026-98432, a Linux kernel vulnerability for which remote code execution was demonstrated using MPTCP. Go 1.24 and later enable these listeners by default on supported Linux systems, which could expose LND operators even if they don’t explicitly configure MPTCP. The change sets multipathtcp=0 in LND’s Go defaults. This blocks the demonstrated exploit path through LND’s listeners, but does not fix the underlying kernel bug. Affected systems still require a patched kernel. Operators using existing binaries can apply the same mitigation by restarting LND with the environment variable GODEBUG=multipathtcp=0.

• ● LND #11357 tightens BOLT11 invoice validation following BOLTs #1357 (see Newsletter #428). Instead of using the first and ignoring the rest, it now rejects duplicate payment secret fields, preventing ambiguity between parsers that select different occurrences. This builds on the earlier rejection of duplicate payment hashes (see Newsletter #425). Tests added by the specification update also revealed that existing requirements were not being enforced. The decoder now rejects incorrect lengths when parsing the payment hash, description hash, payment secret, and receiver public key, instead of treating those fields as absent. Previously, an incorrectly sized receiver public key field could cause LND to fall back to recovering the key from the signature. For invoices containing an explicit receiver public key, a low-S ECDSA signature is also required. However, this restriction does not apply when the public key is recovered from the signature (see Newsletter #381).

• ● LND #11413 speeds up the startup cleanup of stored outgoing payment results on nodes using SQLite or PostgreSQL. During normal operation, the node accumulates a result for each resolved, locally initiated HTLC attempt. At startup, it removes results that are no longer needed. Previously, reading and deleting entries individually required repeated database round trips, which could make cleanup take hours on a busy node using remote PostgreSQL. Now, cleanup batches database operations while preserving the results needed to resume pending payments.

• ● LND #11151 adds checks for excessive commitment feerates and inadequate initial balances when accepting incoming channels. LND now rejects a proposed feerate above the greater of ten times its three-block estimate and 100 sat/vbyte. It also enforces BOLT2’s initial-reserve rule and separately rejects channels where neither party’s initial balance exceeds the reserve that party must maintain. Although the initiator pays the commitment fee, an excessive fee can consume their usable balance, wasting the receiver’s pending-channel capacity during opening and leaving behind an unusable channel once the funding transaction is confirmed. This complements the minimum feerate checks covered in Newsletter #429.

• ● Rust Bitcoin #7067 extends the taproot signature hash (sighash) helpers to accept an optional annex and, for scriptpath spends, the opcode position of the last OP_CODESEPARATOR executed before the signature check. Both affect the message that a signature commits to. Previously, these convenience functions assumed no annex and no executed OP_CODESEPARATOR, so callers handling such spends had to use the more general sighash function to avoid producing an incorrect digest. The helpers now accept these values directly, although callers must still determine the separator position. Callers handling spends without an annex or an executed OP_CODESEPARATOR can pass None for the new arguments to retain the previous behavior. See Newsletter #427 for related sighash API changes for legacy and segwit v0 spends.

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm at 16:30 UTC on November 10. The discussion is also recorded and will be available from our podcasts page.