[Lightning-dev] Return to the Layered Commit Transactions?
matsjj at gmail.com
Tue Nov 24 17:47:36 UTC 2015
While working on the payment layer and messing around with timeouts /
timeframes for CSV and CLTV, I noticed a few things...
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...
I described that some time ago, but was unsure if I was right
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...
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.
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...
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 ...
More information about the Lightning-dev