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] Ask First, Shoot (PTLC/HTLC) Later
>If it is a multipart and we have the preimage, wait for all the parts to arrive, then say yes to all of them. Without actual reservations made in the channels, is this going to work? For example: a 10M payment and a route that contains a channel with only 5M balance. The sender's multi-path algorithm will try to split and send the first 5M. Then they'll do the second 5M, but because there is no actual reservation, the second 5M seems to be passing alright through the bottleneck channel too. When the payment is then executed, it will fail. Or do nodes keep track of all the unresolved probes and deduct the total amount from the available balance? Of course only for the available balance for probes. When a real htlc comes through, outstanding probes are ignored. Although the problem with that could be that someone can spam you with probes so that your available 'probe' balance is zero and you'll receive no real traffic anymore. Perhaps an alternative is to let senders attach a random identifier to a probe. For multi-part probes, each probe will carry the same identifier. Routing nodes will deduct the outstanding probe amounts from the available balance, but only for probes within the same group (same id). That way each probe(group) is isolated from everything else that is going on. Joost On Wed, Sep 29, 2021 at 5:40 AM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning list, > > While discussing something tangentially related with aj, I wondered this: > > > Why do we shoot an HTLC first and then ask the question "can you > actually resolve this?" later? > > Why not something like this instead? > > * For a payer: > * Generate a path. > * Ask first hop if it can resolve an HTLC with those specs (passing the > encrypted onion). > * If first hop says "yes", actually do the `update_add_htlc` dance. > Otherwise try again. > * For a forwarder: > * If anybody asks "can you resolve this path" (getting an encrypted > onion): > * Decrypt one layer to learn the next hop. > * Check if the next hop is alive and we have the capacity towards it, > if not, answer no. > * Ask next hop if it can resolve the next onion layer. > * Return the response from the next hop. > * For a payee: > * If anybody asks "can you resolve this path": > * If it is not a multipart and we have the preimage, say yes. > * If it is a multipart and we have the preimage, wait for all the > parts to arrive, then say yes to all of them. > * Otherwise say no. > > Now, the most obvious reason against this, that comes to mind, is that > this is a potential DoS vector. > Random node can trigger a lot of network activity by asking random stuff > of random nodes. > Asking the question is free, after all. > > However, we should note that sending *actual* HTLCs is a similar DoS > vector **today**. > This is still "free" in that the asker has no need to pay fees for failed > HTLCs; they just lose the opportunity cost of the amount being locked up in > the HTLCs. > And presumably the opportunity cost is low since Lightning forwarding > earnings are so tiny. > > One way to mitigate against this is to make generating an onion costly but > validating and decrypting it cheap. > We could use an encryption scheme that is more computationally expensive > to encrypt but cheap to decrypt, for example. > Or we could require proof-of-work on the onion: each unwrapped onion > layer, when hashed, has to have a hash that is less than some threshold > (this scales according to the number of hops in the onion, as well). > Ultimate askers need to grind the shared secret until the onion layer hash > achieves the target. > > Obviously just because you asked a few milliseconds ago if a path is > viable does not mean that the path *remains* viable right now when you > actually send out an HTLC, but presumably that risk is now lessened. > Unexpected shutdowns or loss of connectivity has to appear in a smaller > and shorter time frame to negatively affect intermediate nodes. > > 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 where any node along a route can report a > forwarding or other payment error, and the sender is able to identify which > node along the path raised it. > Thus, the payer can identify which node along the route responded with a > "yes", and check that it
