Re: [Lightning-dev] Jamming mitigation call
Hi, I am quite busy and focused on developing the Indranet lighting monetised onion relay network project, but I dropped my 2c in the hat relating to this, I just wanted to make a comment regarding related spam mitigation strategies which also form the basis of my project. When nodes in the network will not process data in a message without being paid, the cost of spamming useless data rises dramatically. The asymmetries that can exist between generating data and processing it lead to vulnerabilities, not just DoS of network but attacking memory and processing capacity of nodes. Might I suggest that if the idea of charging for services existed, and a scheme for accounting the consumption of pre-paid service were to exist, similar to the one I am devising for Indra, it would have the same benefit also for Lightning network in general: potential to earn a strongly guaranteed margin of profit, and that leading to the eventual growth of the network as it isn't a loss-leader investment. Wherever the economics favor attackers, making such services paid only or paid plus a dribble of free service, like the Bitcoin mempool, attackers will look elsewhere for easy prey. I will be keeping an eye on how security protocols develop with LN and hope to be able cross-pollinate where things intersect. I do think that onion routing is a loss-leader unless it has anonymous payments in it, and anonymous payments themselves are a utility for LN. - l0k1 > Subject: Re: [Lightning-dev] Jamming mitigation call > Message-ID: > CALZpt+GsNhZcv1u6_hjgt=1WpGE0nE5ygqHN3EUhjHTO9T=y...@mail.gmail.com > > Content-Type: text/plain; charset="utf-8" > > Hi Clara, > > Thanks for rolling the ball forward. > > On the agenda, a few more thoughts. > > > 1. Which parameters should be considered in reputation-based solutions? > > > I think before thinking about the parameters of reputation-based solutions, > we should discuss the security goal we're aiming to achieve with any > potential jamming solutions. Browsing the solution space some have aimed to > increase the opportunity cost for the attacker (e.g liquidity slots), some > to reduce the jamming intensity (e.g circuit breakers), some inflicting a > on-chain fee damage cost back to the adversary (e.g stake certificates), > some to achieve economic hedge of the routing hops (e.g unconditional > fees, reputation credentials). As of today, I would say a security goal > designed in the term of a monetary strategy could be more acceptable to the > routing hops node operators. Beyond that, I believe there is capturing this > design goal in a "measurable" notion, such as the unjamming lightning > paper's breakeven point, and see how we can enrich this "measurable" notion. > > > 2. Circuitbreaker [1] > > > While reviewing the circuitbreaker last week, I started to wonder if there > wasn't another "hidden" issue while solving channel jamming, namely > congestion control of the HTLC flows. A node operator is not only > interested that any liquidity unit allocated for a HTLC forward is paid > back with routing fees, but also in case of more forward demand than > liquidity offer, ready to process it (potentially by deferring and sending > backpressure messages to the HTLC sender). I don't know, though I think > that can be an interesting point to discuss. > > > 3. Onion relay network [2] and its potential uses. > > > Onion relay network rate-limits have been discussed earlier this year, with > a probabilistic backpressure scheme proposed. If the onion relay traffic > starts to have economically-weighable traffic (offers, credentials tokens, > etc), there could be a risk of onion-jamming. For the bootstrap of the > onion relay network, I believe this could be solved by leveraging more the > channel-network topology for the design of a solution. We could re-use the > evaluation framework from the unjamming lightning paper, I guess. > > In the meeting, I think it could be very valuable if we have reliable > transcripts and if we start to maintain a community repository, where we > can pin the issues, problems and ideas. > > On the frequency of the meeting, note some Lightning developers raised the > concern that biweekly might be too much: > https://gnusha.org/lightning-dev/2022-11-23.log (once a month could work > well too, if we have a sound agenda). > > Best, > Antoine > > Le jeu. 8 d?c. 2022 ? 11:08, Clara Shikhelman clara.shikhel...@gmail.com > > a ?crit : > > > Hi all, > > > > The agenda for next week's meeting (Monday the 12th, 7 pm UTC) is the > > following: > > > > 1. Which parameters should be considered in reputation-based solutions? > > 2. Circuitbreaker [1] > > 3. Onion relay network [2] and its potential uses. > > > > The link to the call: https://meet.jit.si/UnjammingLN > > > > See you there, > > Clara > > > > [1] > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003781.html > > [2] > >
Re: [Lightning-dev] Unjamming lightning (new research paper)
> I don't think so - today there are at least three different routing goals to > maximize - (a) privacy, > (b) fees, (c) success rate. For "live" payment, you probably want to lean > towards optimizing for > success rate, and many nodes do today by default. But that isn't the full > story - many nodes do > background rebalancing and they prefer to take paths which optimize for fees, > trying many paths they > think are likely to fail to see if they can rebalance with lower fees. I > don't think we should tell > those users/use-cases that they aren't allowed to do that or they're doing > something "wrong" - I > think choosing to optimize for fees (or, in the future, privacy) is an > important thing to allow, and > ideally make as reliable as possible, without charging extra for it. Right, the trade-offs here are really tricky to navigate and to whatever extent this is possible the choice of what trade-offs to make should be pushed to the user. For example, not knowing the real time channel balances clearly hurts routing success. If this degraded routing success from 95 percent to say 90 percent the network as a whole would probably be willing to pay that routing success "cost" to ensure better balance privacy. But if it degraded routing success from 95 percent to say 50 percent I expect much of the network wouldn't be willing to put up with that terrible routing success percentage and routing nodes would probably seek to broadcast their channel balances either in gossip or out of band. Similarly a routing node not knowing the source of the payment and the intermediate nodes on the route is fine (it is clearly *much* better for privacy) assuming jamming attacks occur rarely. But if the network is being paralyzed regularly by jamming attacks a routing node is going to show a lot more interest in which Lightning node it is routing payments for and which other Lightning nodes are also part of the route. You aren't going to want to continue to be subject to jamming attacks by the same Lightning node. Hence I stick by this from a protocol developer perspective. "Decisions protocol developers make will impact what data can be collected and how easy that data is to collect (there are already some tricky trade-offs with regards to privacy, routing success and transparency for when things go wrong) but beyond that protocol developers should leave it to others." A protocol developer (and individual implementation developer I guess) is going to have to wrestle with these trade-offs and to what extent options can be pushed to the user. But protocol reputation tokens that can be sold or transferred to an attacker or worse collected through gaming the system, ouch. The protocol developer has taken a problem (jamming attacks) that already exists and added an additional problem (reputation) which no doubt will be addressed by adding an additional problem on top of that and another on top of that etc etc. -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Sunday, December 4th, 2022 at 02:03, Matt Corallo wrote: > > On 11/15/22 12:09 PM, Clara Shikhelman wrote: > > > Matt – I don't know that I agree with "... upfront payments kinda kill the > > lightning UX ...". I > > think that upfront fees are almost essential, even outside the context of > > jamming. This also helps > > with probing, general spam, and other aspects. Furthermore, I think that > > the UX is very explainable, > > > Indeed, it may be explainable, but its still somewhat painful, I think. I do > wonder if we can enable > probing via a non-HTLC message and do immediate pre-send-probing to avoid > paying upfront fees on > paths that will fail. > > > and in general nodes shouldn't be motivated to send a lot of failed > > payments, and should adopt > > better routing strategies. > > > I don't think so - today there are at least three different routing goals to > maximize - (a) privacy, > (b) fees, (c) success rate. For "live" payment, you probably want to lean > towards optimizing for > success rate, and many nodes do today by default. But that isn't the full > story - many nodes do > background rebalancing and they prefer to take paths which optimize for fees, > trying many paths they > think are likely to fail to see if they can rebalance with lower fees. I > don't think we should tell > those users/use-cases that they aren't allowed to do that or they're doing > something "wrong" - I > think choosing to optimize for fees (or, in the future, privacy) is an > important thing to allow, and > ideally make as reliable as possible, without charging extra for it. > > Matt > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
