From rusty at rustcorp.com.au Wed Nov 25 00:02:54 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Wed, 25 Nov 2015 10:32:54 +1030 Subject: [Lightning-dev] Return to the Layered Commit Transactions? In-Reply-To: References: Message-ID: <87fuzvx7wx.fsf@rustcorp.com.au> Mats Jerratsch writes: > 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... Right. This isn't immediately obvious, so let's unpack this a bit: Because any to-self output needs to have an additional relative revocation delay, A's HTLC output would look like: For A if HTLC times out + revocation relative timeout, OR For B with HTLC R value, OR For B with revocation hash. A needs to handle the case where B spends after the HTLC timeout, but before the revocation relative timeout, so its inter-hop HTLC timeout delta has to be > revocation timeout. (Aside: can we reduce the HTLC timeout there so that it takes into account the relative timeout? I'd have to think harder about all the other scripts, too, but it seems reasonable on the surface?). > (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... Yeah, don't do this. > (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. This was my plan. > 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... It's not about DoS, really. The revocation time has to be long enough so you're certain to spot someone cheating. And we've established that the HTLC inter-hop-delta should be >> revocation time. If your node is online and robust, 3 hours should be sufficient for revocation time (remember, you can jack up fees if you need to). 12 hours will give you plenty of time to take your claim transactions and inject them into the bitcoin network via carrier pidgeon or whatever you need to get around any DDoS. Still, let's assume everyone uses 1 day for revocation time, and 2 days for HTLC timeout delta, and we have 20 hops. The original HTLC (NODE 0 -> NODE 1) times out in 40 days. The last HTLC (NODE 19 -> NODE 20) times out in 2 days, and that one falls to the blockchain. NODE 19 takes 3 days to get a refund. Then it can immediately close the incoming HTLC from NODE18 (why wait for a timeout? It no longer has outstanding liabilities or any reason to believe it will get the R value), etc. So, worst case is 3 days unless there are multiple hop failures? > 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 ... Agreed. What do you think about reducing the OP_CHECKLOCKTIMEVERIFY argument if it's followed by the revocation delay? Thanks! Rusty.