Thomas HUET [ARCHIVE] on Nostr: đź“… Original date posted:2023-03-02 đź“ť Original message: To give a very simple ...
đź“… Original date posted:2023-03-02
đź“ť Original message:
To give a very simple example, imagine a node that sends the same
confidence c for all HTLCs. We want c to be equal to the probability p that
its HTLCs succeed.
- If c = p then all is well and we give a reputation of 1 to the node.
- If c > p then this node is overconfident or is lying to have its HTLCs
relayed, in both cases we should lower its reputation to account for that.
- If c < p then yes it gives it a higher reputation but the reputation is
capped at 1 anyway, so by underestimating the confidence the node doesn't
gain anything.
Ideally we want all honest nodes to have a reputation of 1. It doesn't mean
that all their HTLCs succeed, it just means that they provide reliable
estimates of the success probability of the HTLCs.
Le jeu. 2 mars 2023 Ă 19:57, Clara Shikhelman <clara.shikhelman at gmail.com>
a Ă©crit :
> 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/f66062bc/attachment-0001.html>;
đź“ť Original message:
To give a very simple example, imagine a node that sends the same
confidence c for all HTLCs. We want c to be equal to the probability p that
its HTLCs succeed.
- If c = p then all is well and we give a reputation of 1 to the node.
- If c > p then this node is overconfident or is lying to have its HTLCs
relayed, in both cases we should lower its reputation to account for that.
- If c < p then yes it gives it a higher reputation but the reputation is
capped at 1 anyway, so by underestimating the confidence the node doesn't
gain anything.
Ideally we want all honest nodes to have a reputation of 1. It doesn't mean
that all their HTLCs succeed, it just means that they provide reliable
estimates of the success probability of the HTLCs.
Le jeu. 2 mars 2023 Ă 19:57, Clara Shikhelman <clara.shikhelman at gmail.com>
a Ă©crit :
> 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/f66062bc/attachment-0001.html>;