Re: [Lightning-dev] LN Summit 2023 Notes

Hi AJ, A different way of thinking about the monetary approach is in terms of > scaling rather than deterrance: that is, try to make the cost that the > attacker pays sufficient to scale up your node/the network so that you > continue to have excess capacity to serve regular users. > > In that

Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation

Hi, > Sure, I understand that in case of an attack, a routing node should have > been paid a significant fee sum by the peer originating the jamming > traffic. However from my understanding this is unclear with the proposed > htlc endorsement system than the fees paid are fully economically >

Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation

Hi, > I think the distinction you're proposing between routing fees and reputation > revenue matters in the HTLC endorsement model. For the example I'm using > let's say Caroll and Bob share the same exact parameters, > *reputation_revenue* = 1,000, *routing_window*=100 and

Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation

Hi, > The lack of transitivity of the reputation acquisition cost (e.g based on > historical fees earned from forwards originating from the peer) between the > hops of the payment path still raises a vulnerability issue for the > endorsement scheme, I think. > > Namely, let's say you have Alice,

[Lightning-dev] Jamming call May 15th

Hi List, A reminder that we've got another jamming call coming up next week. Monday 15 May 5 pm UTC https://meet.jit.si/UnjammingLN In this meeting, we’d like to discuss HTLC endorsement and local reputation [1]. We’ve updated the draft spec PR with some details on what we think reputation

Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation

Hi Christian, Thanks for your comments! We will discuss this further in the upcoming call on the 15th, would be great to see you there! > this is an intrinsic issue with reputation systems, and the main > reason I'm sceptical w.r.t. their usefulness in lightning. > Fundamentally any reputation

Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation

Hi, I think the HTLC endorsement scheme as proposed is still suffering from a > vulnerability as local reputation can be built up during periods of low > routing fees, endorsement gained and then abused during periods of high > routing fees. Therefore, it sounds to me this scheme should aim for

Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming

Hi, This is unclear on which criterias the endorsement decision is made > A node endorses an HTLC if and only if it came from a neighbour that has reputation 1 that endorsed it. > Additionally, this is unclear how the available liquidity/slots on a given > outbound channel are initially

[Lightning-dev] Jamming Mitigation Call Today

Hi List, A reminder that we've got another jamming call coming up today at 19:00 UTC. Monday 06 Mar 19:00 UTC https://meet.jit.si/UnjammingLN Feel free to add additional agenda items here: https://github.com/ClaraShk/LNJamming/issues/ 5 See you

Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming

> With a binary solution a single attacker can easily fill your quota of > low-confidence HTLCs and then all low-reputation nodes are blocked. But not > all of them are attackers, some of them just don't send you enough traffic > to get a high reputation for instance and you're going to block them

Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming

ou will have a reputation of 1 > but your HTLCs will still be rejected at the first sign of congestion. > > Le ven. 3 mars 2023 à 17:14, Clara Shikhelman > a écrit : > >> Hi Thomas, >> >> Thanks for the example. >> >> - If c < p then yes it gives it a higher

Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming

Hi Thomas, Thanks for the example. - If c < p then yes it gives it a higher reputation but the reputation is > capped at 1 anyway, so by underestimating the confidence the node doesn't > gain anything. > Is there anything to gain from giving high confidence? By doing this, you risk lowering your

Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming

we reject and reduce the number of innocent casualties. > > Thomas > > Le jeu. 16 févr. 2023 à 22:29, Clara Shikhelman < > clara.shikhel...@gmail.com> a écrit : > >> Hi List, >> >> We’re writing to seek early feedback on a draft for a neighbour >> reputa

[Lightning-dev] Local Reputation to Mitigate Slow Jamming

Hi List, We’re writing to seek early feedback on a draft for a neighbour reputation setting recommendation as a jamming mitigation. The main idea is that allowing full access to liquidity and slots in a channel can result in jamming. To prevent this, we allow full access only to neighbours that

Re: [Lightning-dev] Jamming Mitigation Call Summary - 02/06

Hi Vincent, Thanks to write this down, do you think that it is a good idea > to make a public google calendar (or other kind of shared calendar)? > Let's try this out:

[Lightning-dev] Jamming mitigation call for 2023

Hi All, Time to bring back the anti-jamming discussions! Our next call will be on January 23rd at 6 pm UTC (notice the time change) at the usual place: https://meet.jit.si/UnjammingLN. A draft of the agenda is available here: https://github.com/ClaraShk/LNJamming/issues/1 Please feel free to

Re: [Lightning-dev] Jamming mitigation call

o 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 t

Re: [Lightning-dev] Jamming mitigation call

you there, Clara [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003781.html [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003780.html On Sun, Nov 27, 2022 at 9:48 PM Clara Shikhelman wrote: > Hi all, > > In light of recent conv

Re: [Lightning-dev] Unjamming lightning (new research paper)

Hi Matt, > 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. > > This could be a good idea, but I think that it

[Lightning-dev] Jamming mitigation call

Hi all, In light of recent conversations ([1],[2]), the agenda for the call tomorrow (Monday the 28th, 7 pm UTC) is roughly the following: 1. Overview of solutions under discussion 2. Reputation (local/tokens) 3. Fees This is the link to the call: https://meet.jit.si/UnjammingLN See you there,

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

we could even save more in > upfront/unconditional fees in the steady state of the network (however such > a probabilistic model breaks hard in presence of attackers). > > Best, > Antoine > > Le jeu. 24 nov. 2022 à 09:45, Clara Shikhelman > a écrit : > >> Hi Antoine, >

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

monetary credentials, in the acceptance of a HTLC forward request. > > So I think I agree with you a recommended policy is needed, let's just > start with a simple one! And refine it with time once we sense we have > solid foundations. > > Best, > Antoine > > > Le me

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

hinking more to > refine the proposed credentials architectural framework. > I think dynamic routing policy in function of channel congestion rate, and > you combine that with reputation to do active risk-management are far more > advanced questions. > > Best, > Antoine >

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

Dear All, If the call time (Monday the 28th at 7 pm UTC) doesn't work out for you, please reach out! Thanks for your quick and detailed response, Antoine. If by recommend policy, you mean the set of algorithms that should guide > the token quantity, rate issuance, token acquisition cost, and

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

Dear Antoine and list, I think that another call to discuss jamming would be great. I would suggest making it a repeating call every 2 weeks, starting from Monday the 28th at 7 pm UTC. Antoine - Thank you for your work! I have a few questions to better understand the details. 1. Are the tokens

Re: [Lightning-dev] Unjamming lightning (new research paper)

ally that required > network-wide upgrade, until we’re confident it’s the right direction. Even > binary HTLC reputation flags, I think, carry a very large privacy cost so > it’s strongly worth exploring every alternative before we commit. > > Matt > > On Nov 10, 2022, at 10:35, Cl

Re: [Lightning-dev] Unjamming lightning (new research paper)

Hi all, We are planning a call to discuss this proposal further. It will be on Monday the 14th, at 7 pm UTC here: https://meet.jit.si/UnjammingLN Please let me know if this conflicts with any other Bitcoin event. Hope to see you all there! On Thu, Nov 3, 2022 at 1:25 PM Clara Shikhelman wrote

Re: [Lightning-dev] Unjamming lightning (new research paper)

Hi, Thanks for your comments! (I'm less convinced about the unconditional fee as it changes a core > principle of the network which means that we'll never reach consensus on > it). > I think this is a core principle that opens the network to several attacks and should be changed. Furthermore,

Re: [Lightning-dev] Unjamming lightning (new research paper)

Hi Antoine, Thank you for the detailed response! > On the framework for mitigation evaluation, there are few other dimensions > we have considered in the past with Gleb for our research that could be > relevant to integrate. One is "centralization", the solution shouldn't > centralize sensibly

[Lightning-dev] Unjamming lightning (new research paper)

Hi list, We would like to share with you our recent research on jamming in Lightning. We propose a combination of unconditional (~ upfront) fees and local reputation to fight jamming. We believe this can be a basis for an efficient and practical solution that can be implemented in the foreseeable

Re: [Lightning-dev] Route reliability<->fee trade-off control parameter

Hi Joost, A quick way to resolve this is to normalize the payment fees to a [0,1] scale. Two natural ways to do this are the following. 0 in both of them is some maximum set by the user (maybe with some reasonable default), 1 could be either the cheapest path or simply 0 sat. Once we have