Clara Shikhelman [ARCHIVE] on Nostr: 📅 Original date posted:2023-03-02 🗒️ Summary of this message: Thomas suggests ...
đź“… Original date posted:2023-03-02
🗒️ Summary of this message: Thomas suggests that local reputation is more important than upfront fees in preventing slow jamming attacks. He proposes a formula for continuous reputation scores and suggests using more than one bit for confidence values.
đź“ť Original message:
Hi Thomas,
I really like the idea of taking into consideration the failures. In our
proposal, a failure won't benefit your reputation, as the neighbour is
trying to reach a fee threshold, but taking it into account instead of
ignoring it could be helpful against an adversary trying to manipulate
parameters.
Could you elaborate a bit about "*c, the confidence given by the previous
node.*" It looks from the formula (that has *1/c* component) that the lower
the confidence, the higher the reputation, and I am not sure that this is
the goal. Some numerical examples could help clarify the dynamics you are
aiming for.
Do you have some estimation of what kind of protection or compensation this
method offers?
Best,
Clara
On Thu, Mar 2, 2023 at 8:14 AM Thomas HUET <thomas.huet at acinq.fr> wrote:
> Hello,
>
> I think the local reputation is more important than upfront fees and
> should be worked on first because 1) the most likely attack against the
> network today is the slow jamming attack against which upfront fees are not
> very effective (an attacker would only consider fast jamming if the network
> is already resilient to slow jamming) and 2) I think that local reputation
> may protect well enough against all types of jamming so that we don't even
> need upfront fees to protect against fast jamming.
> Regarding the formula itself, I would treat all scores as continuous
> values between 0 and 1 instead of binary classes. My proposed formula is
> detailed here:
>
> https://docs.google.com/document/d/1hEt1EzyPFJ3gOY7PAvtm_XotTnlQO2r7LSF8Jx34qgc/edit?usp=sharing
> However my proposal is compatible with Clara's one in that the only thing
> that needs to be communicated to the peers is how confident we are that the
> payment will succeed and all the rest is done locally and everyone can use
> their own formula. I would just prefer this confidence value to be more
> than one bit but my formula would work with anything, even zero bits. The
> advantage of using more bits is that we can be more precise in which HTLCs
> we reject and reduce the number of innocent casualties.
>
> Thomas
>
> Le jeu. 16 févr. 2023 à 22: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/20230302/a33c0a42/attachment-0001.html>;
🗒️ Summary of this message: Thomas suggests that local reputation is more important than upfront fees in preventing slow jamming attacks. He proposes a formula for continuous reputation scores and suggests using more than one bit for confidence values.
đź“ť Original message:
Hi Thomas,
I really like the idea of taking into consideration the failures. In our
proposal, a failure won't benefit your reputation, as the neighbour is
trying to reach a fee threshold, but taking it into account instead of
ignoring it could be helpful against an adversary trying to manipulate
parameters.
Could you elaborate a bit about "*c, the confidence given by the previous
node.*" It looks from the formula (that has *1/c* component) that the lower
the confidence, the higher the reputation, and I am not sure that this is
the goal. Some numerical examples could help clarify the dynamics you are
aiming for.
Do you have some estimation of what kind of protection or compensation this
method offers?
Best,
Clara
On Thu, Mar 2, 2023 at 8:14 AM Thomas HUET <thomas.huet at acinq.fr> wrote:
> Hello,
>
> I think the local reputation is more important than upfront fees and
> should be worked on first because 1) the most likely attack against the
> network today is the slow jamming attack against which upfront fees are not
> very effective (an attacker would only consider fast jamming if the network
> is already resilient to slow jamming) and 2) I think that local reputation
> may protect well enough against all types of jamming so that we don't even
> need upfront fees to protect against fast jamming.
> Regarding the formula itself, I would treat all scores as continuous
> values between 0 and 1 instead of binary classes. My proposed formula is
> detailed here:
>
> https://docs.google.com/document/d/1hEt1EzyPFJ3gOY7PAvtm_XotTnlQO2r7LSF8Jx34qgc/edit?usp=sharing
> However my proposal is compatible with Clara's one in that the only thing
> that needs to be communicated to the peers is how confident we are that the
> payment will succeed and all the rest is done locally and everyone can use
> their own formula. I would just prefer this confidence value to be more
> than one bit but my formula would work with anything, even zero bits. The
> advantage of using more bits is that we can be more precise in which HTLCs
> we reject and reduce the number of innocent casualties.
>
> Thomas
>
> Le jeu. 16 févr. 2023 à 22: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/20230302/a33c0a42/attachment-0001.html>;