rich1.0ZmnSCPxj [ARCHIVE] (npub1g5…3ms3l)https://yabu.me/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lnjumphttps://yabu.me📅 Original date posted:2020-02-20 📝 Original message: Good morning Joost and aj, A thought that arises here is, what happens if I have forwarded a payment, then the outgoing channel is dropped onchain and that peer disconnects from me? Since the onchain HTLC might have a timelock of, say, a few hundred blocks from now, the outgoing peer can claim it up until the timelock. If the peer does not claim it, I cannot claim it in my incoming as well. I also cannot safely fail my incoming, as the outgoing peer can still claim it until the timelock expires. Am I liable for paying the encumbrance fee in this situation? How do I charge the next node the encumbrance fee myself if it has dropped the channel onchain and disconnected from me? Regards, ZmnSCPxj > On Tue, Feb 18, 2020 at 10:23:29AM +0100, Joost Jager wrote: > > > A different way of mitigating this is to reverse the direction in which the > > bond is paid. So instead of paying to offer an htlc, nodes need to pay to > > receive an htlc. This sounds counterintuitive, but for the described jamming > > attack there is also an attacker node at the end of the route. The attacker > > still pays. > > I think this makes a lot of sense. I think the way it would end up working > is that the further the route extends, the greater the payments are, so: > > A -> B : B sends A 1msat per minute > A -> B -> C : C sends B 2msat per minute, B forwards 1msat/min to A > A -> B -> C -> D : D sends C 3 msat, etc > A -> B -> C -> D -> E : E sends D 4 msat, etc > > so each node is receiving +1 msat/minute, except for the last one, who's > paying n msat/minute, where n is the number of hops to have gotten up to > the last one. There's the obvious privacy issue there, with fairly > obvious ways to fudge around it, I think. > > But that's rational, because that last node can either (a) collect the > payment, covering their cost; or (b) forward the payment, at which point > they'll start collecting funds rather than paying them; or (c) cancel > the payment releasing all the locked up funds all the way back. > > I think it might make sense for the payments to have a grace period -- > ie, "if you keep this payment open longer than 20 seconds, you have to > start paying me x msat/minute, but if it fulfills or cancels before > then, it's all good". > > I'm not sure if there needs to be any enforcement for this beyond "this > peer isn't obeying the protocol, so I'm going to close the channel"; not > even sure it's something that needs to be negotiated as part of payment > routing -- it could just be something each peer does for HTLCs on their > channels? If that can be made to work, it doesn't need much crypto or > bitcoin consensus changes, or even much deployment coordination, all of > which would be awesome. > > I think at $10k/BTC then 1msat is about the fair price for locking up $5 > worth of BTC (so 50k sat) for 1 minute at a 1% pa interest rate, fwiw. > > Maybe this opens up some sort of an attack where a peer lies about the > time to make the "per minute" go faster, but if msats-per-minute is the > units, not sure that really matters. > > Maybe this also implies a different protocol for HTLC forwarding, > something like: > > 1. A sends the HTLC onion packet to B > 2. B decrypts it, makes sure it makes sense > 3. B sends a half-signed updated channel state back to A > 4. A accepts it, and forwards the other half-signed channel update to B > > so that at any point before (4) Alice can say "this is taking too long, > I'll start losing money" and safely abort the HTLC she was forwarding to > Bob to avoid paying fees; while only after (4) can she start the time on > expecting Bob to start paying fees that she'll forward back. That means > 1.5 round-trips before Bob can really forward the HTLC on to Carol; > but maybe it's parallelisable, so Bob/Carol could start at (1) as soon > as Alice/Bob has finished (2). > > Cheers > aj > > > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev