Lightning Network Tightens BOLT11 Invoice Rules After Reported Bitcoin Withdrawal Attack
Lightning Network developers have tightened the BOLT11 invoice standard to prevent payment requests containing duplicate or ambiguous fields from being processed differently by separate software components. The change, merged on October 19, follows a developer's report of an attack involving a Telegram peer-to-peer bot that made completed Bitcoin withdrawals appear unpaid.
The update requires invoice-reading software to reject payment requests that do not contain exactly one payment hash and exactly one payment secret. The revised rule aims to reduce inconsistencies between how payment software interprets an invoice and how a Lightning node executes the transaction. Bitcoin Optech highlighted the change on October 23.
How the Lightning Network Invoice Attack Worked
In a September 10 statement about the proposal, Lightning developer Roasbeef described a reported hack involving a Telegram peer-to-peer bot. According to his account, different software libraries interpreted invoices containing multiple payment-hash fields differently: some selected the first hash, while others selected the last.
A payment hash identifies the payment being tracked. When different components use different hashes for the same invoice, a service may record a withdrawal against one hash while its Lightning node processes the payment using another. The service could consequently treat a completed withdrawal as unpaid, potentially allowing additional payouts.
Roasbeef did not disclose when the incident occurred or provide a loss estimate. The reported vulnerability concerned the coordination between payment execution and withdrawal accounting rather than a failure of Bitcoin's underlying transaction system.
BOLT11 Requires Exactly One Payment Hash and Secret
The BOLT11 specification requires each invoice to contain exactly one payment-hash field, identified by the letter p, and exactly one payment-secret field, identified by s. An invoice missing either required field or containing a duplicate occurrence must be rejected as a failed payment request.
The rule addresses ambiguity in both fields, although the reported withdrawal attack specifically involved conflicting payment hashes. Test cases for the proposal include invoices that repeat the same hash and invoices containing different hashes.
This distinction matters because software cannot safely treat identical duplicate values as a single valid field. The specification requires rejection based on the number of field occurrences, even when repeated values are identical.
Lightning Software Fixes and Remaining Work
The implementation timeline began before the specification change was merged. The Lightning Network Daemon, known as lnd, incorporated rejection of duplicate payment hashes on September 23. Its v0.20.5-beta and v0.21.4-beta releases include that fix.
Additional validation remains a separate development task. As of October 27, a proposal to strengthen lnd's payment-secret validation and other decoder checks was still open. The proposed changes include rejecting invoices containing a second payment-secret field.
The proposal also notes that some invoices accepted during decoding may still be rejected by checks performed later in payment processing. As a result, successful invoice decoding does not guarantee that a payment will be completed.
For services handling Lightning withdrawals, the reported incident highlights two operational safeguards: reject invoices with ambiguous or duplicated fields, and ensure internal withdrawal records use the same payment hash as the Lightning node processing the paymet
source: cryptoslate
Writer: Ethan Collins
Crypto Journalist
Ethan Collins reports on developments across the cryptocurrency and blockchain sector. His work covers market movements, protocol updates, regulatory changes, and emerging trends in digital assets.
He focuses on presenting complex topics in a clear and accessible manner for a broad readership.
Check out other news and articles on Google News
Disclaimer:
The articles on Hokanews are here to keep you updated on the latest buzz in crypto, tech, and beyond—but they’re not financial advice. We’re sharing info, trends, and insights, not telling you to buy, sell, or invest. Always do your own homework before making any money moves.
Hokanews isn’t responsible for any losses, gains, or chaos that might happen if you act on what you read here. Investment decisions should come from your own research—and, ideally, guidance from a qualified financial advisor. Remember: crypto and tech move fast, info changes in a blink, and while we aim for accuracy, we can’t promise it’s 100% complete or up-to-date.