Lightning tightens invoice rules after reported attack made Bitcoin withdrawals look unpaid

Lightning developers tightened BOLT11, the Lightning Network’s invoice standard, on Oct. 19 to require software to reject ambiguous payment-hash and payment-secret fields. The change follows a developer’s account of an attack that made completed Bitcoin withdrawals appear unpaid.

The merged change targets software components reading the same signed payment request differently. A payment hash identifies the payment a component is tracking. Bitcoin Optech highlighted the rule change on Oct. 23.

In a Sept. 10 statement on the proposal, developer Roasbeef reported a recent hack of a Telegram peer-to-peer bot that exploited libraries choosing different hashes: some took the first payment-hash field in an invoice, while others took the last. He gave no incident date or loss figure.

In practical terms, a service could track a withdrawal under one hash while its node executes a payment using another. The service could then mistake the completed withdrawal for an unpaid one, creating an opening for further payouts. The failure sits in the connection between payment execution and the service’s accounting.

The current BOLT11 specification requires exactly one payment-hash field, labeled p, and exactly one payment-secret field, labeled s. A missing field or a second occurrence requires payment failure. The rule covers both kinds of ambiguity, while the described withdrawal attack concerned conflicting payment hashes.

Readers must count field occurrences. The proposal’s invalid test cases include an invoice repeating the same hash, as well as one containing distinct hashes. Collapsing identical values into a single value would therefore miss an invoice the rule requires readers to reject.