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