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.
What readers must reject
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.
The implementation timeline also matters. The Lightning node software lnd merged duplicate-hash rejection on Sept. 23, before the specification change. Its available v0.20.5-beta and v0.21.4-beta releases include that payment-hash fix.
The broader payment-secret checks are addressed by a separate lnd proposal that remained open as of Oct. 27. It would tighten payment-secret and other decoder checks, including rejecting a second s field. The author also explains that some invoices accepted by the decoder already face checks later in payment processing, so decoding success alone does not establish that a payment will go through.
For payment operators, the documented failure points to two checks: reject ambiguous invoices and ensure withdrawal accounting follows the same payment hash as the node.
