Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
Good morning Joost, > On Thu, Oct 21, 2021 at 12:00 PM ZmnSCPxj wrote: > > > Good morning Joost, > > > > > A potential downside of a dedicated probe message is that it could be > > > used for free messaging on lightning by including additional data in the > > > payload for the recipient. Free messaging is already possible today via > > > htlcs, but a probe message would lower the cost to do so because the > > > sender doesn't need to lock up liquidity for it. This probably increases > > > the spam potential. I am wondering if it is possible to design the probe > > > message so that it is useless for anything other than probing. I guess it > > > is hard because it would still have that obfuscated 1300 bytes block with > > > the remaining part of the route in it and nodes can't see whether there > > > is other meaningful data at the end. > > > > For the probe, the onion max size does not *need* to be 1300, we could > > reduce the size to make it less useable for *remote* messaging. > > Yes, maybe it can be reduced a bit. But if we want to support 27 hops like we > do for payments, there will be quite some space left for messaging on real > routes which are mostly much shorter. Does six degrees of separation not apply for the LN? I assume it would --- presumably some mathist can actually check the actual network diameter? In particular, forwarding nodes have an incentive to shorten the degree of separation, at least to popular nodes, by building channels to those, so I presume the degrees of separation will remain low. I expect something like 10 hops would work reasonably well...? (Longer routes greatly compound their expected failure rate as well, so no reasonable payer would prefer longer routes if a shorter route would do) Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
On Thu, Oct 21, 2021 at 12:00 PM ZmnSCPxj wrote: > Good morning Joost, > > > A potential downside of a dedicated probe message is that it could be > used for free messaging on lightning by including additional data in the > payload for the recipient. Free messaging is already possible today via > htlcs, but a probe message would lower the cost to do so because the sender > doesn't need to lock up liquidity for it. This probably increases the spam > potential. I am wondering if it is possible to design the probe message so > that it is useless for anything other than probing. I guess it is hard > because it would still have that obfuscated 1300 bytes block with the > remaining part of the route in it and nodes can't see whether there is > other meaningful data at the end. > > For the probe, the onion max size does not *need* to be 1300, we could > reduce the size to make it less useable for *remote* messaging. > Yes, maybe it can be reduced a bit. But if we want to support 27 hops like we do for payments, there will be quite some space left for messaging on real routes which are mostly much shorter. Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
Good morning Joost, > A potential downside of a dedicated probe message is that it could be used > for free messaging on lightning by including additional data in the payload > for the recipient. Free messaging is already possible today via htlcs, but a > probe message would lower the cost to do so because the sender doesn't need > to lock up liquidity for it. This probably increases the spam potential. I am > wondering if it is possible to design the probe message so that it is useless > for anything other than probing. I guess it is hard because it would still > have that obfuscated 1300 bytes block with the remaining part of the route in > it and nodes can't see whether there is other meaningful data at the end. For the probe, the onion max size does not *need* to be 1300, we could reduce the size to make it less useable for *remote* messaging. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
A potential downside of a dedicated probe message is that it could be used for free messaging on lightning by including additional data in the payload for the recipient. Free messaging is already possible today via htlcs, but a probe message would lower the cost to do so because the sender doesn't need to lock up liquidity for it. This probably increases the spam potential. I am wondering if it is possible to design the probe message so that it is useless for anything other than probing. I guess it is hard because it would still have that obfuscated 1300 bytes block with the remaining part of the route in it and nodes can't see whether there is other meaningful data at the end. On Thu, Oct 14, 2021 at 9:48 AM Joost Jager wrote: > A practice that is widely applied by lightning wallets is to probe routes > with an unknown payment hash before making the actual payment. Probing > yields an accurate routing fee that can be shown to the user before > execution of the payment. > > The downside of this style of probing is that for a short period of time, > liquidity is locked up. Not just the sender's liquidity, but also liquidity > of nodes along the route. And if the probe gets stuck for whatever reason, > that short period may become longer. > > But does this lock up serve a purpose at all? Suppose there would be a > liquidity probing protocol message similar to `update_add_htlc` > (`probe_htlc`?) that would skip the whole channel update machinery and is > only forwarded to the next hop if the link would be able to carry the htlc. > Won't this work as well as the current probing without the downsides? Nodes > can obviously reject these probes because they are distinguishable from > real payments (contrary to unknown hash probing where everything looks the > same). However if they do so, senders won't use that route and the routing > node misses out on routing fees. > > Another problem of the lightning network is its susceptibility to channel > jamming. Multiple options have been proposed (see also > https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md), > but they all come with downsides. > > Personally I incline towards solutions that involve deterring the attacker > by making them pay actual satoshis. Lightning itself is payment system and > it seems that paying for the payments is a natural solution to the problem. > Several iterations of this idea have been proposed. One of my own that > builds on an earlier idea by t-bast is described in > https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-February/002958.html > . > > The main criticism that this proposal has received is that it deteriorates > the user experience for honest users when multiple payment routes need to > be attempted. Every attempt will have a cost, so the user will see its > balance going down by only just trying to make the payment. How bad this is > depends on the attempt failure rate. I expect this rate to become really > low as the network matures and senders hold routing nodes to high > standards. Others however think otherwise and consider a series of failed > attempts part of a healthy system. > > Custodial wallets could probably just swallow the cost for failures. They > typically use one pathfinding system for all their users and are therefore > able to collect a lot of information on routing node performance. This is > likely to decrease the payment failure rate to an acceptably low level. > > For non-custodial nodes, this may be different. They have to map out the > good routing nodes all by themselves and this exploration will bear a cost. > > So how would things work out with a combination of both of the proposals > described in this mail? First we make probing free (free as in no liquidity > locked up) and then we'll require senders to pay for failed payment > attempts too. Failed payment attempts after a successful probe should be > extremely rate, so doesn't this fix the ux issue with upfront fees? > > Joost > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
Good morning Joost, > There could be some corners where the incentives may not work out 100%, but I > doubt that any routing node would bother exploiting this. Especially because > there could always be that reputation scheme at the sender side which may > cost the routing node a lot more in lost routing fees than the marginal gain > from the upfront payment. > > Another option is that nodes that don't care to be secretive about their > channel balances could include the actual balance in a probe failed message. > Related: https://github.com/lightningnetwork/lightning-rfc/pull/695 > > Overall it seems that htlc-less probes are an improvement to what we > currently have. Immediate advantages include a reduction of the load on nodes > by cutting out the channel update machinery, better ux (faster probes) and no > locked up liquidity. On the longer term it opens up the option to charge for > failed payments so that we finally have an answer to channel jamming. One can argue that if you are hoping that forwarding nodes will not exploit this, you can also hope that forwarding nodes will not perform channel-jamming attacks. As I noted before, channel jamming attacks will never be performed by payers or payees --- they have an incentive to complete the transaction and earn gains from trade. Channel jamming attacks are performed by large forwarding nodes on their smaller competitors, since having 100 capacity on large versus 10 capacity on the smaller competitor is worse than having 89 capacity on the large versus 0 capacity on the smaller competitor. On the other hand, perhaps it is at this point that we should start computing the exact incentives, hmm. -- A thing to note is that any node along a path can disrupt an onion response by the simple expedient of XORing it with random stuff, or even just a non-0 constant. This may allow for an additional attack vector. Suppose I am a forwarding node and I receive a probe request, and it turns out the next hop lacks capacity right now. I could incite the next hop to lie by forwarding the probe request to the next hop despite the lack of capacity. If the next hop responds immediately, I can then corrupt the return onion. Presumably if the next hop responded immediately it was reporting my lie to the sender. By corrupting the return onion the ultimate sender is unable to determine *which* node along the route failed, and I can hope that the reputation penalty to my competitor forwarding nodes along the path compensates for the reputation hit I personally suffer. If the next hop takes some time before responding, then possibly it colluded with me to lie about the capacity on our channel (i.e. it actually went ahead and forwarded to the next hop despite knowing I lied). Then I could faithfully onion-encrypt the response and send it back to the ultimate sender. To mitigate against the above attack: * If a forwarding node gets a probe request for an amount that the asker is *currently* unable to give anyway: * The forwarding node should still forward the probe request. * On response, however, it replaces the response with its own report that the previous hop was a dirty liar. * Note that the asker is the one who has full control over their funds in the channel, so the asker cannot later claim "but the network latency mixed up our messages!" --- the asker knows when it does `update_add_htlc` to reduce its capacity, so it should know it has the capacity or not. Now, if we are going to add a message "the previous hop was a dirty liar" then we should ask if a forwarding node would want to make a false accusation. * Suppose the previous hop has sufficient capacity and asked us if we have our own capacity. * Does the current hop have any incentive to falsely accuse the previous hop? * No: if it did, then the sender would not try their channel again in the close future, thus leading to lower fee earnings. > ZmnSCPxj, as first person to propose the idea (I think?), would you be > interested in opening a draft PR on the spec repository that outlines the new > message(s) that we'd need and continue detailing from there? It might end up not happening given the stuff I juggle randomly, so feel free to start it. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
There could be some corners where the incentives may not work out 100%, but I doubt that any routing node would bother exploiting this. Especially because there could always be that reputation scheme at the sender side which may cost the routing node a lot more in lost routing fees than the marginal gain from the upfront payment. Another option is that nodes that don't care to be secretive about their channel balances could include the actual balance in a probe failed message. Related: https://github.com/lightningnetwork/lightning-rfc/pull/695 Overall it seems that htlc-less probes are an improvement to what we currently have. Immediate advantages include a reduction of the load on nodes by cutting out the channel update machinery, better ux (faster probes) and no locked up liquidity. On the longer term it opens up the option to charge for failed payments so that we finally have an answer to channel jamming. ZmnSCPxj, as first person to propose the idea (I think?), would you be interested in opening a draft PR on the spec repository that outlines the new message(s) that we'd need and continue detailing from there? Joost On Sat, Oct 16, 2021 at 12:51 AM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning Owen, > > > C now notes that B is lying, but is faced with the dilemma: > > > > "I could either say 'no' because I can plainly see that B is lying, or > > I could say 'yes' and get some free sats from the failed payment (or > > via the hope of a successful payment from a capacity increase in the > > intervening milliseconds)." > > Note that if B cannot forward an HTLC to C later, then C cannot have a > failed payment and thus cannot earn any money from the upfront payment > scheme; thus, at least that part of the incentive is impossible. > > On the other hand, there is still a positive incentive for continuing the > lie --- later, maybe the capacity becomes OK and C could earn both the > upfront fee and the success fee. > > > So C decides it's in his interest to keep the lie going. D, the payee, > > can't tell that it's a lie when it reaches her. > > > > If C did want to tattle, it's important that he be able to do so in a > > way that blames B instead of himself, otherwise payers will assume > > (incorrectly, and to C's detriment) that the liquidity deficit is with C > > rather than B. > > That is certainly quite possible to do. > > Regards, > ZmnSCPxj > ___ > 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] In-protocol liquidity probing and channel jamming mitigation
Good morning Owen, > C now notes that B is lying, but is faced with the dilemma: > > "I could either say 'no' because I can plainly see that B is lying, or > I could say 'yes' and get some free sats from the failed payment (or > via the hope of a successful payment from a capacity increase in the > intervening milliseconds)." Note that if B cannot forward an HTLC to C later, then C cannot have a failed payment and thus cannot earn any money from the upfront payment scheme; thus, at least that part of the incentive is impossible. On the other hand, there is still a positive incentive for continuing the lie --- later, maybe the capacity becomes OK and C could earn both the upfront fee and the success fee. > So C decides it's in his interest to keep the lie going. D, the payee, > can't tell that it's a lie when it reaches her. > > If C did want to tattle, it's important that he be able to do so in a > way that blames B instead of himself, otherwise payers will assume > (incorrectly, and to C's detriment) that the liquidity deficit is with C > rather than B. That is certainly quite possible to do. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
On Fri, Oct 15, 2021 at 02:29:15PM +, ZmnSCPxj wrote: > I propose substantially the same thing here: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-September/003256.html > > In that proposal, I wrote: > > > Another thought is: Does the forwarding node have an incentive to > > lie? > > Suppose the next hop is alive but the forwarding node has > > insufficient capacity towards the next hop. > > Then the forwarding node can lie and claim it can still resolve the > > HTLC, in the hope that a few milliseconds later, when the actual > > HTLC arrives, the capacity towards the next hop has changed. > > Thus, even if the capacity now is insufficient, the forwarding node > > has an incentive to lie and claim sufficient capacity. Under Joost's proposal, there's even more of an incentive to lie: sats to be had. > > Against the above, we can mitigate this by accepting "no" from *any* > > node along the path, but only accepting "yes" from the actual payee. This doesn't really help if all the routers along the way are lying and saying 'yes'. Only the payee's 'yes' is meaningful, and she doesn't have enough information to know if the routers were lying or not. I think the actual enforcement mechanism is (also from your proposal Zmn): > > Presumably, when a node receives a question, it checks if the asking > > node has sufficient capacity towards it first, and if not, fails the > > channel between them, since obviously the asking node is not > > behaving according to protocol and is buggy. But I'm not sure the incentives align for this tattling on your neighbor. Let's take an example A -> B -> C -> D A sends a probe towards D. B doesn't have sufficient liquidity to send to C. But B is a liar. B says 'yes'. C now notes that B is lying, but is faced with the dilemma: "I could either say 'no' because I can plainly see that B is lying, or I could say 'yes' and get some free sats from the failed payment (or via the hope of a successful payment from a capacity increase in the intervening milliseconds)." So C decides it's in his interest to keep the lie going. D, the payee, can't tell that it's a lie when it reaches her. If C did want to tattle, it's important that he be able to do so in a way that blames B instead of himself, otherwise payers will assume (incorrectly, and to C's detriment) that the liquidity deficit is with C rather than B. Maybe Joost's suggestion of using a simple reputation scheme would work. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
> > > On Thu, Oct 14, 2021 at 09:48:27AM +0200, Joost Jager wrote: > > > > > So how would things work out with a combination of both of the > > > proposals described in this mail? First we make probing free (free as > > > in no liquidity locked up) and then we'll require senders to pay for > > > failed payment attempts too. Failed payment attempts after a > > > successful probe should be extremely rate, so doesn't this fix the ux > > > issue with upfront fees? > > > > Why couldn't a malicious routing node (or group of colluding routing > > nodes) succeed the probe and then fail the payment in order to collect > > the failed payment fee? > > Good observation! > > I propose substantially the same thing here: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-September/003256.html I totally missed that thread, but it is indeed the same thing including the notion that it may make upfront payments palatable! Contains some great additional ideas too. Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
Good morning Owen, > On Thu, Oct 14, 2021 at 09:48:27AM +0200, Joost Jager wrote: > > > So how would things work out with a combination of both of the > > proposals described in this mail? First we make probing free (free as > > in no liquidity locked up) and then we'll require senders to pay for > > failed payment attempts too. Failed payment attempts after a > > successful probe should be extremely rate, so doesn't this fix the ux > > issue with upfront fees? > > Why couldn't a malicious routing node (or group of colluding routing > nodes) succeed the probe and then fail the payment in order to collect > the failed payment fee? Good observation! I propose substantially the same thing here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-September/003256.html In that proposal, I wrote: > Another thought is: Does the forwarding node have an incentive to lie? > Suppose the next hop is alive but the forwarding node has insufficient > capacity towards the next hop. > Then the forwarding node can lie and claim it can still resolve the HTLC, in > the hope that a few milliseconds later, when the actual HTLC arrives, the > capacity towards the next hop has changed. > Thus, even if the capacity now is insufficient, the forwarding node has an > incentive to lie and claim sufficient capacity. > > Against the above, we can mitigate this by accepting "no" from *any* node > along the path, but only accepting "yes" from the actual payee. We already have a mechanism to send an onion and get back an "error" reply; the reply can be identified by the sender as arising from any node along the path, or at the destination. Basically, we simply reuse this mechanism: * Do not need an HTLC with this onion. * Only accept a "everything is OK" result from the destination. * Accept a "sorry cannot forward" from *any* node along the path. Thus, a malicious node cannot succeed the probe --- the probe has to reach the destination. Now the malicious forwarding node could be colluding with the destination, but presumably the destination wants to *actually* get paid, so we expect that, economically, it has no incentive to cooperate with the malicious node to *fail* the actual payment later just to extract a tiny failure fee. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
On Fri, Oct 15, 2021 at 4:21 PM Owen Gunden wrote: > On Thu, Oct 14, 2021 at 09:48:27AM +0200, Joost Jager wrote: > > So how would things work out with a combination of both of the > > proposals described in this mail? First we make probing free (free as > > in no liquidity locked up) and then we'll require senders to pay for > > failed payment attempts too. Failed payment attempts after a > > successful probe should be extremely rate, so doesn't this fix the ux > > issue with upfront fees? > > Why couldn't a malicious routing node (or group of colluding routing > nodes) succeed the probe and then fail the payment in order to collect > the failed payment fee? > Yes they could, but senders should be really suspicious when this happens. It could happen occasionally because balances may have shifted in between probe and payment. But if it keeps happening they may want to ban this routing node for a long time. This may disincentivize the routing node enough to respond honestly to probes. Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
On Thu, Oct 14, 2021 at 09:48:27AM +0200, Joost Jager wrote: > So how would things work out with a combination of both of the > proposals described in this mail? First we make probing free (free as > in no liquidity locked up) and then we'll require senders to pay for > failed payment attempts too. Failed payment attempts after a > successful probe should be extremely rate, so doesn't this fix the ux > issue with upfront fees? Why couldn't a malicious routing node (or group of colluding routing nodes) succeed the probe and then fail the payment in order to collect the failed payment fee? ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] In-protocol liquidity probing and channel jamming mitigation
A practice that is widely applied by lightning wallets is to probe routes with an unknown payment hash before making the actual payment. Probing yields an accurate routing fee that can be shown to the user before execution of the payment. The downside of this style of probing is that for a short period of time, liquidity is locked up. Not just the sender's liquidity, but also liquidity of nodes along the route. And if the probe gets stuck for whatever reason, that short period may become longer. But does this lock up serve a purpose at all? Suppose there would be a liquidity probing protocol message similar to `update_add_htlc` (`probe_htlc`?) that would skip the whole channel update machinery and is only forwarded to the next hop if the link would be able to carry the htlc. Won't this work as well as the current probing without the downsides? Nodes can obviously reject these probes because they are distinguishable from real payments (contrary to unknown hash probing where everything looks the same). However if they do so, senders won't use that route and the routing node misses out on routing fees. Another problem of the lightning network is its susceptibility to channel jamming. Multiple options have been proposed (see also https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md), but they all come with downsides. Personally I incline towards solutions that involve deterring the attacker by making them pay actual satoshis. Lightning itself is payment system and it seems that paying for the payments is a natural solution to the problem. Several iterations of this idea have been proposed. One of my own that builds on an earlier idea by t-bast is described in https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-February/002958.html . The main criticism that this proposal has received is that it deteriorates the user experience for honest users when multiple payment routes need to be attempted. Every attempt will have a cost, so the user will see its balance going down by only just trying to make the payment. How bad this is depends on the attempt failure rate. I expect this rate to become really low as the network matures and senders hold routing nodes to high standards. Others however think otherwise and consider a series of failed attempts part of a healthy system. Custodial wallets could probably just swallow the cost for failures. They typically use one pathfinding system for all their users and are therefore able to collect a lot of information on routing node performance. This is likely to decrease the payment failure rate to an acceptably low level. For non-custodial nodes, this may be different. They have to map out the good routing nodes all by themselves and this exploration will bear a cost. So how would things work out with a combination of both of the proposals described in this mail? First we make probing free (free as in no liquidity locked up) and then we'll require senders to pay for failed payment attempts too. Failed payment attempts after a successful probe should be extremely rate, so doesn't this fix the ux issue with upfront fees? Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
