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. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
