Bitcoin Optech Newsletter #430 | Bitcoin Optech

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.