Lightning: why do we need decrementing timelocks in multi-hop payments?

Question

The video (at 28:25) from the official Lightning website describes a multi-hop payment. I understand what a hash-locked contract is, but I still don't understand why we need a timelock aspect here. As you see on the slide, in a multi-hop payment A -> B -> C -> D, (A -> B) has a 3-day nLockTime, (B -> C) has a 2-day nLockTime, and (C -> D) has a 1-day nLockTime. nLockTime of time t means that the transaction can not be included in a block earlier than t. So as time passes, first the (C -> D) becomes valid, then (B -> C) becomes valid, then (A -> B) becomes valid.

Joseph Poon says at 28:35 (emphasis mine):

"Dave's and Carol's channel [...] closes first. And Carol is happy with this setup, because she knows that her payment closes out [...] before her money gets pulled."

Isnt's it the other way around: Dave pulls money from Carol first (between day 1 and day 2), and then Carol pulls money from Bob?

Anyway, what would go wrong if we got rid of timelocks altogether? Say, Dave generates a random R, sends H(R) to Alice, Alice creates a hash-locked transaction and broadcasts it to Dave via Bob and Carol. If Dave discoses R, everyone can withdraw their funds, if he doesn't, no one can. Why do we need timelocks on top of that?

Answer 1

I use the following scenario for both questions: Alice wants to pay 1 BTC to Dave via the route: Alice -> Bob -> Carol -> Dave

Why do we need timelocks?

Lets assume that the payment route has just been established. Meaning: Each hop in the route (A, B, C, D) has an HTLC with its neighbor hop(s). However, the HTLCs would not have any timelocks. Now Dave sends the secret R to Carol who in turn sends R to Bob. However, Bob doesn't respond (e.g. because his node crashed). Unfortunately Alice has no clue why Bob doesn't send R to her. So she has to wait until Bob becomes responisve again. Now that could take an hour, a few days, a few weeks or maybe he will never respond again. The problem for Alice is that the HTLC between her and Bob is valid indefinitely. So without a timelock the money committed to this HTLC may be stuck for a very long item and Alice cannot do anything about it.

What's the benefit of decrementing timelocks?

Decrementing timelocks are useful for intermediate hops (all hops other than the first and last one). In our example the route is:

 A -> B -> C -> D 

So B and C are the intermediate hops. Now according to the HTLCs, an intermediate hop can claim money from the previous hop and has to pay money to the next hop. For example: Carol can claim money from Bob and has to pay money to Dave.

Generally speaking that means: A hop „HOP“ has to make sure that after the next hop „NEXT“ claimed the money from HOP, HOP will be able to claim the money from the previous hop „PREV“ before the HTLC between PREV and HOP is invalidated (timed out). And an easy way to do this is by ensuring that the HTLC-timelock between HOP and NEXT is (significantly) lower than the one between HOP and PREV.

Here's an example of what could happen if all HTLCs would have the same timelock. For this example we assume that the timelock is „T+10 blocks“ (T = a fixed block number). So when the blockheight is at T+10 blocks or later all HTLCs „timed out“ and:

• Bob can reclaim his committed money from the HTLC with Carol
• Carol can reclaim her committed money from the HTLC with Dave

Now after the payment route has been established the following happens:

After a delay (at T+8 blocks) Dave sends the secret R to Carol. By doing this he proved Carol that he can (legitimately) claim the money from their HTLC. As both parties don't want to close their channel yet, they update the channel state accordingly instead. By doing this, Carol has just irrevocably paid money to Dave.

However, Carol hasn't received any money from Bob yet. So she sends R to Bob. But Bob doesn't respond! This is unfortunate for Alice as in 2 blocks (~ 20 minutes) Bob can reclaim his money! To prevent this, Carol has to immediately close the channel with Bob by broadcasting the Committment Transaction that contains the HTLC. At the same time she also has to send another „delivery transaction“ that (intends to) actually transfer the money from the HTLC (between her and Bob) to herself. However, unfortunately there is no guarantee that both transactions are actually included in the next block (T+9). But if only the HTLC is included in block T+9, Bob can broadcast his own „delivery transaction“ that (intends to) transfer money from the now confirmed HTLC (via the output's „timeout path“) to himself. So now there are two „delivery transactions“ in the mempool that use the same HTLC-output. As we know, double-spending is not allowed. So only one of these transactions will be included in a subsequent block. And if Bob's transaction will be included, Alice will lose her money.

Having said all that, I think technically it would also be possible to do trustless multi-hop payments without decrementing timelocks. But this concept is probably much easier to implement and maintain..