Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-24 📝 Original message: Anthony Towns <aj at ...

📅 Original date posted:2020-02-24
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On Fri, Feb 21, 2020 at 12:35:20PM +1030, Rusty Russell wrote:
>> And if there is a grace period, I can just gum up the network with lots
>> of slow-but-not-slow-enough HTLCs.
>
> Well, it reduces the "gum up the network for <timeout> blocks" to "gum
> up the network for <grace period> seconds", which seems like a pretty
> big win. I think if you had 20 hops each with a 1 minute grace period,
> and each channel had a max_accepted_htlcs of 30, you'd need 25 HTLCs per
> second to block 1000 channels (so 2.7% of the 36k channels 1ml reports),
> so at the very least, successfully performing this attack would be
> demonstrating lightning's solved bitcoin's transactions-per-second
> limitation?

But the comparison here is not with the current state, but with the
"best previous proposal we have", which is:

1. Charge an up-front fee for accepting any HTLC.
2. Will hang-up after grace period unless you either prove a channel
close, or gain another grace period by decrypting onion.

(There was is an obvious extension to this, where you pay another HTLC
first which covers the (larger) up-front fee for the "I know the next
HTLC is going to take a long time").

That proposal is simpler, and covers this case quite nicely.

> at which point the best B can do is unilaterally close the B/C channel
> with their pre-HTLC commitment, but they still have to wait for that to
> confirm before they can safely cancel the HTLC with A, and that will
> likely take more than whatever the grace period is, so B will be losing
> money on holding fees.
>
> Whereas:
>
> A->B: here's a HTLC, locked in
>
> B->C: HTLC proposal
> C->B: sure: updated commitment with HTLC locked in
> B->C: great, corresponding updated commitment, plus revocation
> C->B: revocation
>
> means that if C goes silent before B receives a new commitment, B can
> cancel the HTLC with A with no risk (B can publish the old commitment
> still even if the new arrives later, and C can only publish the pre-HTLC
> commitment), and if C goes silent after B receives the new commitment, B
> can drop the new commitment to the blockchain and pay A's fees out of it.

Interesting; this adds a trip, but not in latency (since C can still
count on the HTLC being locked in at step 3).

I don't see how it helps B though? It still ends up paying A, and C
doesn't pay anything?

It forces a liveness check of C, but TBH I dread rewriting the state
machine for this when we can just ping like we do now.

>> There's an old proposal to fast-fail HTLCs: Bob sends an new message "I
>> would fail this HTLC once it's committed, here's the error"
>
> Yeah, you could do "B->C: proposal, C->B: no way!" instead of "sure" to
> fast fail the above too.
>
> And I think something like that's necessary (at least with my view of how
> this "keep the HTLC open" payment would work), otherwise B could send C a
> "1 microsecond grace period, rate of 3e11 msat/minute, HTLC for 100 sat,
> timeout of 2016 blocks" and if C couldn't reject it immediately would
> owe B 50c per millisecond it took to cancel.

Well, surely grace period (and penalty rate) are either fixed in the
protocol or negotiated up-front, not per-HTLC.

Cheers,
Rusty.