Lightning Network tightens invoice rules after exploit exposed

How the parser conflict enabled duplicate payments

BOLT11 protocol now enforces strict validation rules for payment hashes and secrets. The change follows a reported attack where conflicting parsers made completed Bitcoin withdrawals appear unpaid. This allowed attackers to trigger duplicate payouts on the Lightning Network.

The vulnerability stemmed from how different software implementations interpreted invoice data. A developer explained that if one parser accepted an invoice while another rejected it, the system could think a payment was never settled. Attackers exploited this gap to request the same withdrawal twice.

What changed in the new BOLT11 specification

The core issue was a mismatch between invoice validation logic across different Lightning implementations. When a payment hash appeared twice or was missing entirely, some nodes accepted the invoice while others did not. This inconsistency created a window where a completed transaction could be re-requested as if it had never happened. The fix standardizes what constitutes a valid invoice, eliminating the ambiguity.

The updated spec now requires exactly one payment hash and one payment secret per invoice. Invoices with missing fields or repeated hashes are rejected outright. Released versions of lnd now include this duplicate-hash rejection logic. A proposal is also circulating to further harden validation across the ecosystem.

What was the specific attack? A conflicting invoice parser bug made completed Bitcoin withdrawals look unpaid, allowing attackers to request the same payout twice.

Frequently Asked Questions

Which software versions are affected? Older lnd releases that lacked duplicate-hash rejection are vulnerable. Updated versions enforce the new BOLT11 validation rules.

Does this affect all Lightning implementations? The fix targets BOLT11 invoice parsing, which is used across most major Lightning nodes. Operators should verify their software supports the updated spec.