Bitcoin Optech Newsletter #428 | Bitcoin Optech

This week’s newsletter describes a design for a single-issuer layer 2 whose
users can redeem their bitcoin onchain without the issuer’s cooperation and
summarizes a proposal for including hash preimages in output script
descriptors. Also included are our regular sections describing recent changes
to services and client software, announcing new releases and release
candidates, and describing notable changes to popular Bitcoin infrastructure
software.

News

• ● Trust-minimized exits from a single-issuer layer 2: Adam Gibson
  posted to the Bitcoin-Dev mailing list a paper
  and proof-of-concept code for Lichen, a design in which a
  single issuer, which Gibson calls a hub, mints tokens redeemable one-to-one
  for bitcoin on a layer 2 ledger run by a server called the sequencer. Each
  user holds a 2-of-2 contract with the hub that lets them redeem their tokens
  even if the hub refuses or is offline, so users trust the sequencer to run the
  ledger honestly but not the hub to return their bitcoin. The design builds on
  LN-GAP (see Newsletter #427) but replaces its honest-majority
  attestation committee with a dispute settled entirely onchain.

  Each user locks bitcoin in their own 2-of-2 output with the hub and receives
  the same amount of tokens on the layer 2 ledger, where users pay each other
  without touching the chain. To exit, a user hands tokens back to the hub and
  collects bitcoin from their own output. Because that output is the only one a
  user can draw on, the hub also locks some of its own bitcoin in each output up
  to a negotiated cap, like LN inbound liquidity, so that the user can redeem
  tokens received from others. Tokens received beyond the cap are redeemable
  only at the hub’s discretion.

  In the cooperative case, the hub simply signs a settlement of the output
  paying the user. If it refuses or does not respond, the user generates a
  Groth16 proof that the sequencer signed a state recording the returned tokens.
  Since Script cannot verify such a proof, the user instead claims onchain that
  a fixed verifier program accepts it, and if the hub disputes that, presigned
  BitVMX transactions narrow the disagreement to a single execution
  step that Script can check. Each side locks a reserve that it forfeits by
  losing a dispute, deterring false claims and refusals. Gibson acknowledges
  that a sequencer that omits a user’s return, or signs a state it never validly
  reached, can still cost the user or the hub funds, and lists validity proofs
  and a committee of sequencers as future work.

• ● Descriptor syntax for hash preimages: João Dias posted to
  Delving Bitcoin a proposal for extending BIP379 to add a private form
  for hash fragments to miniscript. As of today, there is
  no way to directly give a preimage to Bitcoin Core’s wallet to spend funds
  that need one to satisfy a spending condition. It is only possible to
  provide it through external tools in one of the PSBT hash
  fields (e.g. PSBT_IN_SHA256). The author noted that this proposal only
  covers the preimages already known when a descriptor is created, not
  those learned at spend time, such as in a HTLC.

  Dias explained that the preimage should be treated more like a key
  than a signature, highlighting an inconsistency in the
  descriptor model. His idea aims to let a wallet import
  a secret from a descriptor and build and sign a transaction directly.
  To do so, the author proposed a specific syntax for the descriptor (e.g.
  sha256(preimage(HEX))) and a set of boundaries, such as the need for
  a specific marker instead of raw hex, a fixed size of 32 bytes for all the
  hash fragments, and the requirement to handle the preimage like any other secret,
  with backups, encryption, and never shown in the public descriptor string.

  Before proceeding to formalize the proposal, Dias highlighted some open
  points that need to be addressed, such as what the marker syntax should be , whether
  to amend BIP379 or draft a new BIP, if it is necessary to add an RPC call for
  Bitcoin Core to manage preimages, whether hardware signing devices should handle
  preimage secrets or this should remain software-wallet-only, and if there is any
  interest in deterministically deriving preimages from key material.

Changes to services and client software

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

• ● Ibis Wallet v5.0-beta released: Ibis Wallet v5.0-beta (see
  Newsletter #406) adds Ark support built on Bark,
  unilateral exits from the Spark statechain, and receiving
  to silent payment addresses.

• ● Landfall wallet for Lightning mining payouts: Landfall is a
  proof-of-concept wallet, showing UX achievable today, that derives from a single seed the payout address,
  BOLT12 offer, and BIP322
  signature that the OCEAN mining pool requires to pay rewards over LN, using a
  Lexe-hosted node (see Newsletter #419). It is not intended for
  production use.

• ● rbitcoin 0.8.0 released: rbitcoin 0.8.0 is a Bitcoin
  full node written in Rust and built on rust-bitcoin, described as entirely AI-written, for wallet and Lightning
  backends that replaces the UTXO set with a relational archive, serves Electrum
  and Esplora-style APIs, and uses BIP324 exclusively.

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.

• ● Eclair 0.14.4 and 0.14.5 are security releases for this
  LN node implementation. Version 0.14.4 fixes several issues related to
  splicing, HTLC settlement, on-the-fly
  funding, and onion parsing, as described in Newsletter
  #427. It also rejects API requests with an Origin
  header to prevent cross-site request forgery using cached HTTP Basic
  authentication credentials (see Newsletter #423).
  Browser-based integrations must now use their own backend to call Eclair.
  Version 0.14.5 fixes the trampoline routing and taproot splicing
  vulnerabilities described below, and closes an integer-overflow bypass of the
  onion payload length validation covered in Newsletter #427. The project strongly recommends upgrading.

• ● BDK chain 0.23.4 is a maintenance release of BDK’s libraries for building
  Bitcoin wallets. It fixes issues with transaction tracking and full scans
  that stop before checking all previously revealed addresses. Accompanying
  updates fix Bitcoin Core RPC synchronization after reorgs and include
  previously covered Electrum fixes for txid verification,
  confirmation detection for transactions with an OP_RETURN first
  output, and confirmation tracking after
  reorgs.

• ● LND v0.21.5-beta.rc1 and v0.20.6-beta.rc1 are
  release candidates for maintenance versions of this popular LN node
  implementation. Both include the fee-update handling and channel-message
  limits described in Newsletter #418, along with fixes for
  commitment feerates, excessive memory allocation when parsing TLV records,
  and SQL database deadlocks. Version 0.21.5 also includes the auxiliary
  HTLC signature validation fix for Taproot Assets channels described in Newsletter #427, and fixes wallet synchronization during blockchain reorganizations.

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.

• ● Eclair #3409 fixes a vulnerability that could allow a malicious payer to
  steal funds from a node forwarding trampoline payments. Eclair now limits the total CLTV expiry delta of a downstream route to ensure that the outgoing HTLC expires before
  the incoming HTLC (see Newsletter #423 for a related
  fix). Previously, when pathfinding failed, Eclair would retry with relaxed
  limits on route length and expiry, allowing a payer to provide routing hints
  or blinded paths with excessive expiry deltas. The payer
  could then reclaim the incoming HTLC onchain after it expired, while the
  receiver could still claim the outgoing HTLC. Eclair now only relaxes the
  route-length limit, preserving the required expiry ordering.

• ● Eclair #3411 fixes a vulnerability that could allow a malicious channel
  peer to steal funds by making Eclair sign an invalid splice
  transaction (see Newsletter #427 for related fixes).
  When splicing simple taproot channels, a
  peer can only provide the amount and script of an input’s previous output
  instead of the full transaction. Previously, Eclair trusted these values
  without verifying them. A peer could lie about either field, causing Eclair
  to sign a splice transaction that could never confirm because taproot
  signatures commit to the actual amounts and scripts of the spent inputs.
  Nevertheless, Eclair would treat the invalid splice as its latest channel
  funding state. The peer could then publish a previously signed commitment
  spending the previous funding output and claim an outgoing HTLC
  using its payment preimage after Eclair’s corresponding incoming HTLC had
  timed out and been refunded, leaving Eclair unable to collect the forwarded
  payment. Eclair now verifies the claimed outputs against its Bitcoin backend
  before signing.

• ● LDK #5126 fixes a bug where BOLT12 payments using one-hop
  blinded paths could be rejected because their HTLC expiry
  was too short. Previously, LDK ignored the path’s cltv_expiry_delta because
  the introduction node was also the receiver. This overlooked the fact that it
  includes the receiver’s required final CLTV delta.
  Consequently, payments only met the receiver’s minimum requirement when LDK’s
  random CLTV offset was large enough. This caused intermittent payment
  failures when testing against Core Lightning. LDK now includes the advertised
  delta when constructing the route and checking its maximum permitted total
  CLTV delta.

• ● LND #10919 adds an experimental local reputation system to mitigate
  channel jamming attacks, based on the
  proposed HTLC accountability scheme (see Newsletters #377
  and #387), which replaces the earlier HTLC
  endorsement approach. The system scores outgoing
  channels based on past forwarding activity and the node’s advertised fees,
  penalizing accountable HTLCs that take too long to resolve. The
  system is enabled by default and logs whether HTLCs would qualify for
  protected resources, without affecting forwarding decisions. Reputation
  resets on restart.

• ● BTCPay Server #7679 fixes a bug that could lead to duplicate Lightning
  payouts. Previously, if a payout was initiated and a subsequent payment
  lookup returned no results, BTCPay Server would cancel the payout and discard
  its saved payment hash. This occurred even if the payment had succeeded.
  Consequently, an operator could issue another payout for a payment that had
  already succeeded. BTCPay Server now retains payouts in progress and their
  payment hashes for subsequent checks.

• ● BTCPay Server #7684 fixes a privilege escalation in its Greenfield API
  key authorization. Previously, an API key restricted to a particular store
  could exercise server-wide or account-wide permissions despite its limited
  scope. Additionally, a key authorized to create API keys for other users
  could also grant permissions broader than its own. BTCPay Server now enforces
  permission scopes when authorizing requests and prevents API keys from
  granting permissions they do not possess. Existing unrestricted administrator
  keys retain their intended capabilities.

• ● BDK #2325 and #2360 fix two bugs that could cause the wallet
  to report successful synchronization without retrieving the requested
  transaction data. The first affects Electrum synchronization of individual
  outpoints. Previously, BDK ignored all errors encountered when fetching their
  transactions, including connection failures and timeouts. This could cause a
  spent output to remain classified as unspent. BDK now ignores Electrum
  protocol errors on this path while propagating other failures. The second PR
  fixes sync and full_scan in the Electrum and Esplora clients. Previously,
  setting Electrum’s batch_size or Esplora’s parallel_requests to zero
  could silently skip requested scans or transaction fetches while reporting
  success. Both clients now treat zero as one for these parameters.

• ● BOLTs #1357 updates BOLT11 to require invoice readers to reject
  invoices unless they contain exactly one payment hash (p) and one payment
  secret (s) field. Previously, the specification recommended that payers use
  the first p field, while some invoice parsers used the last. This
  discrepancy was exploited against LNP2PBot, whose invoice
  parser and Lightning node selected different payment hashes. Consequently,
  the bot treated completed payouts as unpaid, allowing attackers to obtain
  duplicate payouts (see Newsletter #425).

• ● BOLTs #1352 corrects several errors in the simple taproot
  channels specification and test vectors (see
  Newsletter #404). Errors in taproot output-key derivation
  and control-block construction could produce invalid spends if implemented as
  previously specified. The PR also clarifies that HTLC
  signatures exchanged in commitment_signed use
  SIGHASH_SINGLE|SIGHASH_ANYONECANPAY: the receiving peer appends 0x83 to
  the 64-byte signature when constructing the witness. When combining
  second-level transactions for fee bumping, each HTLC input and its
  corresponding output must occupy matching indices in the combined
  transaction. Additional corrections cover anchor spending paths, MuSig2 nonce encoding and derivation, and
  local and remote commitment test vectors. These changes align the
  specification with existing LND and Eclair implementations without changing
  protocol behavior.