Matt Morehouse reveals Eclair memory bugs crash nodes
- Security researcher Matt Morehouse discovered memory vulnerabilities that crash Eclair Lightning nodes instantly.
- A tiny 64-kilobyte payload triggers massive heap allocation, exposing offline nodes to stolen funds.
- Developer Conduition proposed zero-knowledge SNARK proofs to prevent post-quantum signatures from bloating Bitcoin.
A tiny payload can bring down a Lightning node.
Security researcher Matt Morehouse disclosed two severe denial-of-service flaws in Eclair version 0.13.1, the implementation behind ACINQ's Phoenix wallet. Using custom fuzzer Smite alongside an AI model to detect allocation asymmetries, Morehouse found that a rogue 64-kilobyte payload decompressed into 64 megabytes and forced 450 megabytes of total heap allocations. A separate feature-vector bug forced nodes to iterate through bit vectors six times, creating processing lag that exhausted memory.
When nodes crash, money is on the line. Offline Lightning nodes cannot monitor the blockchain to prevent malicious channel closes. If a peer broadcasts a revoked commitment while a node is down, the victim risks losing locked HTLC funds. While watchtowers offer partial protection, timing windows still expose unhandled transactions to theft. ACINQ eliminated both vectors in Eclair version 0.14.0 by restricting vector checks and removing legacy Zlib compression support.
Memory exhaustion is not the only structural risk looming over node operators.
On Delving Bitcoin, developer Conduition outlined a proposal to prevent quantum-resistant cryptography from inflating the blockchain. Because post-quantum signatures require nearly ten times more data than standard Secp256k1 curve signatures, Conduition suggested replacing individual signature records with compact, block-wide zero-knowledge SNARK proofs. Nodes would store a single 500-kilobyte recursive proof alongside transaction data, capping block size near 1.5 megabytes.
Bitcoin node operator Brandon Black noted that verifying a single SNARK proof takes less time than validating individual elliptic curve signatures, accelerating node synchronization. However, generating those proofs shifts a heavy burden onto block producers. Assembling recursive proofs takes several seconds, potentially exposing miners to targeted denial-of-service attacks right when new blocks are mined.
To isolate consensus risks, Conduition proposed deploying the proof architecture as a temporary soft fork. If researchers identify flaws in the zero-knowledge proof mechanics later, the network could automatically fork the proof layer out without compromising Bitcoin's primary supply rules or history.
Node survival depends on balancing computation against memory limits.
Source Intelligence
- Deep dive into what was said in the episodes
Bitcoin Optech: Newsletter #425 Recap • Oct 8
- Matt Morehouse disclosed two denial-of-service vulnerabilities in Eclair version 0.13.1, both resolved in version 0.14.0. The first involved highly inefficient feature bit vector parsing, while the second exploited legacy Zlib decompression of short channel IDs to cause memory exhaustion.
Also discussed on this episode: (15)
Nostr (1)
- Jakub proposed standardizing wallet label synchronization using descriptor data for decryption and Noster for transport. Craig Raw opposed using Noster over privacy concerns, suggesting synchronization should be integrated into a broader inter-wallet communication standard that includes PSBTs and payment confirmations.
Protocol (8)
- Antoine Poinsot questioned whether combining post-quantum signatures with cross-input signature aggregation for Secp256k1 provides the right incentives. The proposal aims to offer fee savings on legacy signatures to drive voluntary user migration to quantum-resistant output types.
- Brandon Black explained that Pay to Merkle Root achieves quantum resistance by removing Taproot's internal key to leave only a script tree. Conversely, Pay to Taproot v2 retains the internal key but permits disabling the key-spend path if Secp256k1 is compromised.
- Conduition proposed using block-wide SNARK proofs to validate all post-quantum signatures collectively, reducing on-chain storage requirements. While this maintains historical block sizes, Brandon Black noted it increases miner workload, potentially delaying block template generation by several seconds.
- Peter Wuille proved that the BIP54 consensus cleanup proposal successfully limits block production rates to within one percent of the target ten-minute interval. This mathematical proof demonstrates that BIP54 prevents miners from manipulating timestamps to construct rapid, low-difficulty alternative header chains.
- Lillian Wang analyzed different covenant proposals for implementing reactive security vaults. Her research indicates that simple, infrequently accessed vaults are highly suited for OP_CHECKTEMPLATEVERIFY, whereas vaults requiring everyday transaction features like change outputs should utilize Check Contract Verify.
- Bitcoin Core PR 29278 separated absolute fee limits from fee rate limits by introducing a default max fee rate of 10,000 satoshis per virtual byte. Additionally, PR 35984 fixed a SighashSingle legacy signing bug where missing outputs allowed signature reuse across different UTXOs.
- Bitcoin Core PR 35301 integrated foundational support for BIP352 silent payments. The implementation enables encoding and decoding of silent payment addresses, Taproot output derivation from transaction inputs, and transaction scanning for recipient labels.
- Bitcoin Core PR 35813 added a listrawtransactions RPC to return exactly one entry per transaction, bypassing the double-accounting format of listtransactions. Concurrently, BIP-376 was updated to stop deleting PSBT witness UTXOs during finalization, which previously broke other Taproot signatures.
Lightning (4)
- John Law proposed DPOTS, a protocol utilizing covenants to support millions of Lightning channels from a single on-chain output. To secure micro-balances, DPOTS introduces a probabilistic mechanism where an operator violation awards the entire output to one randomly selected user.
- LND released maintenance versions 0.21.4 and 0.20.5. Version 0.21.4 mandates that users explicitly define channel types during setup and introduces a WalletKit feature to reserve outputs until a transaction reaches a specified confirmation depth.
- LND PR 11190 was merged to reject Bolt 11 invoices with duplicate payment hashes, resolving an exploit that caused the shutdown of LNP2PBot. The vulnerability arose because LND and other parsers processed duplicate payment hashes differently, creating accounting discrepancies.
- LND PR 11212 removed legacy commitment formats for new channels, mandating static remote keys to simplify seed-based fund recovery. Additionally, LND PR 11173 fixed a gossip synchronization stall from oversized channel messages, and LDK PR 4993 corrected an issue where aborted fee bumps on closed channels released unconfirmed splice reservations.
Privacy (1)
- Bitcoin Core PR 36312 resolved an IP correlation bug in private transaction broadcasting, while PR 36284 corrected a coin selection error where ineligible unconfirmed UTXOs caused the wallet to subtract balances twice and reject valid transactions.
Custody (1)
- Bitcoin Core PR 35752 resolved eight silent error handling bugs occurring during wallet encryption, passphrase updates, and key insertions. These bugs could report successful changes despite database write failures, leaving private keys vulnerable or locking users out of funds.