Re: [Lightning-dev] A proposal for up-front payments.
On Thu, Feb 20, 2020 at 03:42:39AM +, ZmnSCPxj wrote: > 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. Suppose the channel state looks like: Bob's balance: $150 Carol's balance: $500 Bob to Carol: $50, hash X, timelock +2016 blocks The pre-signed close transaction will have already deducted maybe $1 in fees, say 50c from each balance. At 5% pa, that's $50*0.05*2/52, so about 10 cents worth of "holding" fees, so that seems like it's worth just committing to up-front, ie: Bob's balance: $149.60 (-.50+.10) Carol's balance: $499.40 (-.50-.10) Bob to Carol: $50, hash X, timelock +2016 blocks Fees: $1 And that seems necessary anyway: if the channel does drop to the chain, then the HTLC can't be cancelled, so if it never confirms, Bob will have had to pay, say, 9.5c to Alice waiting for the timeout, and can then immediately cancel the HTLC with Alice allowing it to finish unwinding. So I think the idea would be not to accept a (rate, amount, timelock) tuple for an incoming HTLC unless the rate*amount*timelock product is substantially less than what you're putting towards the blockchain fees anyway, as otherwise you've got bad incentives for the other guy to drop to the chain. Note the rate increases with number of hops, so if it's 1% pa per hop, the 11th peer will be emitting 10% pa. I think that's probably okay, because BTC's deflationary nature probably means you don't need to earn much interest on it, and you can naturally choose the rate dynamically based on how many HTLCs you currently have open and how much of your channel funds are being used up by the HTLC? Also, you'd presumably update your channel state every hundred blocks, reducing the 10c by half a cent or so each time, so you could have your risk reduce. Maybe there could be some way of bumping the timelock across a HTLC path so that the risk is capped, but if the HTLC is still being paid for it doesn't have to be cancelled? Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] A proposal for up-front payments.
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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] A proposal for up-front payments.
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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
