Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-06 📝 Original message: Hi *, > Our suggestion is ...
📅 Original date posted:2023-05-06
📝 Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230506/40daccce/attachment.html>;
📝 Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230506/40daccce/attachment.html>;