Anthony Towns <a...@erisian.com.au> writes: > Aside from those philosophical complaints, seems to me the simplest > attack would be: > > * route 1000s of HTLCs from your node A1 to your node A2 via different, > long paths, using up the total channel capacity of your A1/A2 nodes, > with long timeouts > * have A2 offer up a transaction claiming that was the channel > close to A3; make it a real thing if necessary, but it's probably > fake-able > * then leave the HTLCs open until they time out, using up capacity > from all the nodes in your 1000s of routes. For every satoshi of > yours that's tied up, you should be able to tie up 10-20sat of other > people's funds > > That increases the cost of the attack by one on-chain transaction per > timeout period, and limits the attack surface by how many transactions > you can get started/completed within whatever the grace period is, but > it doesn't seem a lot better than what we have today, unless onchain > fees go up a lot.
Interestingly, I think your "reverse commitment signing" proposal would mean the close tx will have the HTLC within it, so this attack is not possible? (Modulo handling dust HTLCs, which won't show up in the commitment tx). Previously I suggested the node simply send a (signed) list of up to N additional HTLCs (this reduces batching to N, so make it at least 16). This is gossiped, and if you get conflicting versions, the channel break is considered invalid, so (as always) the previous channel has to break. >> > 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 >> 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? > > The updated commitment has C paying B onchain; if B doesn't receive that > by the time the grace period's about over, B can cancel the HTLC with A, > and then there's statemachine complexity for B to cancel it with C if > C comes alive again a little later. I thought C paid per unit time, so it wouldn't pay up-front? You're suggesting it pays the max in the commitment, and then it gets some back in the normal case of things going right? >> 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. > > I'd be surprised if making musig work doesn't require a dread rewrite > of the state machine as well, and then there's PTLCs and eltoo... Hmm, PTLCs and eltoo don't. Musig requires some mods to the protocol, but the state machine changes are trivial. >> >> 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. > > I think the "keep open rate" should depend on how many nodes have > already been in the route (the more hops it's gone through, the more > funds/channels you're tying up by holding onto the HTLC, so the more > you should pay), while the grace period should depend on how many nodes > there are still to go in the route (it needs to be higher to let each of > those nodes deduct their delta from it). So I think you *should* expect > those to change per HTLC than you're forwarding, as those factors will > be different for different HTLCs. In theory, but I could lie about both, and it's very undesirable to communicate these things anyway. I think it might make it worse, not better, than having a fixed (per-msat?) rate. Cheers, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
