<unnamed>

Public Key

npub1tcwr7j30p5q4sypnsw4arca9s2433s7wdcpt2z2sk7pkqfsntjds0pu5xp

Profile Code

nprofile1qqs9u8plfghs6q2czqec8273uwjc92ccc08xuq44p9gt0qmqycf4excpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsrhfwev

Publishing to

nostr.wine

nos.lol

relay.damus.io

Last Notes

2023-07-30 22:54:54 UTC

- reply

📅 Original date posted:2023-07-28
🗒️ Summary of this message: The motivation for multipath keysend is to allow for splitting payments into multiple parts, ensuring the receiver can only claim the payment once all parts have arrived. This adds complexity to keysend, but may be useful for certain use cases.
📝 Original message:
What is the motivation for multipath keysend? Why not just make
several independent keysend payments with different payment hashes?
We should make sure that there is a user need before adding complexity
to keysend, especially since we're already working on BOLT 12 which
supports multipath and even provides a proof of payment.
Le ven. 28 juil. 2023 à 09:24, ZmnSCPxj via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> a écrit :
>
> Good morning list,
>
> I would like to share a simple scheme for creating a `keysend` protocol that allows for multipath payments.
>
> In `keysend`, the preimage is embedded as TLV 5482373484 with length 32.
>
> In the multipath case, we want the receiver to only be able to claim the payment once all parts have arrived at the receiver.
>
> For example, suppose we want to split the `keysend` into 2 parts.
> Let us select a true preimage `p` at random.
> Then, we generate the payment hash `h = SHA256(p)`.
>
> Then, we generate a new 256-bit scalar, `a`.
> For one part, we send `a` for TLV 5482373484, and for the second part, we send `a ^ p`, where `^` is XOR.
> All parts use the same payment hash `h`.
>
> The receiver, on receiving either part, will find that the supposed preimage does not match the actual HTLC payment hashes.
> Instead of failing, it holds the payment, using the usual basic multipath payment rules.
>
> When the receiver receives another part, it will XOR together the supposed preimages.
> In the above case, it would get `a` and `a ^ p`, which when XORed together result in `a ^ a ^ p` or `p`, which is now the correct preimage, and the receiver can now claim the entire complete funds.
>
> The same technique would work with any number of parts --- if we split into `n` parts, we generate `n - 1` additional random scalars and use it for the first `n - 1` parts, then XOR all of them with the scalar-to-be-split for the `n`th part.
> This scheme also works for dynamic splitting, i.e. if you are splitting a part that was already split off from a part that was already split off from a part etc.
>
> A sender can detect if the receiver does not support multipath `keysend` if a part reaches the receiver and it errors with `incorrect_or_unknown_payment_details`.
> If the receiver is aware of multipath `keysend`, it would hold onto the incoming HTLCs until MPP timeout, and instead error with `mpp_timeout`.
> Thus, support for this on the receiver side does not need to be specially announced via a new feature bit --- an MPP-capable sender can simply try to split, and if it gets an `incorrect_or_unknown_payment_details`, knows that the receiver does not support multipath `keysend`.
> The same feature bit 55 can be reused.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 13:12:50 UTC

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

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

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

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

- 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:17 UTC

- 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:16 UTC

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

- 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:06:32 UTC

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