rich1.0Rusty Russell [ARCHIVE] (npub1zw…hkhpx)https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxnjumphttps://yabu.me📅 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.