Full article
Disclosure and repair happen on different timelines
Bitcoin Optech Newsletter #425, dated October 2, 2026, describes two denial-of-service issues affecting Eclair v0.13.1 and earlier. The fixes shipped in v0.14.0 in May. This chronology separates public disclosure from the availability of a repair. It also exposes a third date that matters operationally: when a particular node actually adopted the repaired software. An available update does not retroactively change a running installation. Reading the October publication as the discovery of a new, still-unfixed October incident would therefore distort the event.
Small inputs can create expensive work
The issues involve feature parsing and message decompression. Their shared theme is a mismatch between the effort required to send data and the work required to process it. As an analogy, imagine a short customer-service message automatically triggering an expensive database report. A small inbox could generate a large workload. That is a useful way to understand resource exhaustion without confusing it with control of a signing key. Service disruption and unauthorized spending are different outcomes. Evidence of one does not, by itself, establish that the other happened.
A repaired version and a restored service are separate checks
Our engineering interpretation is that correct transaction rules do not automatically imply safe resource consumption at every network boundary. Operational checks should also distinguish the installed version from the version currently running. In a hypothetical deployment, an operator downloads a new executable while the background process continues using the old one. The download record would not establish that the repair is active. Likewise, successfully restarting a process is not the same as confirming that its expected connections and work have resumed. This is an illustrative maintenance scenario, not an incident reported in the newsletter.
Labels preserve context that the ledger does not contain
The issue also covers a proposal for synchronizing wallet labels through an untrusted store using BIP329 records. A label describes how someone understands a payment; it is not proof of ownership. Imagine a phone marking a receipt as travel funds while a desktop still shows it as uncategorized. Both applications can agree perfectly about the coins while disagreeing about their purpose. That inconsistency can affect bookkeeping or selection decisions. Synchronization addresses this layer of shared context rather than changing which transactions the network considers valid.
Encryption does not resolve conflicting edits
Suppose two offline devices rename the same item differently. Reconnection requires a rule for deciding which version survives. Deletion needs representation too, or an old copy may appear to restore a removed label. Encryption concerns who can read data; conflict handling concerns which data remains. Neither substitutes for the other. The newsletter presents an evolving proposal, not a universal feature already implemented by all wallets. Our broader takeaway is that treating a storage service as untrusted does not remove the need to define the rights and responsibilities of the devices holding access material.