Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-20 📝 Original message: On Tue, Feb 18, 2020 at ...

📅 Original date posted:2020-02-20
📝 Original message:
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