Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-24 📝 Original message: Mats Jerratsch <matsjj at ...

📅 Original date posted:2015-11-24
📝 Original message:
Mats Jerratsch <matsjj at gmail.com> writes:
> While working on the payment layer and messing around with timeouts /
> timeframes for CSV and CLTV, I noticed a few things...
>
> (1)
> 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...

Right.

This isn't immediately obvious, so let's unpack this a bit:

Because any to-self output needs to have an additional relative
revocation delay, A's HTLC output would look like:

For A if HTLC times out + revocation relative timeout, OR
For B with HTLC R value, OR
For B with revocation hash.

A needs to handle the case where B spends after the HTLC timeout, but
before the revocation relative timeout, so its inter-hop HTLC timeout
delta has to be > revocation timeout.

(Aside: can we reduce the HTLC timeout there so that it takes into account
the relative timeout? I'd have to think harder about all the other
scripts, too, but it seems reasonable on the surface?).

> (2)
> 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...

Yeah, don't do this.

> (3)
> 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.

This was my plan.

> 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...

It's not about DoS, really. The revocation time has to be long enough
so you're certain to spot someone cheating. And we've established that
the HTLC inter-hop-delta should be >> revocation time.

If your node is online and robust, 3 hours should be sufficient for
revocation time (remember, you can jack up fees if you need to). 12
hours will give you plenty of time to take your claim transactions and
inject them into the bitcoin network via carrier pidgeon or whatever you
need to get around any DDoS.

Still, let's assume everyone uses 1 day for revocation time, and 2 days
for HTLC timeout delta, and we have 20 hops.

The original HTLC (NODE 0 -> NODE 1) times out in 40 days. The last
HTLC (NODE 19 -> NODE 20) times out in 2 days, and that one falls to the
blockchain. NODE 19 takes 3 days to get a refund. Then it can
immediately close the incoming HTLC from NODE18 (why wait for a timeout?
It no longer has outstanding liabilities or any reason to believe it
will get the R value), etc.

So, worst case is 3 days unless there are multiple hop failures?

> 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 ...

Agreed.

What do you think about reducing the OP_CHECKLOCKTIMEVERIFY argument if
it's followed by the revocation delay?

Thanks!
Rusty.