Author: CJP 2016-02-08 22:07:53
Published on: 2016-02-08T22:07:53+00:00
In an old email thread, a potential problem with Lightning Network was identified where Eve could steal funds from Alice. If Eve has two channels with Alice, she could perform a payment to herself routed through Alice with the two channels and not reveal the transaction R value as a payee. This would lead to a timeout on both channels and reverting back to the original situation. Eve spends all her coins on the channel where she was RECEIVING. She then signs and broadcasts the version of the commit transaction that contained the HTLC. However, since revocation pre-images have been exchanged, Alice can immediately spend the HTLC, using either the HTLC-TIMEOUT & SIG-PAYER clause or the REVOCATION-E & SIG A clause, but this is not guaranteed to work. If Eve succeeds in spending the HTLC, Alice can only claim her balance and using the revocation pre-image, claim Eve's balance in the commit transaction. On the other channel, Alice could try to perform the same trick on Eve as Eve did on her, since Alice now has the transaction R value. However, that is not guaranteed to work. Worse: Eve could also have depleted her own balance on that channel, e.g. with a payment to herself through a third party. That way, Alice will never be able to get all the funds that belong to her, and Eve gets more than she deserves.The author suggests adding an OP_CSV to the R-VALUE & SIG-PAYEE clause but acknowledges it would break its legitimate use. The author believes the issue cannot be solved without having a two-transaction set-up, and hence something like SIGHASH_NOINPUT (or maybe SegWitness?). Maybe a "never completely deplete the channel" rule could be a work-around? You could define a maximum for the sum of all active HTLCs in one direction in a commit transaction, and require the other side to always have at least one or two times that maximum as remaining balance. The author requests where can he find an updated design if this issue has already been resolved.
Updated on: 2023-05-23T18:20:57.746416+00:00