Bitcoin Optech Newsletter #425
Eclair’s DoS bugs are fixed in v0.14.0; a new proposal aims to sync wallet labels via an untrusted store; the community debates post‑quantum outputs, SNARK‑based signature aggregation, and BIP54 time‑warp bounds, while covenant vaults and probabilistic Lightning depots offer fresh spending models.

Bitcoin Optech Newsletter #425 – Oct 2 2026
The latest edition of the Bitcoin Optech Newsletter dives into a mix of security findings, protocol proposals, and consensus‑rule discussions that shape the Bitcoin ecosystem. Two denial‑of‑service (DoS) bugs were responsibly disclosed in older releases of the Eclair Lightning node, prompting a quick upgrade to v0.14.0. A fresh proposal for synchronizing wallet labels via an untrusted store is sparking debate about privacy‑first inter‑wallet communication. Meanwhile, the community continues to wrestle with post‑quantum output types, block‑wide signature aggregation, and the mechanics of time‑warp fixes in BIP54. Below is a concise rundown of the most impactful items.
1. Eclair DoS Vulnerabilities – Upgrade Now
Matt Morehouse’s Delving Bitcoin post exposed two DoS vectors that affect Eclair v0.13.1 and earlier:
- Feature‑bit parsing – Eclair parsed each init‑message bit separately, allocating a new object per bit. A maximum‑length init message could allocate ~300 MB of memory and block a parsing thread for 300 ms. With a handful of connections, an attacker could disconnect all peers in under a minute and exhaust memory in five minutes.
- Gossip‑query decompression – After BOLT 7 removed zlib encoding for `queryshortchannel_ids`, Eclair continued to accept uncompressed messages. A 64 kB payload could inflate to 64 MB and 17 million objects, bringing a node offline within seconds.
Both bugs were fixed in Eclair v0.14.0 (released May 2026). If you’re still running an older version, upgrade immediately to avoid a DoS attack.
2. Wallet Label Synchronization – A New Proposal
Jakub’s recent Bitcoin‑Dev mailing‑list thread proposes standardizing the exchange of wallet labels through a shared, untrusted store. The idea builds on BIP 329’s label‑export format but removes the manual import/export step:
- Wallets derive a storage location and encryption keys from a canonical descriptor (no private keys involved). Any wallet that shares the descriptor automatically finds the same encrypted label set.
- Records are authenticated with an encryption envelope and timestamped, so the most recent change wins.
- Deletions are recorded as markers, allowing a label to be removed across all wallets.
Jakub suggests using Nostr as the reference transport, but Craig Raw argues that privacy‑first protocols should be preferred over censorship‑resistance. The discussion also touches on broader inter‑wallet communication, including PSBTs, multisig setups, and payment confirmations.
3. Post‑Quantum Output Types – The Ongoing Debate
Pieter Wuille’s thread on post‑quantum output types continues to generate lively discussion. Antoine Riad supports a P2TRv2 output that keeps a quantum‑vulnerable spend path until the user opts out, while Conduition stresses the need for new standards to derive PQ keys. Wuille counters that neither P2TRv2 nor the proposed P2MR type can guarantee quantum security without user‑initiated key changes. The consensus is that shipping multiple output types may create distinguishable footprints, but it also offers users choice.
4. Block‑Wide Signature Aggregation via SNARKs
Conduition’s design sketch proposes compressing many post‑quantum signatures into a single SNARK proof per block. The approach uses a bespoke aggregation circuit (SPHINCS‑WOTS+C) rather than a general‑purpose VM, aiming to keep verification cost constant per signature. While the smallest hash‑based SNARK proofs are ~300–500 kB, the design avoids allowing miners to mine while a proof is being generated, mitigating potential DoS vectors. Jonas Nick and ZmnSCPxj raised concerns about recursive proof soundness and prover code reliability, suggesting that the prover be shipped with Bitcoin Core for review.
5. BIP54 Time‑Warp Bounds – A Lean‑Proof Milestone
Pieter Wuille’s machine‑checked Lean proof demonstrates that the two timestamp rules in BIP54 (classic time‑warp and Murch–Zawy) bound the maximum number of blocks that can be mined in a chain of a given work. The bound tightens the long‑term block rate to roughly one block per 9 min 56 s, with a small, bounded number of extra blocks. This result is crucial for Bitcoin Core’s headers‑presync DoS protection, which can rely on the bound once BIP54 is buried.
6. Covenant‑Based Vaults – A Comparative Study
Lillian Wang’s report compares simplified vault constructions using CTV, CCV, TXHASH, APOAS, and an OP_CAT‑based Purrfect Vault. Key takeaways:
- CTV works well for pre‑computed outputs.
- CCV excels at partial withdrawals and choosing a withdrawal address at trigger time.
- TXHASH offers more commitment flexibility but places more responsibility on the designer.
- APOAS and CAT may be attractive for broader non‑vault applications.
The study highlights that APOAS signatures can be combined across multiple deposits to the same vault address, enabling a single‑output “half‑spend” scenario.
7. Probabilistic Lightning Channels – The Depot Idea
John Law’s protocol introduces depots: a single time‑limited taproot output that hosts Lightning channels for many users. Users buy channels via Lightning payments, and each channel is assigned a secret guess between 0 and a large prime. After the depot expires, the operator reveals a target; a channel is a “hit” if its guess matches. This probabilistic model limits the number of on‑chain claims while offering a chance at a large payout.
---
Practical Takeaways
- Upgrade Eclair to v0.14.0 or later to patch critical DoS bugs.
- Consider the label‑sync proposal if you run multiple wallets that share descriptors; it could streamline coin‑selection workflows.
- Stay informed about post‑quantum output types and BIP54 bounds, as they influence future protocol upgrades.
- Watch the SNARK aggregation proposal for potential changes to block‑size and miner incentives.
- Explore covenant vaults if you need advanced conditional spending; the comparative study can guide your choice.
---
TL;DR: Eclair’s DoS bugs are fixed in v0.14.0; a new proposal aims to sync wallet labels via an untrusted store; the community debates post‑quantum outputs, SNARK‑based signature aggregation, and BIP54 time‑warp bounds, while covenant vaults and probabilistic Lightning depots offer fresh spending models.
Source
Read original sourceWhy we picked this
Comprehensive coverage of Bitcoin security vulnerabilities, consensus proposals, and software releases.