[Lightning-dev] Return to the Layered Commit Transactions?
rusty at rustcorp.com.au
Fri Nov 27 03:42:55 UTC 2015
Anthony Towns <aj at erisian.com.au> writes:
> 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:
>> 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?
More information about the Lightning-dev