Author: Bastien TEINTURIER 2021-12-15 08:01:37
Published on: 2021-12-15T08:01:37+00:00
A Lightning developer has proposed a protocol to mitigate the issue of HTLC (Hash Time Locked Contract) spam via onions. The key idea is to set a fixed time in seconds after successfully negotiating an HTLC until when a node requires a resolution or reply from its peer to which it previously has forwarded a downstream onion. If the HTLC is not resolved and no reply was sent, the downstream peer is considered to be acting maliciously. A new message called `blame_channel` is sent if a node is not able to send an `update_fulfill_htlc` or `update_fail_htlc`. The `blame_channel` includes a proof that the node has previously successfully set up the HTLC with the next peer. There are two limitations to this proposal: It does not directly prevent spam via HTLCs, and with Multi-Path Payments, the short reply interval might be an issue as the honest recipient of a partial payment might just not have received enough parts of the entire payment and cannot fulfill the payment yet. However, the proposal ensures that blame can be ascribed quickly by requiring a reply from the downstream onion that is proportional to the `cltv delta` at the hop. In this way, a sending node will quickly know that a downstream channel is not working properly. The proposal also picks up the early idea by Rusty, AJ, and others to ascribe blame to a malicious actor but hopefully in a cheaper way than providing proof of a channel close by making use of a new lightning message `blame_channel` in combination with the proposed onion messages.However, there is another limitation that is not mentioned in the proposal. It is easy for a malicious node to blame an honest node, which is a serious limitation of the proposal. If a payment goes through A -> B -> C -> D and C is malicious, C can forward the payment to D and even wait for D to correctly settle it but then withhold that message instead of forwarding it to B. Then C blames D, everyone agrees that D is a bad node that must be avoided. Later, C unblocks the `update_*_htlc`, and everyone thinks that D held the HTLC for a long time, which is bad.Apart from this, the blame proof isn't that easy to build. It cannot simply use `commitment_signed` because HTLCs are relayed only once the previous commitment has been revoked (through `revoke_and_ack`). So the proof should contain data from `commitment_signed` and a proof that the previous commitment was revoked (and that it was indeed the previous commitment), which is likely very hard to do securely without disclosing too much about your channel. Finally, the proposal also includes extensions and limitations that could help overcome some of the challenges mentioned above.The proposal suggests a mechanism to ascribe blame which would allow several nodes on the network to learn about malicious or slow actors and take other preventive measures, especially if they have direct channels with that peer. It also proposes that once stuckless payments are available, an honest sender of the payment may quickly discard this stuck HTLC (PTLC) and try another path without including the malicious node. The author acknowledges that the suggestions in this proposal may not be as secure as needed, but believes it is a step towards mitigating nodes abusing the possibilities of onion routing and HTLCs spam. The proposal ends with a request for review and criticism.
Updated on: 2023-06-03T06:53:02.993554+00:00