ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-20 📝 Original message: Good morning Joost and ...
📅 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
📝 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