Bitcoin Optech Newsletter #429 | Bitcoin Optech

This week’s newsletter describes a protocol for creating silent payment
transactions from multiparty wallets, summarizes the responsible disclosure of
a denial-of-service vulnerability that affected older versions of Core
Lightning, and explains Bitcoin Core’s updated security policy for easily
discoverable vulnerabilities. Also included are our regular sections with
selected questions and answers from the Bitcoin Stack Exchange, announcements
of new releases and release candidates, and descriptions of notable changes to
popular Bitcoin infrastructure software.

News

• ● Silent payments for multiparty wallets: Oleksandr Kurbatov
  posted to Delving Bitcoin to describe a protocol
  to use multiparty inputs in silent payment
  transactions. BIP352 does not recommend using that kind of
  input due to lack of a security proof. The protocol allows
  a multiparty sender to compute the ECDH share as a weighted sum of
  the signers’ contributions, while providing an aggregated
  DLEQ proof, called AggDLEQ, to prove that the ECDH
  share is correctly derived from the input key. The proposal works
  with several multiparty protocols, such as FROST
  and MuSig2.

  The proposed protocol relies on two rounds. A coordinator provides
  context, containing signer set, signing protocol coefficients and
  tweak, key material, the transaction, and a session ID. During the
  first round, each signer generates two random nonces and sends messages
  needed for AggDLEQ back to the coordinator, such as the ECDH
  share computed from their own key fragment and nonce commitments.
  Those messages are used by the coordinator to compute the combined
  ECDH share and a challenge. During the second round, each signer
  produces a contribution to the proof based on the provided challenge.
  If the responses are correct, the coordinator aggregates all the
  responses into a single proof compatible with BIP374.

  Kurbatov stated that the protocol needs no changes to BIP352, BIP374,
  BIP375, or the MuSig2 and FROST signing protocols, and no new PSBT
  fields, because the AggDLEQ messages are exchanged only between the
  signers over the wallet’s coordinator channel. He said a paper with
  security proofs is under internal review, but noted that its claim that
  corrupted signers and the coordinator cannot forge a proof or a
  signature relies on an assumption whose hardness is an open question.

• ● CLN self-referential channel announcement DoS disclosure: Nishant
  Bansal posted to Delving Bitcoin disclosing a
  denial-of-service vulnerability affecting Core Lightning (CLN) versions
  25.02 through 26.04. CLN never checked that the two node IDs in a
  channel announcement differ, so an
  announcement naming the same node as both endpoints passed validation and
  was written to the on-disk gossip store before being loaded into the
  in-memory channel graph. Loading it added the unknown node twice, which
  tripped a no-duplicates assertion in gossipd and crashed the node. The
  stored message then crashed the node again on every restart until the
  operator removed it by hand, which upgrading alone did not do.

  An attacker only needed to fund a 2-of-2 output it controlled and sign the
  announcement with those keys and a fresh node key, so the cost was limited
  to onchain fees. Older CLN releases accept and relay such an announcement
  without crashing, so they could carry it to vulnerable nodes the attacker
  could not reach directly.

  Bansal found the bug with a gossip fuzz target later proposed in Core
  Lightning #9115. It was responsibly disclosed in April and fixed in CLN 26.04.1 (see
  Newsletter #398) by Core Lightning #9082, which
  rejects any announcement whose node_id_1 is not strictly less than
  node_id_2. BOLTs #1333 added the same receiver requirement to
  BOLT7, which had only required senders to order the IDs. Operators
  still on an affected version should upgrade to the latest release.

• ● Bitcoin Core security policy update: Antoine Poinsot posted to the Bitcoin-Dev mailing list that Bitcoin Core has amended its
  security policy (see Newsletter #306) for vulnerabilities it classifies as easily discoverable, such
  as those found with a simple prompt to a large language model. The
  project has seen an increase in reports of such bugs, which can be
  rediscovered or inferred from covert fixes. Rather than wait for the next
  major release and the severity-based embargo the policy otherwise applies,
  Bitcoin Core now backports a fix to every maintained release, cuts point
  releases as soon as possible, and publishes an advisory alongside them. The
  three vulnerabilities described in this week’s notable code section (Bitcoin
  Core #36665, #36667, and #36669) were disclosed under the new classification. Their fixes were merged
  after 32.0 had been tagged, so 32.0 was never released and Bitcoin Core
  32.1 (described below), along with 31.2, 30.4, and 29.5, ships them
  instead.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange is one of the first places Optech
contributors look for answers to their questions—or when we have a
few spare moments to help curious or confused users. In
this monthly feature, we highlight some of the top-voted questions and
answers posted since our last update.

• ● Why does Bitcoin use both a transaction ID and a witness transaction ID?
  Pieter Wuille explains that segwit moved signatures and
  other malleable data into the witness, which the txid excludes, so that
  presigned chains of unconfirmed transactions keep working. Inputs therefore
  still reference txids. Blocks additionally commit to wtxids so that a node
  handed a block with tampered witness data can reject it permanently rather
  than reprocess every variant a peer offers. BIP339 later extended wtxid
  use to transaction relay for similar denial-of-service reasons.

• ● How to sign a MuSig with Bitcoin Core Ava Chow explains
  that MuSig2 signing takes two rounds, so each wallet must
  process the PSBT twice. The first pass adds the wallet’s public
  nonce and the second, run on the combined PSBT once every nonce is present,
  adds its partial signature, after which finalizepsbt produces the
  transaction. The asker published an example of creating and
  spending from a MuSig2 address with Bitcoin Core.

• ● What changed in Bitcoin P2P protocol version 70017 compared to 70016?
  Ava Chow explains that BIP434 assigns the new version number because it
  introduces a new feature message exchanged during the version handshake.
  The message itself lets peers announce and negotiate optional features for
  the life of a connection, replacing the historical practice of bumping the
  protocol version or defining a dedicated message for each new feature (see
  Newsletter #386). Bitcoin Core implemented the message and
  the version bump earlier this year (see Newsletter #410),
  and both ship in Bitcoin Core 32.1, described below.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure
projects. Please consider upgrading to new releases or helping to test
release candidates.

• ● Bitcoin Core 32.1 is the latest major release of the network’s
  predominant full node implementation. Version 32.0 was tagged but never fully
  released because of last-minute issues. This release includes the three
  security fixes described below. Other changes include
  mempool-based fee estimation, PSBTv2 by
  default, watch-only wallet exports, and faster block validation. Existing
  transaction and transaction-output-spender indexes remain compatible but
  must be rebuilt to save disk space. See the release notes for
  details and upgrade considerations. Versions 29.x and earlier have reached
  the end of their lifecycle and will no longer receive updates.

• ● Bitcoin Core 31.2 is a maintenance release of the predominant
  full-node implementation. It includes the same three security fixes as
  32.1. It also excludes the version bits that BIP323 reserves as
  extra nonce space for miners from the BIP9 unknown soft fork warning
  (see Newsletter #409), caps the -privatebroadcast
  queue at 10,000 transactions, and compacts the chainstate database
  regularly. See the release notes for details.

• ● Bitcoin Core 30.4 is a maintenance release for a previous major
  release series. It includes the same three security fixes as 32.1, the
  BIP323 warning change, and the removal of one DNS seed. See the release
  notes for details.

• ● Bitcoin Core 29.5 is a maintenance release for a previous major
  release series. It includes the same three security fixes as 32.1 and the
  removal of one DNS seed. See the release notes for details.

• ● Eclair 0.14.6 is a security release for this LN node implementation. It
  includes the splicing force-close and on-the-fly
  funding fee-tracking fixes described below. The project
  strongly recommends upgrading because malicious peers can exploit some of the
  fixed issues.

• ● LND v0.21.5-beta and v0.20.6-beta are maintenance
  releases of this popular LN node implementation, following the release
  candidates covered in Newsletter #428. Both
  include the commitment feerate fixes described below, as well as fixes for
  excessive memory allocation when parsing TLV records and SQL database
  deadlocks, and faster startup cleanup on SQL-backed nodes.

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 #36665 fixes a memory-exhaustion vulnerability that allowed a connected peer to crash nodes running on Windows, macOS,
  or BSD. Although Bitcoin Core pauses reads from a peer when its receive queue
  grows too large, its select() socket backend continued monitoring
  exceptional conditions. A peer could send TCP urgent data to trigger further
  reads and bypass the queue limit. Now, exceptional conditions are only
  monitored when reads are enabled for that socket. Linux uses a different
  socket backend and was unaffected.

• ● Bitcoin Core #36667 adds a timeout that disconnects a peer if the node’s
  send buffer for that peer exceeds its limit for more than 20 minutes,
  mitigating unbounded memory growth. Bitcoin Core
  continues to queue some transaction announcements even after this limit is
  exceeded. Typically, a ping timeout would eventually disconnect a
  slow-reading peer. However, peers claiming a protocol version predating
  BIP31 could avoid this. This would allow a malicious peer to maintain an
  open connection while queued announcements gradually accumulate. The new
  timeout applies regardless of the peer’s protocol version. Nodes using the
  -blocksonly option were much less affected.

• ● Bitcoin Core #36669 fixes an undo-file overflow
  that could corrupt data needed to disconnect blocks during a reorg. Since
  undo data can exceed the size of its corresponding block data, an undo file
  can exceed 4 GiB and wrap its 32-bit offset, thereby overwriting earlier
  data. A subsequent reorg could stop the node, requiring reindexing with a
  fixed version to recover. The fix increases the file offset size to 64 bits.
  It also uses 64-bit file positioning calls on Windows, where exceeding 2 GiB
  could stop the node even without a reorg. Exploitation requires mining
  thousands of specially constructed blocks. For the corruption case, it also
  requires precisely positioning those blocks within the targeted node’s block
  files, followed by a reorg. The disclosure deems this impractical. Nodes on
  32-bit systems or FAT32 block storage are still affected.

• ● BIPs #2130 adds draft BIP139, Wallet Metadata Export Format,
  specifying a JSON format for exporting wallet accounts and their output
  script descriptors, signer information, labels, transactions, coins, and PSBTs (see Newsletter
  #399). This format enables the transfer of metadata
  between wallets and the restoration of information that cannot be recovered
  by a seed backup alone. The specification prohibits including spending
  private keys or mnemonic seeds in mainnet exports, so these exports
  complement a separate key backup.

• ● Core Lightning #9627 updates xpay to account for BOLT4’s 1,300-byte
  routing information limit for the payment onion before selecting a payment
  route. Previously, pathfinding could succeed, but onion construction could
  fail if the selected path exceeded the limit. This could cause a payment to
  fail even when a shorter path might have worked. xpay now calculates the
  available space after accounting for the receiver’s final payload or the
  invoice’s blinded path, then passes a corresponding hop
  limit to askrene through a new maxhops parameter on its getroutes RPC.
  The pathfinding cost calculation in askrene also adds a penalty for each
  hop to favor shorter routes.

• ● Eclair #3417 and #3419 improve force-close handling when
  splice transactions remain unconfirmed (see Newsletter
  #427). For non-zero-conf channels, Eclair now
  selects the newest commitment whose funding transaction is confirmed or
  present in its Bitcoin backend’s mempool, reevaluating that choice as blocks
  arrive or as splice transactions are published. It also includes unconfirmed
  funding ancestors in anchor CPFP fee calculations and starts
  claiming outputs of non-revoked remote commitments for earlier funding states
  after one confirmation. The new require-confirmed-inputs-for-splicing
  setting, enabled by default, requires confirmed inputs from the peer when
  splicing and prevents Eclair from initiating another splice until the
  previous one confirms. The changes also ensure that a previously published
  local commitment is recognized if it confirms after Eclair switches to a
  different commitment. Previously, Eclair could leave its own balance and
  HTLC outputs unclaimed.

• ● Eclair #3416 fixes a bug that allowed a peer to repeatedly obtain
  on-the-fly funding without paying the agreed-upon
  liquidity advertisement fees. Previously, a
  peer could reject the proposed payments intended to cover these fees, yet
  Eclair could still complete the liquidity purchase. Now, Eclair flags
  underpaid purchases and blocks the peer from making further purchases paid
  from future payments (from_future_htlc). Settling other parts of a
  multipath payment does not clear the flag.
  Flagged peers count toward the existing suspicious-peer limit, which disables
  this payment method globally once it is reached. Flags are cleared on
  restart, through operator intervention, or if the funding transaction is
  aborted before publication.

• ● LDK #5314 fixes a privacy leak in onion message
  forwarding that could link an unannounced channel to its onchain funding output. An attacker could derive a candidate
  short channel ID (SCID) from an output’s blockchain location. By connecting
  to both suspected channel endpoints and sending an onion message through them
  back to itself, the attacker could use the SCID to identify the channel
  between them. Receiving the message would confirm the link between the output
  and the nodes. LDK now refuses to resolve real SCIDs for unannounced channels
  when forwarding onion messages. SCID aliases remain usable. This complements
  the HTLC-forwarding privacy protections covered in Newsletter #426.

• ● LDK #5412 fixes a denial-of-service bug in its LSPS2 server for
  just-in-time channels. Previously, a client could
  submit the same request ID repeatedly while the original request remained
  pending. Each duplicate increased the service-wide pending-request counter
  and replaced the stored entry. Reaching the 1,000-request limit caused the
  LSP to reject requests from other clients, despite having far fewer requests
  to process. Duplicate IDs are now rejected without increasing the counter or
  replacing the original request.

• ● LND #11164 advances its gossip-v2 implementation by updating message
  formats to match the latest taproot gossip proposal, which
  would allow nodes to announce and verify taproot channels. Signature-exchange messages now include the funding
  transaction ID to distinguish funding attempts in preparation for
  splicing and carry separate MuSig2 partial
  signatures for the node and funding keys. The changes also correct the
  encoding of the fee and capacity fields and preserve optional fields
  containing default values. This preserves the signed bytes when messages are
  decoded and re-encoded, thus preventing signature verification failures.

• ● LND #11373 and #11380 enforce LND’s existing minimum
  commitment feerate of 253 sat/kw consistently during channel opening and fee
  updates. Previously, setting max-commit-fee-rate-anchors=1 capped the rate
  at 1 sat/vbyte, equivalent to 250 sat/kw, slightly below the minimum. A
  channel could open at that rate, but it could not carry HTLCs
  until its initiator increased the rate because subsequent commitment updates
  would reject it. LND now raises locally proposed opening rates to the minimum
  and rejects incoming proposals below it. It also checks incoming and outgoing
  fee updates against the minimum before recording or sending them, instead of
  only rejecting them when signing commitments. LND attempts to raise the
  feerate of existing channels opened below the minimum, but those channels
  remain unable to carry HTLCs if their initiator cannot afford the increase.

• ● BTCPay Server #7744 and #7748 fix two errors when
  merchants authorize application API keys. Optional permissions that a
  merchant unchecked could still be granted. Additionally, an application could
  request a permission scoped to another store and have that scope used instead
  of the store selected by the merchant. The fixes preserve the merchant’s
  permission choices and remove application-supplied store scopes before
  applying the merchant’s store selection. These changes affect key issuance,
  following the permission-enforcement fixes covered in Newsletter
  #428. Previously issued keys retain their permissions
  and may need to be revoked if they grant unintended access.