Bitcoin Optech Newsletter #425

AI editorial brief — source checked

This week's Optech newsletter covers the responsible disclosure of two denial-of-service vulnerabilities in Eclair v0.13.1 and earlier, a proposal for synchronizing wallet labels via a shared untrusted store, and ongoing discussions on post-quantum cryptography output types, block-wide SNARK-based signature aggregation, BIP54 timestamp rules for chain length bounds, covenant comparisons for vaults, and probabilistic Lightning channel depots. It also includes release candidates for LND and notable changes across Bitcoin infrastructure software.

1. Two denial-of-service vulnerabilities affecting Eclair v0.13.1 and earlier were responsibly disclosed, with fixes in Eclair v0.14.0 released in May.
   Source evidence

   ● Disclosure of two DoS vulnerabilities in Eclair: Matt Morehouse posted to Delving Bitcoin the responsible disclosure of two denial-of-service (DoS) vulnerabilities affecting Eclair v0.13.1 and
2. The first Eclair vulnerability is in feature bit parsing, where a maximum-length init message could allocate and discard about 300 MB of memory and occupy a parsing thread for up to 300 ms.
   Source evidence

   The first vulnerability is in feature bit parsing. Eclair parsed the feature bits in an init message one at a time, allocating several objects per bit, so a single maximum-length init message
3. The second Eclair vulnerability is in gossip queries, where BOLT7 removed zlib encoding for query_short_channel_ids messages in April 2022, but Eclair continued to accept it, allowing a 64 kB message to inflate to 64 MB and about 17 million objects.
   Source evidence

   The second vulnerability is in gossip queries. BOLT7 removed the zlib encoding for query_short_channel_ids messages in April 2022, and Eclair stopped sending it the same month but continued to
4. Jakub proposed synchronizing wallet labels via a shared untrusted store, deriving storage location and encryption keys from a canonical descriptor form without private keys, so wallets sharing a descriptor find the same data.
   Source evidence

   Under the proposal, wallets derive a storage location and encryption keys from a canonical form of the descriptor, without any private keys, so wallets sharing a descriptor find the same data
5. Pieter Wuille proved that the two timestamp rules in BIP54 suffice to bound chain length, allowing at most 1,012,794 blocks for a chain at height 966,270, about 3,300 times tighter than with neither rule.
   Source evidence

   For a chain at height 966,270 the formula allows at most 1,012,794 blocks, about 3,300 times tighter than with neither rule. Omitting either rule leaves a limit above 3.34 billion blocks. The

What remains uncertain: The newsletter does not establish whether the wallet label synchronization proposal will be adopted as a standard, nor whether the SNARK-based post-quantum signature aggregation design will be implemented in practice.