Carla Kirk-Cohen [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-16 🗒️ Summary of this message: The Lightning ...
đź“… Original date posted:2023-05-16
🗒️ Summary of this message: The Lightning Network proposes a reputation scheme to clarify open questions. Reputation is tracked locally for each node's peers, and sudden changes in behavior are short-lived.
đź“ť Original message:
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. During a jamming attack, the less active edges of the network will
experience gradually degraded quality of service, but they will be
unaffected in times of peace.
3. Reputation is slow and expensive to build (accumulated through
payment of fees) and fast to degrade, so sudden changes in behavior
are short-lived.
4. Good reputation is always examined relative to a node’s recent
routing activity, so reputation gained cheaply in the past during
low-activity periods can’t be exploited in busier times.
Re [2]
> 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 informed decision, while the edges may be more
vulnerable, but they'd also be used by way fewer senders, and the
impact of an attack would also be proportionally smaller.
I’m unclear on what you mean by “individual senders” here? In our
scheme, nodes only track local reputation for their direct peers so
what matters is their history with all HTLCs a peer has forwarded to
them (not whether they come from repeat senders).
It’s true that nodes that forward fewer HTLCs are less likely to be
able to build a good reputation with very active routing nodes. In the
regular operation of the network, this should have low to no impact on
their activity - they don’t require much from their peers anyway.
During an attack, small and low activity nodes will temporarily be in
competition for large routing nodes’ scarce liquidity and slots, but
will still be able to interact with similar nodes where they have
better chances of building a good reputation.
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 CLN would be great! Seems
like lnmetrics would be a good home for it - I’ll follow up with you
when we start working on data collection.
Cheers,
Carla + Clara
[1] https://github.com/lightning/bolts/pull/1071
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003944.html
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003949.html
On Wed, May 10, 2023 at 7:58 AM Christian Decker <decker.christian at gmail.com>
wrote:
> 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 behavioral changes (going rogue from a prior
> clean record) and whitewashing attacks (switching identity, abusing
> any builtin bootstrapping method for new users to gain a good or
> neutral reputation before turning rogue repeatedly).
>
> 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 other
> part of the world, and then turn around and attack the nodes that
> trusted the reputation shared from those other parts.
>
> 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 informed decision, while the edges may be more
> vulnerable, but they'd also be used by way fewer senders, and the
> impact of an attack would also be proportionally smaller.
>
> Cheers,
> Christian
>
> On Mon, May 8, 2023 at 10:26 PM Antoine Riard <antoine.riard at gmail.com>
> wrote:
> >
> > 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 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 some
> reputational transitivity between incoming traffic and outgoing traffic.
> Namely, the acquisition cost of the local reputation should be equal to the
> max timevalue damage that one can inflict on a routing node channel
> accessible from its local counterparty granting this high-level of
> reputation.
> >
> > I don't know if this can be fixed by ensuring permanent link-level
> "gossip" where counterparties along a payment path expose their reputation
> heuristics to guarantee this transitivity, or it's a fundamental issue with
> a point-to-point approach like HTLC endorsement.
> >
> > Opened an issue on the repository to converge on a threat model:
> > https://github.com/ClaraShk/LNJamming/pull/13
> >
> > I still think building data gathering infrastructure for Lightning is
> valuable as ultimately any jamming mitigation will have to adapt its
> upfront fees or reputation acquisition cost in function of HTLC traffic and
> market forces.
> >
> > Looking forward to giving an update on Staking Credentials [0], an
> end-to-end approach to mitigate channel jamming.
> >
> > Best,
> > Antoine
> >
> > [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html
> >
> > Le dim. 30 avr. 2023 Ă 03:57, Carla Kirk-Cohen <kirkcohenc at gmail.com> a
> Ă©crit :
> >>
> >> 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
> >> _______________________________________________
> >> Lightning-dev mailing list
> >> Lightning-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230516/90159528/attachment.html>;
🗒️ Summary of this message: The Lightning Network proposes a reputation scheme to clarify open questions. Reputation is tracked locally for each node's peers, and sudden changes in behavior are short-lived.
đź“ť Original message:
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. During a jamming attack, the less active edges of the network will
experience gradually degraded quality of service, but they will be
unaffected in times of peace.
3. Reputation is slow and expensive to build (accumulated through
payment of fees) and fast to degrade, so sudden changes in behavior
are short-lived.
4. Good reputation is always examined relative to a node’s recent
routing activity, so reputation gained cheaply in the past during
low-activity periods can’t be exploited in busier times.
Re [2]
> 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 informed decision, while the edges may be more
vulnerable, but they'd also be used by way fewer senders, and the
impact of an attack would also be proportionally smaller.
I’m unclear on what you mean by “individual senders” here? In our
scheme, nodes only track local reputation for their direct peers so
what matters is their history with all HTLCs a peer has forwarded to
them (not whether they come from repeat senders).
It’s true that nodes that forward fewer HTLCs are less likely to be
able to build a good reputation with very active routing nodes. In the
regular operation of the network, this should have low to no impact on
their activity - they don’t require much from their peers anyway.
During an attack, small and low activity nodes will temporarily be in
competition for large routing nodes’ scarce liquidity and slots, but
will still be able to interact with similar nodes where they have
better chances of building a good reputation.
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 CLN would be great! Seems
like lnmetrics would be a good home for it - I’ll follow up with you
when we start working on data collection.
Cheers,
Carla + Clara
[1] https://github.com/lightning/bolts/pull/1071
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003944.html
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003949.html
On Wed, May 10, 2023 at 7:58 AM Christian Decker <decker.christian at gmail.com>
wrote:
> 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 behavioral changes (going rogue from a prior
> clean record) and whitewashing attacks (switching identity, abusing
> any builtin bootstrapping method for new users to gain a good or
> neutral reputation before turning rogue repeatedly).
>
> 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 other
> part of the world, and then turn around and attack the nodes that
> trusted the reputation shared from those other parts.
>
> 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 informed decision, while the edges may be more
> vulnerable, but they'd also be used by way fewer senders, and the
> impact of an attack would also be proportionally smaller.
>
> Cheers,
> Christian
>
> On Mon, May 8, 2023 at 10:26 PM Antoine Riard <antoine.riard at gmail.com>
> wrote:
> >
> > 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 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 some
> reputational transitivity between incoming traffic and outgoing traffic.
> Namely, the acquisition cost of the local reputation should be equal to the
> max timevalue damage that one can inflict on a routing node channel
> accessible from its local counterparty granting this high-level of
> reputation.
> >
> > I don't know if this can be fixed by ensuring permanent link-level
> "gossip" where counterparties along a payment path expose their reputation
> heuristics to guarantee this transitivity, or it's a fundamental issue with
> a point-to-point approach like HTLC endorsement.
> >
> > Opened an issue on the repository to converge on a threat model:
> > https://github.com/ClaraShk/LNJamming/pull/13
> >
> > I still think building data gathering infrastructure for Lightning is
> valuable as ultimately any jamming mitigation will have to adapt its
> upfront fees or reputation acquisition cost in function of HTLC traffic and
> market forces.
> >
> > Looking forward to giving an update on Staking Credentials [0], an
> end-to-end approach to mitigate channel jamming.
> >
> > Best,
> > Antoine
> >
> > [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html
> >
> > Le dim. 30 avr. 2023 Ă 03:57, Carla Kirk-Cohen <kirkcohenc at gmail.com> a
> Ă©crit :
> >>
> >> 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
> >> _______________________________________________
> >> Lightning-dev mailing list
> >> Lightning-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230516/90159528/attachment.html>;