[Lightning-dev] Return to the Layered Commit Transactions?

[Rusty Russell]

Anthony Towns <aj at erisian.com.au> writes:
>  Definitions:
>   d -- the OP_CSV delay
>   T -- top OP_CLTV timeout
>   C -- the commitment tx is signed by B and given to A at time C
>   P -- the commitment tx is published at time P
>   S -- the commitment tx is spent at time S
>   X -- the timeout at which a refund can be forced
...
>    For n=4, F=4, t >= d+2 hours, so normal expiry is no later than
>    T-d-40m, and uncooperative expiry is at T+1h20, so d+2h later.

Is the 2 hours here due to timer tolerance?  If so, BIP 113 may allow us
to squeeze that a little in practice, depending on one's risk tolerance.

>> So, worst case is 3 days unless there are multiple hop failures?
>
> A single hop failure at node 3 immediately after the transaction gets
> passed on would be worse. Setup:

Indeed.

>> What do you think about reducing the OP_CHECKLOCKTIMEVERIFY argument if
>> it's followed by the revocation delay?
>
> The revocation delay happens simultaneously, so I don't think this can
> be made to work usefully.

Good point, it was a thinko.

> Don't think it's needed either though, so long as channels have parameters
> "t" and "k" as well as "d" to drop to the blockchain well before T
> actually comes around.

I'll be honest, I got lost somewhere in the alphabet reading your post.

However, you might be able to help me with a related question: I
proposed previously that if you didn't get fast resolution on an HTLC
you'd require proof that a commit tx was published, or you'd close the
channel yourself to create such a proof to hand back.

How would this work, timeout-wise?  We don't know how many hops are
ahead of us.  If the rule is "wait 1 minute, if you don't get a
response, close the channel" then everyone in the chain will close the
channel at once.  If the timeout is in the HTLC offer, then it makes the
message more traceable.

I can't see any obvious solution, can you?

Thanks,
Rusty.