Bitcoin Optech newsletter #425 is here:
- summarizes the responsible disclosure of two denial-of-service vulnerabilities affecting older versions of Eclair
- describes a proposal for synchronizing wallet labels between devices through an untrusted store
- recaps continued discussion of PQC output types
- describes an approach to block-wide signature aggregation via SNARKs
- summarizes bounds on chain length with BIP54 time warp fixes
- links to research comparing covenant proposals for vaults
- discusses the depots idea for probabilistic Lightning channels
- Optech Newsletter #425 Podcast
https://bitcoinops.org/en/newsletters/2026/10/02/
Matt Morehouse posted to Delving Bitcoin the responsible disclosure of two denial-of-service (DoS) vulnerabilities affecting Eclair v0.13.1 and earlier...
https://bitcoinops.org/en/newsletters/2026/10/02/#disclosure-of-two-dos-vulnerabilities-in-eclair
Jakub posted to the Bitcoin-Dev mailing list to gauge interest in standardizing synchronization of wallet labels between wallets through a shared, untrusted store before writing a specification...
https://bitcoinops.org/en/newsletters/2026/10/02/#proposal-for-wallet-label-synchronization
Discussion continued following last month’s summary of Pieter Wuille’s Delving Bitcoin thread on post-quantum output types...
https://bitcoinops.org/en/newsletters/2026/10/02/#continued-discussion-of-pqc-output-types
Conduition posted to Delving Bitcoin a design sketch for compressing many post-quantum signatures in a block into a single SNARK...
https://bitcoinops.org/en/newsletters/2026/10/02/#block-wide-signature-aggregation-via-snarks
Pieter Wuille posted to Delving Bitcoin a proof that the two timestamp rules in the consensus cleanup proposal (BIP54) suffice to bound how many blocks can be mined in a chain of given work...
https://bitcoinops.org/en/newsletters/2026/10/02/#bounds-on-chain-length-with-bip54-time-warp-fixes
Lillian Wang posted to Delving Bitcoin and cross-posted to the Bitcoin-Dev mailing list a report comparing simplified vault constructions...
https://bitcoinops.org/en/newsletters/2026/10/02/#comparing-covenant-proposals-for-vaults
John Law posted to Delving Bitcoin a protocol in which an operator funds a single time-limited taproot output (a depot) that can host Lightning channels for many thousands or millions of users...
https://bitcoinops.org/en/newsletters/2026/10/02/#depots-for-probabilistic-lightning-channels
Bitcoin Optech will host an audio recap discussion of this newsletter streaming live on X/Twitter Tuesday at 16:30 UTC.
Lillian's vault comparison is the one I'm watching. In Naija we do informal vaults (ajo) for shop savings — but you must trust the keeper. Covenant-based vaults on Bitcoin would let my suya merchant lock profit without third party. Which of the simplified constructions is closest to actually shipping in wallets?
Noted ✌️✌️
Both Eclair DoS bugs share the same asymmetry pattern: a tiny attacker message buys a huge amount of server-side work (~300MB allocated from one maximal init message; an uncapped zlib inflate letting a 64kB gossip query balloon to 64MB/~17M objects). Neither needed a funded channel, just a completed BOLT8 handshake, which is a good reminder that pre-channel parsing code deserves the same fuzzing rigor as post-channel logic. Also notable: the second bug was found by prompting an LLM to scan the codebase for other spots where a peer can impose disproportionate work, right after the first bug turned up via fuzzing. Seems worth other LN implementations running that same 'find more asymmetric-cost paths' pass on their own codebases instead of waiting for the next one-off disclosure. (comment drafted with AI research assistance, reviewed before posting)