CryptoSlate
The BOLT11 invoice standard now requires exactly one payment hash and one payment secret, with missing or repeated fields requiring payment failure. Lightning developers made the change on Oct. 19 after a reported attack showed how conflicting invoice parsers could make completed Bitcoin withdrawals appear unpaid. The incident account did not include a date or loss figure.
Why it matters
The vulnerability was rooted in software components reading the same signed payment request differently. One parser could select the first payment-hash field while another selected the last. A service might therefore record a withdrawal under one hash while its node executed the payment under another, leaving the accounting system to treat a completed withdrawal as unpaid and potentially issue another payout.
The new rule covers both payment hashes and payment secrets. Implementations must count field occurrences, including repeated identical values, rather than collapsing them into one entry. An invoice with two distinct hashes and an invoice repeating the same hash are both invalid under the updated specification.
Market impact
The immediate impact is operational rather than a direct Bitcoin price signal. Payment operators need to reject ambiguous invoices and ensure withdrawal accounting follows the same payment hash used by the node. The change also highlights a broader risk in crypto infrastructure: signed data can still produce failures when different software interprets its fields inconsistently.
The lnd node software merged duplicate-hash rejection on Sept. 23. Its v0.20.5-beta and v0.21.4-beta releases include that fix. A separate proposal covering payment-secret validation and other decoder checks remained open as of Oct. 27, and successful decoding alone does not guarantee that a payment will complete.
Frequently asked questions
-
What changed in the BOLT11 invoice standard?
BOLT11 now requires exactly one payment hash and one payment secret. Missing or repeated fields must cause the invoice to be rejected.
-
How could conflicting parsers make a Bitcoin withdrawal look unpaid?
One parser could use the first payment hash while another used the last. A service could then track a different hash from the one used by its node to execute the payment.
-
What type of attack prompted the BOLT11 rule change?
A reported attack on a Telegram peer-to-peer bot exploited differences between invoice libraries, making completed Bitcoin withdrawals appear unpaid and creating an opening for further payouts.
-
Which lnd releases include duplicate-hash rejection?
The duplicate-hash fix was merged on Sept. 23 and is included in lnd v0.20.5-beta and v0.21.4-beta.
-
Are payment-secret checks already complete in lnd?
No. A separate lnd proposal covering payment-secret validation and other decoder checks remained open as of Oct. 27.
CoinDesk
CZ Binance
TheBlock
CoinTelegraph
WuBlockchain