Clara Shikhelman [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-16 📝 Original message: Hi List, We’re writing ...
đź“… Original date posted:2023-02-16
đź“ť Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230216/e3574a61/attachment-0001.html>;
đź“ť Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230216/e3574a61/attachment-0001.html>;