Bitcoin developers are discussing a new Lightning Network bug that can cause unattributed payment routing failures. This bug can cause Lightning Network payments to fail without the parties involved knowing why.
As opposed to base layer Bitcoin where thousands of node operators validate transactions, Lightning payments can involve as few as two people. Users purposefully sacrifice the security of Bitcoin’s blockchain in exchange for faster speeds and cheaper fees.
Within the Lightning Network, payments can fail if anything goes wrong with any step in various multi-signature processes. For example, the end receiver might refuse to release a preimage confirming that they received the payment, or a Lightning Network node might go offline.
An unattributed payment routing failure means that the spenders wouldn’t even know what went wrong. Either an error message got corrupted on the way back to the sender, or they never received a message. They might keep trying to use a faulty node without even realizing that there’s a problem.
If the spenders do get a notification about what went wrong, they can try again after making a few adjustments, like switching to a different Lightning Network node.
Possible solutions for the unattributed payment routing failure
Developer Joost Jager anticipated this issue and proposed a solution in 2019. He noticed that a payment channel could take a long time to confirm that the transaction went through. He recommended adding two timestamps to the messages that nodes send back to the transaction’s sender. One timestamp would represent the time the node received the transaction and the other timestamp when the node relayed the transaction to its next stop. Both timestamps would give senders an idea of which channels are slow to relay transactions and avoid those channels in the future.
On October 19, 2022, Jager posted an updated version of his unattributed payment routing fix that would improve failure messages so that they wouldn’t look like gibberish to a sender. The improved messages will allow senders to identify the exact node that caused their transaction to fail so that they could exclude it from future transactions.
Rusty Russell suggested an alternative: Each routing node would be paid one sat even when a transaction fails. Senders could tell which routing node failed by comparing the number of satoshis sent with the number of satoshis they received back. This satoshi-counting technique would work even if an error message became corrupted. (Note: One satoshi equals one hundred millionth of a bitcoin.)
LND implementations of Lightning Network plagued with errors
On November 1, 2022, Lightning Labs released an emergency update to fix a bug that caused LND nodes to fail to parse transactions that needed many witness inputs. Nodes that don’t update may fail to prevent malicious channel closings once timelocks expire.
A developer known as “Burak” triggered the bug with a transaction containing the message, “you’ll run CLN [Core Lightning] and you’ll be happy.”
Burak triggered a similar bug on October 9, 2022, when the anonymous developer sent a 998-of-999 tapscript multisig transaction. This transaction type would have required 998 private key signatures to authenticate, making it difficult to push it through successfully. He bragged about doing it for a $4.90 fee.
Twitter user Stadicus called the attacks a “savage takedown” and suggested launching a bug bounty program.
A hacker named Anthony Towns claimed he tried to warn Lightning Network developers about the bug, but says the btcd repo seems to lack a mechanism for reporting security bugs.
Two Lightning Network developers proposed possible solutions for the unattributed payment routing failure issue. By improving messages, Joost Jager’s proposal would make it easier to pinpoint where the problem occurred. Russell’s proposal would cost senders a few more satoshis, yet make it possible to track down the issue even if a message fails to return to the sender. Meanwhile, developers are fixing bugs that might cause LND nodes to fail in the first place.