Bitcoin Optech Newsletter #428
Bitcoin Optech’s latest newsletter examines a trust‑minimized exit design for single‑issuer layer‑2 systems and a proposal to extend descriptor syntax for hash preimages. It finds that the Lichen design could let users withdraw on‑chain without hub cooperation, while the descriptor update aims to treat preimages like keys.
Points clés
- Lichen introduces 2‑of‑2 contracts that let users redeem tokens even if the hub is unresponsive.
- Dispute resolution relies on on‑chain verification of Groth16 proofs via a fixed verifier program.
- The design still depends on a trustworthy sequencer; future work includes validity proofs and sequencer committees.
- A new descriptor syntax would allow wallets to import preimages directly, simplifying HTLC‑style spends.
- Open questions remain about BIP amendments, RPC support, and hardware‑wallet handling of preimages.
Trust‑minimized exits from a single‑issuer layer‑2
Bitcoin Optech highlights a paper by Adam Gibson that proposes Lichen, a layer‑2 system where a single issuer – the hub – mints tokens pegged 1:1 to on‑chain Bitcoin. Users lock Bitcoin in a 2‑of‑2 output with the hub and receive matching tokens on the off‑chain ledger run by a sequencer. The key question the report asks is whether users can exit to on‑chain Bitcoin without needing the hub’s cooperation. In the cooperative case, the hub simply signs a settlement. If the hub refuses, the user creates a Groth16 proof that the sequencer recorded the token return, then posts a claim that a fixed verifier program accepts the proof. A dispute is narrowed to a single on‑chain script step using presigned BitVMX transactions, and each side stakes a reserve that is forfeited on loss, deterring false claims.
The design builds on the earlier LN‑GAP concept but replaces the honest‑majority committee with an entirely on‑chain dispute. While this reduces trust in the hub, the sequencer remains a single point of failure; Gibson notes that a malicious sequencer could still cause loss, and suggests future work on validity proofs and a committee of sequencers to mitigate this risk.
Extending descriptor syntax for hash preimages
Another focus of the newsletter is João Dias’s proposal to extend BIP‑379 with a private form for hash fragments in miniscript descriptors. Currently, Bitcoin Core wallets cannot receive a preimage directly; they must rely on external PSBT fields. The proposal treats the preimage as a secret akin to a private key, introducing a syntax such as `sha256(preimage(HEX))` with a fixed 32‑byte size and a marker to keep the secret out of the public descriptor. This would let wallets import the secret, build, and sign transactions without external tooling. Open issues include whether to amend BIP‑379 or draft a new BIP, the need for an RPC call, hardware‑wallet support, and the possibility of deterministically deriving preimages.
Service and client updates
The newsletter also lists recent software releases: Ibis Wallet v5.0‑beta adds Ark support and unilateral exits from the Spark statechain; Landfall demonstrates a Lightning‑mining payout wallet; rbitcoin 0.8.0, an AI‑written Rust full node, now uses BIP‑324 exclusively. Security patches for Eclair, BDK, and LND are highlighted, urging users to upgrade.
Caveats and implications
Bitcoin Optech cautions that Lichen’s security still hinges on the sequencer’s honesty and that the dispute mechanism, while on‑chain, adds complexity and potential cost. The descriptor proposal is at an early stage; practical adoption will require consensus on BIP changes and hardware support. For developers and users, these advances suggest a move toward more trust‑minimized layer‑2 exits and richer wallet capabilities, but they also underscore the need for thorough testing and community review before deployment.