Carla Kirk-Cohen [ARCHIVE] on Nostr: 📅 Original date posted:2023-03-14 🗒️ Summary of this message: A summary of a ...
📅 Original date posted:2023-03-14
🗒️ Summary of this message: A summary of a jamming mitigations call discussing local reputation tracking and the redesign of the circuit breaker UI. Next call on March 21.
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230314/1ab60721/attachment.html>;
🗒️ Summary of this message: A summary of a jamming mitigations call discussing local reputation tracking and the redesign of the circuit breaker UI. Next call on March 21.
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230314/1ab60721/attachment.html>;