Vincenzo Palazzo [ARCHIVE] on Nostr: ð Original date posted:2023-05-11 ð Original message: Hi all, > Some updates on ...
ð
Original date posted:2023-05-11
ð Original message:
Hi all,
> 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.
There is anything that I can do to help here with lnmetrics tools?
With some guidance (because i lost the track of the situation here) I
can be able to deploy a metrics collector in production by the end of
May.
> - 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.
>
> 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.
Why not? I think this deserve a round on the real network also because
it is hard to simulat the real network imho, and I think
with some implementation like cln we can write an extention an deploy
it in some nodes, I need to go deeper into it but I can help with this.
> Looking forward to discussing further in the upcoming call!
Unfortunatlly I ran out of routing here :) but I would love to discuss
how I can help with some implementation details.
Thanks to update in a very compact way what it is going on in the
Jamming mitigating meetins, it is helping a lot.
Cheers!
Vincent.
ð Original message:
Hi all,
> 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.
There is anything that I can do to help here with lnmetrics tools?
With some guidance (because i lost the track of the situation here) I
can be able to deploy a metrics collector in production by the end of
May.
> - 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.
>
> 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.
Why not? I think this deserve a round on the real network also because
it is hard to simulat the real network imho, and I think
with some implementation like cln we can write an extention an deploy
it in some nodes, I need to go deeper into it but I can help with this.
> Looking forward to discussing further in the upcoming call!
Unfortunatlly I ran out of routing here :) but I would love to discuss
how I can help with some implementation details.
Thanks to update in a very compact way what it is going on in the
Jamming mitigating meetins, it is helping a lot.
Cheers!
Vincent.