From matsjj at gmail.com Tue Nov 24 17:47:36 2015 From: matsjj at gmail.com (Mats Jerratsch) Date: Tue, 24 Nov 2015 17:47:36 +0000 Subject: [Lightning-dev] Return to the Layered Commit Transactions? Message-ID: While working on the payment layer and messing around with timeouts / timeframes for CSV and CLTV, I noticed a few things... (1) It is indeed not possible for HTLCs to have a long revocation time and a short refund time. And it makes sense the way we designed the scripts and the commit transaction. As it's a single output, we either can prevent the other side from doing ANYTHING for the revocation timeout T1, or the other party is able to claim the complete output without any encumbering... In long chains of multiple hops, I might need R to settle the payment normally, while you still wait out the revocation timeout before you can reveal R... I described that some time ago, but was unsure if I was right http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-September/000182.html (2) As revocation-time and refund time are equal, we have some problematic race conditions, where both parties can technically claim the payment, depending on propagation time of the transaction. Further, if you claim the payment that I was actually entitled to per refund, I may be out of luck getting my money back on the next hop... (3) As the absolute CLTV timeout has to increase with each hop, it can give us insight about our position within the route, even with onion routing. It is possible to have the sender add some delay, but this just increases the (already long) total refund time. I played with the numbers back and forth, but I don't really see any way out of this problem. Anything below one day might be dangerous already for DDoS attacks, with 20 hops we might end up with 30-40 days for a refund though... If we go back to the original design, we are able to separate 'claiming-a-payment-using-R' and 'revoke-an-output' into two layers and such, we can enforce revealing R within a separate timeframe than the revocation timeframe. To do this, we need either SIGHASH_NOINPUT or SW, as we can't construct the transaction on top of the 'reveal-R' transaction without knowing R currently. Short refund timeouts would also mitigate the problems of (3) I would really love to stick with the current design, as not having to keep another set of signatures makes everything easier ... Cheers Mats