Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2023-03-06 🗒️ Summary of this message: The local ...
đź“… Original date posted:2023-03-06
🗒️ Summary of this message: The local reputation channel involves forwarding requests from one party to another based on reputation and available outbound liquidity/slots. However, there are concerns about endorsement decision criteria, reputation slashing in case of HTLC failure, and exploitable reputation asymmetries.
đź“ť Original message:
Hi all,
My understanding of the local reputation channel is the following, when Bob
receives a HTLC forwarding request from Alice to Caroll:
- if Alice has reputation of 1 and Alice endorses the transaction, Bob
forwards and endorses the HTLC to Caroll
- else if the HTLC amount is under the available outbound liquidity quota
assigned to Alice and available outbound slots assigned to Alice, Bob
forwards the HTLC to Caroll and reduce available outbound liquidity/slots
assigned to Alice
- else the HTLC is rejected
This is unclear on which criterias the endorsement decision is made (e.g
CLTV expiry delta, odds of settlement, ongoing congestion of outbound
channels ?). Additionally, this is unclear how the available
liquidity/slots on a given outbound channel are initially distributed
between all the inbound channels (e.g proportional to the capacity) and how
they're balanced once the inbound channels start to accumulate reputation.
I don't know if this local reputation scheme precises how reputation is
slashed in case of HTLC failure, and if any "grace" amount/rate is granted
to the inbound channel counterparty, e.g Alice.
Independently of those considerations, I think this local reputation scheme
might suffer from exploitable reputation asymmetries by a jamming adversary.
Let's say you have the topology:
Alice - Bob - Caroll - Dave
Alice accumulated a reputation of 1 towards Bob and same for Bob towards
Caroll. As `fee_base_msat` Bob picked up 1000 msat and Caroll picked up
2000 msat. If Alice forwards a HTLC to Bob and it is endorsed by him before
relay to Caroll, Alice can now inflict a 50 sat damage to Caroll, while
only encumbering the lower-priced reputational cost towards Bob.
This concern could hold in case of asymmetries arising from the dynamic
adjustment of routing fees during an evaluated period of time. E.g both Bob
and Caroll requires routing fees of 1000 msat. Alice builds up a reputation
of 1 towards Bob during this period N. At period N+1, Caroll bumps her
routing fees to 2000 msat. From now on, Alice can exploit this asymmetry.
While I think this deficiency could be fixed by ensuring a proportionality
of the reputation acquisition cost between the inbound channels and the
cost requested by a counterparty on an outbound channel, I believe this
would come with the downside that any update in reputation cost should be
recursively applied to the downstream links (i.e Bob on Alice channel,
Alice on neighbouring inbound channels, etc).
Apart of this reputation asymmetry concern, I think the local reputation
scheme could suffer from spontaneous jamming by "honest" long-term held
packets (e.g CLTV delta=2 weeks), where even if Alice is not scored to 1 by
Bob, she always settles her long-term held packets. However, those packets
are yielding less routing fees to Bob than let's say 14 HTLC packets of
CLTV delta = 1 day.
Finally, the dynamic reduction of the available outbound liquidity/slots in
the occurrence of reputation=0 counterparty's HTLC being only known at the
link-level could break the expectations of the HTLC senders scoring
algorithms. E.g, being connected to Alice might have probed through another
path the available liquidity on the link Bob-Caroll. This Eve's probe is
falsified by any reduction done by Caroll towards Bob, and therefore Eve's
payment reliability is likely to be downgraded.
Best,
Antoine
Le jeu. 16 févr. 2023 à 21:29, Clara Shikhelman <clara.shikhelman at gmail.com>
a Ă©crit :
> Hi List,
>
> We’re writing to seek early feedback on a draft for a neighbour reputation
> setting recommendation as a jamming mitigation. The main idea is that
> allowing full access to liquidity and slots in a channel can result in
> jamming. To prevent this, we allow full access only to neighbours that
> forward HTLC that resolve quickly and generate more profit than the damage
> they can potentially create.
>
> The full suggested jamming mitigation solution includes upfront fees
> together with reputation, see [1] for details.
>
> In the previous episodes:
>
> As presented here [1], we suggest a two part jamming mitigation strategy.
> Reputation-based forwarding is aimed to solve “slow jamming”, where the
> jamming transaction takes a long time to resolve.
>
> The main idea is that each node gives a binary reputation to its
> neighbour. Each channel has a quota of liquidity and slots (say 50% of the
> channel size and 50% of the slots in the channel) dedicated to transactions
> coming from neighbours with reputation 0, or for transactions coming from
> neighbours with reputation 1 that were not endorsed by the neighbour.
>
> For example, when Alice asks Bob to forward to Charlie then:
>
> If (Alice has reputation 1 with Bob) and (Alice endorses transaction):
>
> Forward and endorse
>
> Else:
>
> If (amount < available liquidity quota) and (available slots in quota>0):
>
> Forward HTLC without endorsing
>
> Reduce available liquidity and slots
>
> Else:
>
> Reject
>
> Reputation:
>
> The question we discuss here is how does Alice gain “good” reputation
> (i.e., a score of 1). Alice starts at 0, and she gains and keeps her good
> reputation of 1 by continuously paying more fees to Bob than the damage she
> can inflict.
>
> The 3 main parameters for reputation that each node operator picks are S,L
> and M. Our recommendations are as follows:
>
> -
>
> S should be chosen as the maximum time an HTLC can be unresolved in
> any of Bob’s channels.
> -
>
> M is the revenue generated by Bob’s node in the time S, representing
> the damage Alice could inflict.
> -
>
> L is the time in which Alice should generate M revenue for Bob for her
> to have a good reputation of 1. We suggest L=10S.
>
>
> Alice has reputation 1 if, in the last L seconds, she has forwarded
> payments that generated M satoshi in fees.
>
> As an example:
>
> -
>
> Bob has a maximum CLTV delta of 2 weeks [2]
> -
>
> Over the last 2 weeks, he has earned 0.5 BTC in routing fees
> -
>
> Alice will be considered to have good reputation if she has forwarded
> 0.5 BTC of routing revenue to Bob over the last 20 weeks
>
>
> Formally:
>
> Let t be the current time, and let S and L be constants.
>
> M is calculated to be the revenue of Bob in time [t-S,t]. The revenue of
> Bob is the sum of fees from transactions forwarded by any neighbour besides
> Alice + any payments received by Bob. Note that Bob can choose to also take
> into account utility gained from sending payments or anything of value to
> the node operator.
>
> Alice has reputation 1 if in the time [t-L,t] she has forwarded HTLCs
> that paid M in normalized fees.
>
> We normalize fees by resolution time to reward payments that resolve
> quickly and discount slow resolving payments. Here we assume 10 seconds is
> the “normal” resolution time, this number can be bikesheded, and we round
> up to avoid penalizing transactions resolved quicker than the “normal”.
>
> The fee from a single transaction is normalized by the time it took for
> the HTLC to resolve, counted in slots of 10 seconds. That is:
>
> Normalized_fee = (fee)/[ceiling(time_to_resolve/10s)]
>
>
>
> Some notes
>
> 1.
>
> The reputation management happens locally, that is, the only protocol
> change needed is the ability to signal endorsement as a TLV in
> UpdateAddHTLC. The various parameters can be selected for various risk
> preferences.
> 2.
>
> We currently suggest a binary reputation for simplicity. Having
> several buckets could be interesting to study, yet we don’t think that the
> complexity and the possible privacy issues are worth the potential benefits.
> 3.
>
> For most use cases, having reputation 0 is more than enough. If we
> send and receive transactions at a low rate, we usually don’t need the full
> liquidity and slots available in a channel. Reputation mostly comes into
> play only when a channel is under attack, and then not all transaction are
> allowed to go through.
> 4.
>
> Following this thread [3]: it is important to note that we are only
> giving reputation to our direct neighbours. An advantage of this is that we
> have repeated interactions with them. In practice, this is also the only
> clean data we have to use when deciding whether to forward an HTLC or not.
>
>
> Best,
>
> Carla and Clara
>
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
> [2]
> https://github.com/lightningnetwork/lnd/blob/de94a4ea5e81799330a72dfde111817b38565d99/htlcswitch/link.go#L51
> [3]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003842.html
> _______________________________________________
> 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/20230306/d19448db/attachment-0001.html>;
🗒️ Summary of this message: The local reputation channel involves forwarding requests from one party to another based on reputation and available outbound liquidity/slots. However, there are concerns about endorsement decision criteria, reputation slashing in case of HTLC failure, and exploitable reputation asymmetries.
đź“ť Original message:
Hi all,
My understanding of the local reputation channel is the following, when Bob
receives a HTLC forwarding request from Alice to Caroll:
- if Alice has reputation of 1 and Alice endorses the transaction, Bob
forwards and endorses the HTLC to Caroll
- else if the HTLC amount is under the available outbound liquidity quota
assigned to Alice and available outbound slots assigned to Alice, Bob
forwards the HTLC to Caroll and reduce available outbound liquidity/slots
assigned to Alice
- else the HTLC is rejected
This is unclear on which criterias the endorsement decision is made (e.g
CLTV expiry delta, odds of settlement, ongoing congestion of outbound
channels ?). Additionally, this is unclear how the available
liquidity/slots on a given outbound channel are initially distributed
between all the inbound channels (e.g proportional to the capacity) and how
they're balanced once the inbound channels start to accumulate reputation.
I don't know if this local reputation scheme precises how reputation is
slashed in case of HTLC failure, and if any "grace" amount/rate is granted
to the inbound channel counterparty, e.g Alice.
Independently of those considerations, I think this local reputation scheme
might suffer from exploitable reputation asymmetries by a jamming adversary.
Let's say you have the topology:
Alice - Bob - Caroll - Dave
Alice accumulated a reputation of 1 towards Bob and same for Bob towards
Caroll. As `fee_base_msat` Bob picked up 1000 msat and Caroll picked up
2000 msat. If Alice forwards a HTLC to Bob and it is endorsed by him before
relay to Caroll, Alice can now inflict a 50 sat damage to Caroll, while
only encumbering the lower-priced reputational cost towards Bob.
This concern could hold in case of asymmetries arising from the dynamic
adjustment of routing fees during an evaluated period of time. E.g both Bob
and Caroll requires routing fees of 1000 msat. Alice builds up a reputation
of 1 towards Bob during this period N. At period N+1, Caroll bumps her
routing fees to 2000 msat. From now on, Alice can exploit this asymmetry.
While I think this deficiency could be fixed by ensuring a proportionality
of the reputation acquisition cost between the inbound channels and the
cost requested by a counterparty on an outbound channel, I believe this
would come with the downside that any update in reputation cost should be
recursively applied to the downstream links (i.e Bob on Alice channel,
Alice on neighbouring inbound channels, etc).
Apart of this reputation asymmetry concern, I think the local reputation
scheme could suffer from spontaneous jamming by "honest" long-term held
packets (e.g CLTV delta=2 weeks), where even if Alice is not scored to 1 by
Bob, she always settles her long-term held packets. However, those packets
are yielding less routing fees to Bob than let's say 14 HTLC packets of
CLTV delta = 1 day.
Finally, the dynamic reduction of the available outbound liquidity/slots in
the occurrence of reputation=0 counterparty's HTLC being only known at the
link-level could break the expectations of the HTLC senders scoring
algorithms. E.g, being connected to Alice might have probed through another
path the available liquidity on the link Bob-Caroll. This Eve's probe is
falsified by any reduction done by Caroll towards Bob, and therefore Eve's
payment reliability is likely to be downgraded.
Best,
Antoine
Le jeu. 16 févr. 2023 à 21:29, Clara Shikhelman <clara.shikhelman at gmail.com>
a Ă©crit :
> Hi List,
>
> We’re writing to seek early feedback on a draft for a neighbour reputation
> setting recommendation as a jamming mitigation. The main idea is that
> allowing full access to liquidity and slots in a channel can result in
> jamming. To prevent this, we allow full access only to neighbours that
> forward HTLC that resolve quickly and generate more profit than the damage
> they can potentially create.
>
> The full suggested jamming mitigation solution includes upfront fees
> together with reputation, see [1] for details.
>
> In the previous episodes:
>
> As presented here [1], we suggest a two part jamming mitigation strategy.
> Reputation-based forwarding is aimed to solve “slow jamming”, where the
> jamming transaction takes a long time to resolve.
>
> The main idea is that each node gives a binary reputation to its
> neighbour. Each channel has a quota of liquidity and slots (say 50% of the
> channel size and 50% of the slots in the channel) dedicated to transactions
> coming from neighbours with reputation 0, or for transactions coming from
> neighbours with reputation 1 that were not endorsed by the neighbour.
>
> For example, when Alice asks Bob to forward to Charlie then:
>
> If (Alice has reputation 1 with Bob) and (Alice endorses transaction):
>
> Forward and endorse
>
> Else:
>
> If (amount < available liquidity quota) and (available slots in quota>0):
>
> Forward HTLC without endorsing
>
> Reduce available liquidity and slots
>
> Else:
>
> Reject
>
> Reputation:
>
> The question we discuss here is how does Alice gain “good” reputation
> (i.e., a score of 1). Alice starts at 0, and she gains and keeps her good
> reputation of 1 by continuously paying more fees to Bob than the damage she
> can inflict.
>
> The 3 main parameters for reputation that each node operator picks are S,L
> and M. Our recommendations are as follows:
>
> -
>
> S should be chosen as the maximum time an HTLC can be unresolved in
> any of Bob’s channels.
> -
>
> M is the revenue generated by Bob’s node in the time S, representing
> the damage Alice could inflict.
> -
>
> L is the time in which Alice should generate M revenue for Bob for her
> to have a good reputation of 1. We suggest L=10S.
>
>
> Alice has reputation 1 if, in the last L seconds, she has forwarded
> payments that generated M satoshi in fees.
>
> As an example:
>
> -
>
> Bob has a maximum CLTV delta of 2 weeks [2]
> -
>
> Over the last 2 weeks, he has earned 0.5 BTC in routing fees
> -
>
> Alice will be considered to have good reputation if she has forwarded
> 0.5 BTC of routing revenue to Bob over the last 20 weeks
>
>
> Formally:
>
> Let t be the current time, and let S and L be constants.
>
> M is calculated to be the revenue of Bob in time [t-S,t]. The revenue of
> Bob is the sum of fees from transactions forwarded by any neighbour besides
> Alice + any payments received by Bob. Note that Bob can choose to also take
> into account utility gained from sending payments or anything of value to
> the node operator.
>
> Alice has reputation 1 if in the time [t-L,t] she has forwarded HTLCs
> that paid M in normalized fees.
>
> We normalize fees by resolution time to reward payments that resolve
> quickly and discount slow resolving payments. Here we assume 10 seconds is
> the “normal” resolution time, this number can be bikesheded, and we round
> up to avoid penalizing transactions resolved quicker than the “normal”.
>
> The fee from a single transaction is normalized by the time it took for
> the HTLC to resolve, counted in slots of 10 seconds. That is:
>
> Normalized_fee = (fee)/[ceiling(time_to_resolve/10s)]
>
>
>
> Some notes
>
> 1.
>
> The reputation management happens locally, that is, the only protocol
> change needed is the ability to signal endorsement as a TLV in
> UpdateAddHTLC. The various parameters can be selected for various risk
> preferences.
> 2.
>
> We currently suggest a binary reputation for simplicity. Having
> several buckets could be interesting to study, yet we don’t think that the
> complexity and the possible privacy issues are worth the potential benefits.
> 3.
>
> For most use cases, having reputation 0 is more than enough. If we
> send and receive transactions at a low rate, we usually don’t need the full
> liquidity and slots available in a channel. Reputation mostly comes into
> play only when a channel is under attack, and then not all transaction are
> allowed to go through.
> 4.
>
> Following this thread [3]: it is important to note that we are only
> giving reputation to our direct neighbours. An advantage of this is that we
> have repeated interactions with them. In practice, this is also the only
> clean data we have to use when deciding whether to forward an HTLC or not.
>
>
> Best,
>
> Carla and Clara
>
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
> [2]
> https://github.com/lightningnetwork/lnd/blob/de94a4ea5e81799330a72dfde111817b38565d99/htlcswitch/link.go#L51
> [3]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003842.html
> _______________________________________________
> 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/20230306/d19448db/attachment-0001.html>;