Carla Kirk-Cohen [ARCHIVE] on Nostr: 📅 Original date posted:2023-04-28 🗒️ Summary of this message: The Lightning ...
📅 Original date posted:2023-04-28
🗒️ Summary of this message: The Lightning Network community is gathering data on the use of HTLC endorsement and local reputation tracking to mitigate channel jamming.
📝 Original message:
Hi list,
Some updates on channel jamming!
# Next Call
- Monday 01 May @ 15:00 UTC
- https://meet.jit.si/UnjammingLN
- Agenda: https://github.com/ClaraShk/LNJamming/issues/12
# Data Gathering
During these weekly calls, we've come to agreement that we would like
to gather data about the use of HTLC endorsement and local reputation
tracking for jamming mitigation. A reminder of the full scheme is
included at the end of this email, and covered more verbosely in [1].
We have a few goals in mind:
- Observe the effect of endorsement in the steady state with
logging-only implementation.
- Gather real-world data for use in future simulation work.
- Experiment with different algorithms for tracking local reputation.
The minimal changes required to add HTLC endorsement are outlined in [2].
Our suggestion is to start simple with a binary endorsement field. As
we learn more, we will be better equipped to understand whether a
more expressive value is required.
With this infrastructure in place, we can start to experiment with
various local reputation schemes and data gathering, possibly even
externally to LN implementations in projects like circuitbreaker [3].
We'd be interested to hear whether there's any appetite to deploy using
an experimental TLV value?
# Reputation Scheme
- Each node locally tracks the reputation of its direct neighbors.
- Each node allocates, per its risk tolerance:
- A number of slots reserved for endorsed HTLCs from high reputation
peers.
- A portion of liquidity reserved for endorsed HTLCs from high
reputation peers.
- Forwarding of HTLCs:
- If a HTLC is endorsed by a high reputation peer, it is forwarded
as usual with endorsed = 1.
- Otherwise, it is forwarded with endorsed = 0 if there are slots and
liquidity available for unknown HTLCs.
Endorsement and reputation are proposed as the first step in a two part
scheme for mitigating channel jamming:
- Reputation for slow jams which are easily detected as misbehavior.
- Unconditional fees for quick jams that are difficult to detect, as
they can always fall under a target threshold.
Looking forward to discussing further in the upcoming call!
Best,
Carla and Clara
[1] https://gist.github.com/carlaKC/be820bb638624253f3ae7b39dbd0e343
[2] https://github.com/lightning/bolts/pull/1071
[3] https://github.com/lightningequipment/circuitbreaker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230428/686b99f7/attachment.html>;
🗒️ Summary of this message: The Lightning Network community is gathering data on the use of HTLC endorsement and local reputation tracking to mitigate channel jamming.
📝 Original message:
Hi list,
Some updates on channel jamming!
# Next Call
- Monday 01 May @ 15:00 UTC
- https://meet.jit.si/UnjammingLN
- Agenda: https://github.com/ClaraShk/LNJamming/issues/12
# Data Gathering
During these weekly calls, we've come to agreement that we would like
to gather data about the use of HTLC endorsement and local reputation
tracking for jamming mitigation. A reminder of the full scheme is
included at the end of this email, and covered more verbosely in [1].
We have a few goals in mind:
- Observe the effect of endorsement in the steady state with
logging-only implementation.
- Gather real-world data for use in future simulation work.
- Experiment with different algorithms for tracking local reputation.
The minimal changes required to add HTLC endorsement are outlined in [2].
Our suggestion is to start simple with a binary endorsement field. As
we learn more, we will be better equipped to understand whether a
more expressive value is required.
With this infrastructure in place, we can start to experiment with
various local reputation schemes and data gathering, possibly even
externally to LN implementations in projects like circuitbreaker [3].
We'd be interested to hear whether there's any appetite to deploy using
an experimental TLV value?
# Reputation Scheme
- Each node locally tracks the reputation of its direct neighbors.
- Each node allocates, per its risk tolerance:
- A number of slots reserved for endorsed HTLCs from high reputation
peers.
- A portion of liquidity reserved for endorsed HTLCs from high
reputation peers.
- Forwarding of HTLCs:
- If a HTLC is endorsed by a high reputation peer, it is forwarded
as usual with endorsed = 1.
- Otherwise, it is forwarded with endorsed = 0 if there are slots and
liquidity available for unknown HTLCs.
Endorsement and reputation are proposed as the first step in a two part
scheme for mitigating channel jamming:
- Reputation for slow jams which are easily detected as misbehavior.
- Unconditional fees for quick jams that are difficult to detect, as
they can always fall under a target threshold.
Looking forward to discussing further in the upcoming call!
Best,
Carla and Clara
[1] https://gist.github.com/carlaKC/be820bb638624253f3ae7b39dbd0e343
[2] https://github.com/lightning/bolts/pull/1071
[3] https://github.com/lightningequipment/circuitbreaker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230428/686b99f7/attachment.html>;