Thomas HUET [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2022-07-01 to 2023-03-03
💬 Posted a total of 7 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:12:50

- reply

📅 Original date posted:2023-03-03
🗒️ Summary of this message: Giving high confidence to HTLCs increases the chance of relaying, while having a high reputation is just a means to that end. Reporting confidence 0 may lead to a reputation of 1, but HTLCs may still be rejected during congestion.
📝 Original message:
By giving a high confidence to HTLCs you increase the chance that they are
relayed which should be your goal. Having a high reputation is not a goal
in itself, it's just a way to make your HTLCs more likely to be relayed. If
you always report confidence 0, then yes you will have a reputation of 1
but your HTLCs will still be rejected at the first sign of congestion.
Le ven. 3 mars 2023 à 17:14, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :
> Hi Thomas,
>
> Thanks for the example.
>
> - 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.
>>
> Is there anything to gain from giving high confidence? By doing this, you
> risk lowering your reputation, and it's not clear what you gain.
> Could it be that the best selfish strategy is to report confidence 0 (that
> maps to reputation 1) all the time?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230303/bc05d231/attachment.html>

2023-06-09 13:12:50

- reply

📅 Original date posted:2023-03-03
🗒️ Summary of this message: Continuous solutions allow for more precise blocking of attackers and low-reputation nodes. Reporting c truthfully is important to maintain reputation.
📝 Original message:
The benefit is that you can be more precise when blocking. With a binary
solution a single attacker can easily fill your quota of low-confidence
HTLCs and then all low-reputation nodes are blocked. But not all of them
are attackers, some of them just don't send you enough traffic to get a
high reputation for instance and you're going to block them too. With a
continuous solution you can differentiate between an active attacker and
someone who just sends to nodes with poor connectivity and only block the
first.
For reporting c truthfully, if you report it too high you will be penalized
by having your reputation lowered, if you report it too low you will
penalize your HTLCs and still get the same reputation as if you had
reported it truthfully.
Le ven. 3 mars 2023 à 19:45, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :
> Could you explain the benefits of continuous solutions over binary? This
> is something we should definitely understand before going in a more
> complicated direction.
>
> Also, I'm still not sure that the rational behaviour is to report *c*
> truthfully.
>
>
>
> On Fri, Mar 3, 2023 at 11:51 AM Thomas HUET <thomas.huet at acinq.fr> wrote:
>
>> By giving a high confidence to HTLCs you increase the chance that they
>> are relayed which should be your goal. Having a high reputation is not a
>> goal in itself, it's just a way to make your HTLCs more likely to be
>> relayed. If you always report confidence 0, then yes you will have a
>> reputation of 1 but your HTLCs will still be rejected at the first sign of
>> congestion.
>>
>> Le ven. 3 mars 2023 à 17:14, Clara Shikhelman <clara.shikhelman at gmail.com>
>> a écrit :
>>
>>> Hi Thomas,
>>>
>>> Thanks for the example.
>>>
>>> - 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.
>>>>
>>> Is there anything to gain from giving high confidence? By doing this,
>>> you risk lowering your reputation, and it's not clear what you gain.
>>> Could it be that the best selfish strategy is to report confidence 0
>>> (that maps to reputation 1) all the time?
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230303/d15bb113/attachment-0001.html>

2023-06-09 13:12:49

- reply

📅 Original date posted:2023-03-02
🗒️ Summary of this message: A proposed formula for local reputation in Lightning Network considers the confidence given by the previous node, with honest nodes having a reputation of 1.
📝 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>

2023-06-09 13:12:48

- reply

📅 Original date posted:2023-03-02
🗒️ Summary of this message: A proposed jamming mitigation strategy suggests prioritizing local reputation over upfront fees to protect against slow jamming attacks. A continuous value formula is proposed.
📝 Original message:
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/47bf0566/attachment-0001.html>

2023-06-09 13:08:17

- reply

📅 Original date posted:2023-03-03
📝 Original message:
By giving a high confidence to HTLCs you increase the chance that they are
relayed which should be your goal. Having a high reputation is not a goal
in itself, it's just a way to make your HTLCs more likely to be relayed. If
you always report confidence 0, then yes you will have a reputation of 1
but your HTLCs will still be rejected at the first sign of congestion.
Le ven. 3 mars 2023 à 17:14, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :
> Hi Thomas,
>
> Thanks for the example.
>
> - 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.
>>
> Is there anything to gain from giving high confidence? By doing this, you
> risk lowering your reputation, and it's not clear what you gain.
> Could it be that the best selfish strategy is to report confidence 0 (that
> maps to reputation 1) all the time?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230303/bc05d231/attachment.html>

2023-06-09 13:08:17

- reply

📅 Original date posted:2023-03-03
📝 Original message:
The benefit is that you can be more precise when blocking. With a binary
solution a single attacker can easily fill your quota of low-confidence
HTLCs and then all low-reputation nodes are blocked. But not all of them
are attackers, some of them just don't send you enough traffic to get a
high reputation for instance and you're going to block them too. With a
continuous solution you can differentiate between an active attacker and
someone who just sends to nodes with poor connectivity and only block the
first.
For reporting c truthfully, if you report it too high you will be penalized
by having your reputation lowered, if you report it too low you will
penalize your HTLCs and still get the same reputation as if you had
reported it truthfully.
Le ven. 3 mars 2023 à 19:45, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :
> Could you explain the benefits of continuous solutions over binary? This
> is something we should definitely understand before going in a more
> complicated direction.
>
> Also, I'm still not sure that the rational behaviour is to report *c*
> truthfully.
>
>
>
> On Fri, Mar 3, 2023 at 11:51 AM Thomas HUET <thomas.huet at acinq.fr> wrote:
>
>> By giving a high confidence to HTLCs you increase the chance that they
>> are relayed which should be your goal. Having a high reputation is not a
>> goal in itself, it's just a way to make your HTLCs more likely to be
>> relayed. If you always report confidence 0, then yes you will have a
>> reputation of 1 but your HTLCs will still be rejected at the first sign of
>> congestion.
>>
>> Le ven. 3 mars 2023 à 17:14, Clara Shikhelman <clara.shikhelman at gmail.com>
>> a écrit :
>>
>>> Hi Thomas,
>>>
>>> Thanks for the example.
>>>
>>> - 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.
>>>>
>>> Is there anything to gain from giving high confidence? By doing this,
>>> you risk lowering your reputation, and it's not clear what you gain.
>>> Could it be that the best selfish strategy is to report confidence 0
>>> (that maps to reputation 1) all the time?
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230303/d15bb113/attachment-0001.html>

2023-06-09 13:08:16

- reply

📅 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>

2023-06-09 13:08:15

- reply

📅 Original date posted:2023-03-02
📝 Original message:
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/47bf0566/attachment-0001.html>

2023-06-09 13:07:18

- reply

📅 Original date posted:2022-11-08
📝 Original message:
Hi,
I agree that the local reputation solution is very promising (I'm less
convinced about the unconditional fee as it changes a core principle of the
network which means that we'll never reach consensus on it). What I really
like about it is that it's quite simple and can be quickly deployed without
even needing to coordinate with others or upgrade the network.
I had a similar idea but your solution adds a "I endorse this payment" bit
which I think can make the method a lot more effective (and unfortunately
breaks the "can be deployed without upgrading the network" but I think it's
worth it). However if we change the protocol, we may as well make it a
continuous risk score instead of a binary low/high-risk. Also, having only
two classes (high and low-risk) protects the the low-risk class but makes
the high-risk class even easier to attack, having a continuous policy
should mitigate this problem.
And while I agree with the general idea of throttling based on a local
reputation, I think we need more work to find a good formula to compute
this reputation. I don't have a good formula myself but relying on "A
satoshis per second" doesn't seem wise. There are huge disparities between
nodes and even for a given node, traffic is fluctuating a lot. I think a
more reliable indicator would be the proportion of successful payments.
The beauty of this solution is that we don't need a standardized formula
for reputation, everyone can use its own. However getting a good one is
hard so we need a default recommandation.
Thanks for your work.
Thomas
Le lun. 7 nov. 2022 à 19:23, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :
> Hi Antoine,
>
> Thank you for the detailed response!
>
>
>
>> On the framework for mitigation evaluation, there are few other
>> dimensions we have considered in the past with Gleb for our research that
>> could be relevant to integrate. One is "centralization", the solution
>> shouldn't centralize sensibly the LN ecosystem around any of its actors:
>> LSP, Lightning Wallet Providers (e.g watchtower or Greenlight-style infra)
>> or routing node, where centralization could be defined in terms of "market
>> entry cost" for new incumbents. "Protocol evolvability" could be another
>> one, as we don't want a solution rendering the design and operations of
>> things like offline-receive, trampoline, negative fees, etc harder.
>> "Ecosystem impacts" was one more category we thought about, e.g introducing
>> a mass mempool congestion vector (one of the versions of Stakes
>> Certificates did it...).
>>
>
> These are indeed important dimensions. I think that our solution gets
> “good marks” in all of them, but this should definitely be stated
> explicitly in the future.
>
>
>> For the dimensions of your evaluation framework, the "effectiveness"
>> sounds to be understood as attacker-centric. However few times after in the
>> paper, the viewpoint of the routing nodes sounds to be adopted
>> ("compensating them for the financial damage of jamming", "breakeven point
>> n"). If this distinction is real, the first way would be more searching for
>> a game-theory equilibrium whereas much damage is inflicted to the attacker.
>> The second one would be more to ensure a compensation for the loss income
>> for the routing nodes. I believe the first approach is limited as the
>> attacker's resources could overwhelm the victim's economic sustainability,
>> and rationality might be uneconomic. Maybe those two approaches could be
>> combined, in the sense that loss income compensation should only be borne
>> by "identified" attackers, however this doesn't sound the direction taken
>> by unconditional fees.
>>
>
> The effectiveness evaluation does have a few facets. From the attacker's
> viewpoint, it might be that mitigation makes the attack impossible,
> difficult, or expensive. From the victim's point of view, we can talk about
> protection, compensation, or any combination of the two. Of course, the
> best outcome is when the attack is impossible. As this is oftentimes not
> something we can do, we have to choose one of the other outcomes.
>
>
>> About "incentive compatibility", one element valuable to integrate is how
>> much the existence of scoring algorithms allows the routing nodes to adopt
>> "honest behaviors" and high-level of service availability. I don't know if
>> a jamming solution can be devised without considerations of the inner
>> workings of routing/scoring algorithms, and so far every LN implementation
>> has its own cooking.
>>
>
> We focused on the most basic incentive of not failing transactions that
> could have been forwarded. I'll be happy to discuss other potential
> pitfalls if you have something in mind.
>
>
>>
>> On the structure of the monetary strategy, I think there could be a
>> solution to implement a proof-of-burn, where the fee is captured in a
>> commitment output sending to a provably unspendable output. Theoretically,
>> it's interesting as "unburning" the fee is dependent on counterparty
>> cooperation, the one potentially encumbering the jamming risk.
>> Proof-of-work "fee" has been discussed in the past by LN devs, however it
>> was quickly dismissed, as it would give an edge to the attacker who is able
>> to gather ASICs farms while completely burning the batteries of LN mobile
>> clients. It has also been widely discussed to make the fees conditional on
>> either outgoing HTLC CLTV value or effective duration. For effective
>> duration, an upfront fee shard could be paid after each clock tick (either
>> epoch or block-based).
>>
>
> The main problem with proof of burn or PoW is that it does not compensate
> the victim, we write this explicitly in the newer version of the paper.
> Thanks for this comment, we will add further details on previous
> discussions.
>
>
>> On the structure of reputation strategy, I think one interesting missing
>> point to me is the blurring of the local/global reputation definition in
>> Lightning. At least maybe in a way traditionally defined in P2P
>> litterature. Reputation could be enforced on the HTLC sender, as we've
>> aimed with Stakes Certificates. The upstream peer reputation is not
>> accounted for at all. I think it's an open question if the reputation score
>> of a routing node could be exported across nodes (a behavior that one could
>> expect if you assume web-of-trust, as the current LN network topology is
>> heavily based on). On the statement, that attaching reputation to payment
>> contradicts the LN's privacy-focused goal, I would say it's a light one in
>> regards to the state of cryptography tools like blinded signature, known
>> since the 80s.
>>
>
> I think that further research on assigning the blame to the sender is of
> interest, but as we don't have this right now, it would be good to work
> with the available tools.
>
>
>> On the analysis of the unconditional fee, I think my main objection would
>> be the lack of integration of the time uncertainty of the honest use-cases,
>> making it hard to classify between quick and slow jamming. As you say "The
>> borderline between quick and slow jamming depends on a subjective
>> definition of the maximal honest payment resolution delay" An attacker
>> should hold all its HTLC jamming for a duration of "maximal honest payment
>> resolution delay" minus 1. Without even scoping L2s protocol like swaps or
>> hold-invoice where the effective duration might hold for a few blocks,
>> modern flows like offline receive where the user has to take manual actions
>> to settle the HTLC could far extend beyond a few seconds. To develop my
>> point, fair compensation could aim for the most optimistic flow of
>> short-held 0.1s payment, however a routing policy could qualify as honest
>> payment resolution delay duration of as much as a few minutes. This
>> discrepancy could be exploited by an attacker to inflict an asymmetric
>> damage to the routing nodes. Of course, one fix could be to scale up the
>> unconditional fee amount in function of the maximal honest payment
>> resolution delay accepted by the routing node policy". I wonder if it would
>> be suitable in terms of UX.
>>
>
> For special use cases, where Alice and Bob agree that HTLCs can wait for a
> long time over the channel, they can agree that this would not change their
> reputation with the other party. If Alice decides to knowingly forward to
> Bob an HTLC that will not resolve quickly, without agreeing on this
> beforehand, this is a problem and should be solved through the reputation
> system.
>
>
>> For a routing node, there is the uncertainty of downstream payment path
>> hops, responsible for some failures, I don't know if it's currently
>> accounted for in the evaluation of the unconditional fee. If the
>> unconditional fee paid downstream is too high, there is a moral hazard for
>> the routing node, they can pocket the fee, depending how much they're
>> penalized by the sender scoring algorithm.
>>
>
> This is addressed in inequality 5 in the paper.
> In general, routing algorithms should avoid nodes and channels that
> regularly fail their payments. This is true beyond the scope of upfront
> fees, and as the upfront fees are rather low, this wouldn't be the main
> motivation for avoiding “bad” nodes.
>
>
>
>> On the analysis of the reputation mechanism, there is one recursive
>> issue: you might constrain the incoming HTLC traffic of your peers, even if
>> they're all honest. Let's say you assign K slots and L satoshis of
>> liquidity to your upstream peer Carioll, Caroll must know divide by (K, L)
>> by two to Alice and Bob, even if Alice and Bob each can offer (K, L) of
>> honest HTLC traffic.
>>
>
> Are we the only node sending anything to Carol? If this is the case, our
> channel is Carol's bottleneck, and indeed whichever limit we choose will be
> the limit she will have to handle (this is a bit of "min-cut max-flow"
> problem for Carol, where our channel is her min-cut)
>
>
>> Further, there is also the attack timing asymmetries, in the sense that a
>> high-reputation score might have been earned in period of low-congestion,
>> and consumed during period of high-congestion, so it sounds to me
>> reputation should be quantitative rather to introduce a low-risk/high-risk
>> binary framework, to account for proportionality. This proportionality
>> issue is a hard thing, especially if I would like concretely to address
>> payments with intentionally delayed resolutions in a non-cooperative-only
>> way.
>>
>
> As reputation policy is determined on the level of an individual node, it
> could be that some will choose to take into account congestion.
>
>
>> Lastly, I wonder if there is not some conceptual issue with the chaining
>> of unconditional fee and local reputation. As I understand the distinction
>> between quick/slow jamming is based on this idea of maximal honest payment
>> resolution delay. However, the bypass of this upper bound is only known
>> _after_ the HTLC forward, and as such it sounds to me the strategie regime
>> (unconditional fee/local reputation) under which a HTLC forward should be
>> evaluated is dependent on the knowledge of a future event.
>>
>
> We use reputation as part of a continuous game. You don't gain or lose
> high reputation based on one HTLC, you evaluate based on the continuous
> behavior of the node. The unconditional fee is always charged.
>
>
> Thanks again,
> Clara
> _______________________________________________
> 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/20221108/dc506636/attachment-0001.html>

2023-06-09 13:07:11

- reply

📅 Original date posted:2022-11-03
📝 Original message:
Hi Joost,
This is a very interesting proposal that elegantly solves the problem, with
however a very significant size increase. I can see two ways to keep the
size small:
- Each node just adds its hmac in a naive way, without deleting any part of
the message to relay. You seem to have disqualified this option because it
increases the size of the relayed message but I think it merits more
consideration. It is much simpler and the size only grows linearly with the
length of the route. An intermediate node could try to infer its position
relative to the failing node (which should not be the recipient) but
without knowing the original message size (which can easily be randomized
by the final node), is that really such a problem? It may be but I would
argue it's a good trade-off.
- If we really want to keep the constant size property, as you've suggested
we could use a low limit on the number of nodes. I would put the limit even
lower, at 8 or less. We could still use longer routes but we would only get
hmacs for the first 8 hops and revert to the legacy system if the failure
happens after the first 8 hops. That way we keep the size low and 8 hops
should be good enough for 99% of the payments, and even when there are more
hops we would know that the first 7 hops are clean.
Thanks again for your contribution, I hope we'll soon be able to attribute
failures trustlessly.
Thomas
Le mar. 1 nov. 2022 à 22:10, Joost Jager <joost.jager at gmail.com> a écrit :
> Hey Rusty,
>
> Great to hear that you want to try to implement the proposal. I can polish
> my golang proof of concept code a bit and share if that's useful? It's just
> doing the calculation in isolation. My next step after that would be to see
> what it looks like integrated in lnd.
>
> 16 hops sounds fine to me too, but in general I am not too concerned about
> the size of the message. Maybe a scheme is possible where the sender
> signals the max number of hops, trading off size against privacy. Probably
> an unnecessary complication though.
>
> I remember the prepay scheme, but sounds quite a bit more invasive than
> just touching encode/relay/decode of the failure message. You also won't
> have the timing information to identify slow nodes on the path.
>
> Joost.
>
> On Tue, Oct 25, 2022 at 9:58 PM Rusty Russell <rusty at rustcorp.com.au>
> wrote:
>
>> Joost Jager <joost.jager at gmail.com> writes:
>> > Hi list,
>> >
>> > I wanted to get back to a long-standing issue in Lightning: gaps in
>> error
>> > attribution. I've posted about this before back in 2019 [1].
>>
>> Hi Joost!
>>
>> Thanks for writing this up fully. Core lightning also doesn't
>> penalize properly, because of the attribution problem: solving this lets
>> us penalize a channel, at least.
>>
>> I want to implement this too, to make sure I understand it
>> correctly, but having read it twice it seems reasonable.
>>
>> How about 16 hops? It's the closest power of 2 to the legacy hop
>> limit, and makes this 4.5k for payloads and hmacs.
>>
>> There is, however, a completely different possibility if we want
>> to use a pre-pay scheme, which I think I've described previously. You
>> send N sats and a secp point; every chained secret returned earns the
>> forwarder 1 sat[1]. The answers of course are placed in each layer of
>> the onion. You know how far the onion got based on how much money you
>> got back on failure[2], though the error message may be corrupted.
>>
>> Cheers,
>> Rusty.
>> [1] Simplest is truncate the point to a new secret key. Each node would
>> apply a tweak for decorrelation ofc.
>> [2] The best scheme is that you don't get paid unless the next node
>> decrypts, actually, but that needs more thought.
>>
> _______________________________________________
> 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/20221103/ddb54b9c/attachment.html>

2023-06-09 13:06:32

- reply

📅 Original date posted:2022-07-01
📝 Original message:
Hi Joost,
It was discussed in this issue:
https://github.com/lightning/bolts/issues/835
On the network, the traffic is not balanced. Some nodes tend to receive
more than they send, merchants for instance. For the lightning network to
be reliable, we need to incentivise people to open channels to such nodes,
or else there won't be enough liquidity available and payments will fail.
The current fee structure provides this incentive: You pay some onchain
fees and lock some funds and in exchange you will earn routing fees. My
concern is that your proposed change would break that incentive and make
the network less reliable.
Thomas
Le ven. 1 juil. 2022 à 14:02, Joost Jager <joost.jager at gmail.com> a écrit :
> Hi Bastien,
>
> I vaguely remembered that the idea of inbound fees had been discussed
> before. Before writing my post, I scanned through old ML posts and bolts
> issues but couldn't find the discussion. Maybe it was part of a different
> but related email or a bolts pr?
>
> With regards to your objections, isn't it the case that it is always
> possible to DoS your peer by just rejecting any forward that comes in from
> them? Or indirectly affecting them negatively by setting high fees on all
> outbound channels? To me it seems that there is nothing to lose by adding
> inbound fees.
>
> My thinking is that if I accept an incoming htlc, my local balance
> increases on that incoming channel. My money gets locked up in a channel
> that may or may not be interesting to me. Wouldn't it be fair to be
> compensated for that?
>
> Any thoughts from routing node operators would be welcome too (or links to
> previous threads).
>
> Joost
>
> On Fri, Jul 1, 2022 at 1:19 PM Bastien TEINTURIER <bastien at acinq.fr>
> wrote:
>
>> Hi Joost,
>>
>> As I've already stated every time this has been previously discussed, I
>> believe
>> this doesn't make any sense. The funds that are on the other side of the
>> channel belong to your peer, not you, so they're free to use it however
>> they
>> want. If you're not happy with the way your peer is managing their fees,
>> then
>> don't open channels to them and let the network decide whether you're
>> right or
>> not.
>>
>> Moreover, you shouldn't care at all. If all the funds are on your peer's
>> side,
>> this isn't your problem, you used up all the money that was yours. As
>> long as
>> the channel is open, this is free inbound liquidity for you, so you're
>> even
>> benefiting from this.
>>
>> If Alice could set fees for Bob's side of the channel, Alice could
>> arbitrarily
>> DoS Bob's payments by setting a high fee. This is just one example of the
>> many
>> ways this idea completely breaks the routing incentives.
>>
>> Cheers,
>> Bastien
>>
>> Le ven. 1 juil. 2022 à 13:10, Joost Jager <joost.jager at gmail.com> a
>> écrit :
>>
>>> Path-finding algorithms that are currently in use generally don’t
>>>> support negative fees. But in this case, the sum of inbound and outbound
>>>> fees is still positive and therefore not a problem. If routing nodes set
>>>> their policies accidentally or intentionally so that the sum of fees turns
>>>> out negative, senders can just round up to zero and find a path as normal.
>>>>
>>>
>>> Correction to this:
>>>
>>> The sum of inbound and outbound are not the fees set by one single
>>> routing node. When path-finding considers a candidate hop, this adds the
>>> outbound fee of the "from" node and the inbound fee of the "to" node.
>>> Because those nodes don't necessarily coordinate fees, it may happen more
>>> often that the fee goes negative. Rounding up to zero is still a quick fix
>>> and better than ignoring inbound fees completely.
>>> _______________________________________________
>>> 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/20220701/3c0f507d/attachment.html>