Hi list, Writing with a summary from our latest jamming mitigations call. Full transcript is available at [1].
Details for the next call: * Tuesday 21 March @ 17:00 UTC - *please note change of day/time* * https://meet.jit.si/UnjammingLN * Agenda: https://github.com/ClaraShk/LNJamming/issues/9 ## Housekeeping The participants discussed the possibility of adding a rotating chair for meetings, as suggested on the agenda issue [2]. There was no strong preference to introduce the structure of a chair, and none of the attendees volunteered to take on the role for the next meeting, so the a decision was taken to leave the meetings structured around a communally sourced agenda. ## Circuit Breaker Update The circuit breaker UI is being redesigned for a more user friendly experience, and to make it more mobile-friendly. ## Local Reputation The majority of the meeting's discussion was centered around approaches to local reputation tracking, as there have been multiple proposals suggested on the mailing list. ### Specification There was some general discussion around taking a simpler approach to reputation before trying to propose more ambitious algorithms for tracking whether a peer has "good" reputation. This suggestion aims for a more pragmatic approach to the long-unsolved quagmire of jamming mitigation proposals, and a way to make solutions more easily observable to end users. The reputation schemes that have been discussed so far depend on the addition of an "endorsement" fields to update_add_htlcs to help peers along around communicate whether they believe a HTLC is unlikely to be part of a jamming attack. The possibility of starting without an "endorsement" field was floated, though many participants believed that it was an important part of informing forwarding decisions. Instead, the possibility of simplifying the local reputation metric that is used to decide whether a peer's behavior is considered "good" was raised as a simplifying alternative. ### Upfront Fees The question was posed whether we will need to introduce upfront fees if we have an effective local reputation mechanism that can identify bad behavior. Opinions varied. It was noted that the original motivation for local reputation paired with upfront fees was to address attackers that target their attack to sit just beneath a "good" threshold. General consensus seemed to be that we should focus on reputation first, with the goal of measuring how effectively we can address spamming before endeavoring to add upfront fees to the protocol. ### Understanding of Attacks Discussion also touched on the shifting landscape for the types of attacks we are trying to mitigate - at present, a mitigation is proposed and then we think about custom attacks for that exact solution. Instead, it was suggested that we collect a set of different attack strategies that we wish to defend against, then compare different solutions effectiveness. The first, instinctual definition for an attack being successfully defeated is that it is unable to disrupt honest traffic. We agreed to use an issue on the repo that is used to administer these meetings to track various forms of attacks [3]. ### Simulation and Testing We spent some time discussing the availability of data and possibility of using simulations to compare various approaches. A few approaches to empirically examining the problem were discussed: * "Shadow" deployment of a reputation metric, just logging outcomes, to see how it would work on nodes today. * Data gathering on a collection of nodes in the network to feed into a more realistic simulation. * Simulation of various payment flows using the real network graph. One drawback that was noted is that we can't use real data to simulate attacks, since the network is not under attack in the steady state, and the challenge of realistically representing this type of traffic. As always, thanks to all who attended! Carla + Clara [1] https://github.com/ClaraShk/LNJamming/pull/8 [2] https://github.com/ClaraShk/LNJamming/issues/5 [3] https://github.com/ClaraShk/LNJamming/issues/7
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
