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 HTL
Hi *,
> 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.
I think the HTLC endorsement scheme as proposed is still suffering from a
vulnerability as local reputation can be
Hi,
I think the HTLC endorsement scheme as proposed is still suffering from a
> vulnerability as local reputation can be built up during periods of low
> routing fees, endorsement gained and then abused during periods of high
> routing fees. Therefore, it sounds to me this scheme should aim for so
Hi Antoine,
this is an intrinsic issue with reputation systems, and the main
reason I'm sceptical w.r.t. their usefulness in lightning.
Fundamentally any reputation system bases their expectations for the
future on experiences they made in the past, and they are thus always
susceptible to sudden b
From my perspective it really comes down to whether you want security
*guarantees* or data to assist you in making probabilistic judgments about
future behavior. Reputation data or reputation systems will never give you
guarantees for the reasons Christian explains. But reputation data is better
Hi Christian,
Thanks for your comments! We will discuss this further in the upcoming call
on the 15th, would be great to see you there!
> this is an intrinsic issue with reputation systems, and the main
> reason I'm sceptical w.r.t. their usefulness in lightning.
> Fundamentally any reputation s
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 abo
Hi all,
> > This gets compounded as soon as we start gossiping about reputations,
> > since now our decisions are no longer based just on information we can
> > witness ourselves, or at least verify its correctness, and as such an
> > attacker can most likely "earn" a positive reputation in some o
Hi all,
Pulling together a few conversation threads here. I’ve also updated
the draft spec PR [1] with a full write up of the reputation scheme
we’re proposing to help clarify open questions.
TL;DR
1. Reputation is tracked locally for each of a node’s peers, there
is *no gossip component*.
2. D
> Re [3]
> > I think with some implementation like cln we can write an extension
> > an deploy in some nodes, I need to go deeper into it but I can help
> > with this. But I would love to discuss how I can help with some
> > implementation details.
>
> An experimental data gathering mechanism for
Hi all,
> That is, one cannot gain reputation during low fee times and use it when
fees are high.
> Good reputation is also a function of the general environment, and so if
there is a fee spike, reputation will change. It is true that nodes can go
rogue, but this is why we aim > for the price of
Hi,
> The lack of transitivity of the reputation acquisition cost (e.g based on
> historical fees earned from forwards originating from the peer) between the
> hops of the payment path still raises a vulnerability issue for the
> endorsement scheme, I think.
>
> Namely, let's say you have Alice,
> > I'd be very interested in how many repeat interactions nodes get from
> individual senders, since that also tells us how much use we can get
> out of local-only reputation based systems, and I wouldn't be
> surprised if, for large routing nodes, we have sufficient data for
> them to make an inf
> I think it's important to differentiate between fees a node charges and
> *reputation_revenue*. Reputation is determined as a function of the latter.
> If Caroll has a very high *reputation_revenue* and Bob has a very low one,
> then Bob probably won't have a high reputation with Caroll, as the a
Hi,
> I think the distinction you're proposing between routing fees and reputation
> revenue matters in the HTLC endorsement model. For the example I'm using
> let's say Caroll and Bob share the same exact parameters,
> *reputation_revenue* = 1,000, *routing_window*=100 and *routing_window*=10,
Hi,
> Bob can also forward but not endorse Alice's HTLC. All of this is a
function of how much credit Bob gives to Alice's judgment. In case of
jamming, the damage that Alice inflicts should be proportional to the
revenue she recently created for Bob, and so the more damage, the higher
the thresho
Hi,
> Sure, I understand that in case of an attack, a routing node should have
> been paid a significant fee sum by the peer originating the jamming
> traffic. However from my understanding this is unclear with the proposed
> htlc endorsement system than the fees paid are fully economically
> com
Hi,
> The only damage we can observe in the protocol is routing fees. If we go
ahead with our suggestion, it will be straightforward to choose a different
threshold based on the preference of a node. We have some suggestions for
receiving nodes, for example.
I think there is another obvious damag
18 matches
Mail list logo
