[Lightning-dev] Timeframes for refunds and revocation
matsjj at gmail.com
Thu Sep 3 11:18:39 UTC 2015
I just messed around, thinking about reasonable timeframes for
payments and revocation. I ended up thinking that 7 days would be
okayish as the revocation timeframe for most usecases, as we also have
to think about the everyday users that are not online (or don't even
have access to their computer) for a couple of days..
I further think 1 day is plenty of time to reveal R. We really don't
want to give the receiver too much time to accept and clear the
payment. (It locks up funds for everyone else in the route..)
Considering these values with the HTLC Receiver Redeemscript
<7 DAYS> OP_CSV
<8 DAYS> OP_CLTV OP_DROP
So if A has REVOKE-PREIMAGE he can claim the payment anytime.
If B has R he has to wait 7 days until he can claim the output (and
reveal R doing so..)
Furthermore, if he has R and wants to clear the payment, he has to act
within one day. He has to either settle the payment with the other
party or broadcast the channel within this time.
If he broadcasts the channel within one day, B can claim the output,
but A has to wait for full 7 days until he learns R. However, A might
not be the original sender, but just one of the nodes on the route,
and if A does not provide R to the node before him within 2 days (we
have 1 day per hop), he cannot pull the funds, although B can pull
his. This means all nodes along the route has to broadcast their
channel in order to not lose money.
In conclusion the payment-timeout and the revoke-time must be the same
in this channel design (which is inconvenient I think..). While the
payment-timeout should be as short as possible, a long revoke-time is
healthy in many instances.. 1 or maybe 2 days will probably be the
optimal trade-off then, although this can also be dangerously short in
case of full blocks..
More information about the Lightning-dev