Lightning tightens BOLT11 rules, requires single payment hash and secret

In response, Lightning developers tightened the BOLT11 standard, the protocol governing Lightning Network invoices, on October 19. This update mandates that software must reject invoices containing ambiguous payment-hash and payment-secret fields.

The core issue stemmed from software components interpreting the same signed payment request differently. A payment hash serves to identify the specific payment a component is tracking.

Developer Roasbeef detailed the hack in a September 10 statement, noting the bot exploited libraries that handled hashes inconsistently—some using the first payment-hash field, others the last. He provided no details on the incident's date or financial losses.

Practically, a service might track a withdrawal using one hash while its node processes the payment using a different one. This discrepancy could cause the service to mistakenly flag a finished withdrawal as outstanding, opening a door for subsequent payouts.

The current BOLT11 specification demands precisely one payment-hash field, labeled 'p,' and one payment-secret field, labeled 's.' Any missing field or a second instance of either requires the payment to fail.

For operators, this change necessitates two critical checks: rejecting invoices exhibiting ambiguity and verifying that withdrawal accounting aligns precisely with the payment hash recorded by the node.

While the specification change addresses hash conflicts, the broader checks for payment-secret are covered by a separate lnd proposal, which remained open as of October 27. The Lightning node software lnd had already implemented duplicate-hash rejection on September 23, available in v0.20.5-beta and v0.21.4-beta releases.

Why it matters

This rule change directly addresses a vulnerability in the Lightning Network that could lead to incorrect accounting and potential payouts. Readers should watch how quickly node software fully implements these new, stricter invoice validation rules.