<unnamed>

Public Key

npub1uyhgpz5nsfnvdlcqm3erjsdjasd9pdeaejeetwtkvumm6mp3ujlqxt9vwk

Profile Code

nprofile1qqswzt5q32fcyekxluqdcu3egxewcxjsku7uevu4h9mxwdaadsc7f0spz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dslt4z9w

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-08-02 22:15:36 UTC

- reply

📅 Original date posted:2023-07-31
🗒️ Summary of this message: A different approach to dealing with attacks on the network is to scale up capacity and make attackers pay for the resources they use, turning them into a profit center. This could be done through fees for message spam and holding funds. However, there are challenges in implementing fees based on the time an HTLC is held. The suggested fees are low, so hourly precision should be sufficient.
📝 Original message:
Hi AJ,
A different way of thinking about the monetary approach is in terms of
> scaling rather than deterrance: that is, try to make the cost that the
> attacker pays sufficient to scale up your node/the network so that you
> continue to have excess capacity to serve regular users.
>
> In that case, if people are suddenly routing their netflix data and
> nostr photo libraries over lightning onion packets, that's fine: you
> make them pay amazon ec2 prices plus 50% for the resources they use,
> and when they do , you deploy more servers. ie, turn your attackers and
> spammers into a profit centre.
>
> I've had an email about this sitting in my drafts for a few years now,
> but I think this could work something like:
>
> - message spam (ie, onion traffic costs): when you send a message
> to a peer, pay for its bandwidth and compute. Perhaps something
> like 20c/GB is reasonable, which is something like 1msat per onion
> packet, so perhaps 20msat per onion packet if you're forwarding it
> over 20 hops.
>
> - liquidity DoS prevention: if you're in receipt of a HTLC/PTLC and
> aren't cancelling or confirming it, you pay your peer a fee for
> holding their funds. (if you're forwarding the HTLC, then whoever you
> forwarded to pays you a slightly higher fee, while they hold your
> funds) Something like 1ppm per hour matches a 1% pa return, so if
> you're an LSP holding on to a $20 payment waiting for the recipient to
> come online and claim it, then you might be paying out $0.0004 per hour
> (1.4sat) in order for 20 intermediate hops to each be making 20%
> pa interest on their held up funds.
>
> - actual payment incentives: eg, a $20 payment paying 0.05% fees
> (phoenix's minimum) costs $0.01 (33sat). Obviously you want this
> number to be a lot higher than all the DoS prevention fees.
>
> If you get too much message spam, you fire up more amazon compute
> and take maybe 10c/GB in profit; if all your liquidity gets used up,
> congrats you've just gotten 20%+ APY on your bitcoin without third party
> risk and you can either reinvest your profits or increase your fees; and
> all of those numbers are just noise compared to actual payment traffic,
> which is 30x or 1500x more profitable.
>
Message spam is outside the scope of this solution.
As for liquidity DoS, the “holy grail” is indeed charging fees as a
function of the time the HTLC was held. As for now, we are not aware of a
reasonable way to do this. There is no universal clock, and there is no way
for me to prove that a message was sent to you, and you decided to pretend
you didn't. It can easily happen that the fee for a two-week unresolved
HTLC is higher than the fee for a quickly resolving one. Because of this,
we turn to reputation for slow jamming and use fees only for quick jamming.
See later comments on the specific suggestion outlined.
The amounts here are all very low, so I don't think you really need much
> more precision than "hourly". I think you could even do it "per block"
> and convert "1% pa" as actually "0.2 parts per million per block", since
> the only thing time is relevant for is turning liquidity DoS into an APY
> figure. Presumably that needs some tweaking to deal with the possibility
> of reorgs or stale blocks.
>
This is again the same problem with a node preferring the fees for a
two-week unresolved HTLC over a quick resolving one. See comments below for
the far downstream node.
I think the worst case for that scenario is if you have a route
>
> A1 -> A2 -> .. -> A19 -> B -> A20
>
> then B closes the {B,A20} channel and at the end of the timeout A20 claims
> the funds. At that point B will have paid liquidity fees to A1..A19 for
> the full two week period, but will have only received a fixed payout
> from A20 due to the channel close.
>
> At 10% APY, with a $1000 payment, B will have paid ~$73 to A (7.3%). If
> the close channel transaction costs, say, $5, then either you end up with
> B wanting to close the channel early in non-attack scenarios (they collect
> $73 from A20, but only pay perhaps 4c back to A1..A19, and perhaps $6 to
> open and close the channel), or you end up with A holding up the funds
> and leaching off B (B only collects, say, $20 from A20, but then A20
> claims the funds after two weeks so is either up $75 if B didn't claim
> the funds from A19, or is up $53 after B paid liquidity fees for 2 weeks).
>
> _But_ I think this is an unreasonable scenario: the only reason for B to
> forward a HTLC with a 2 week expiry is if they're early in the route,
> but the only reason to accept a large liquidity fee is if they're late
> in the route. So I think you can solve that by only forwarding a payment
> if the liquidity fee rate multiplied by the expiry is below a cap, eg:
>
> A19 -> B : wants 36ppm per block; cap/ppm = 500/36 = 13.8
> B -> A20 : expiry is in 13 blocks; wants 38ppm per block
>
> (2ppm per block ~= 10% APY)
>
> For comparison, at the start of the chain, things look like:
>
> A2 -> A3 : wants 2ppm per block; cap/ppm = 500/2 = 250
> A3 -> A4 : expiry is in 250 blocks; wants 4ppm per block
>
> In each case, the commitment tx would look like:
>
> $1000 HTLC paying Y refunding to X
> $0.50 liquidity fee bonus to X's balance (500ppm cap)
>
I think this is another take on time-based fees. In this variation, the
victim is trying to take a fee from the attacker. If the attacker is not
willing to pay the fee (and why would they?), then the victim has to force
close. There is no way for the victim to prove that it is someone
downstream holding the HTLC and not them.
> > - They’re not large enough to be enforceable, so somebody always has
> > to give the money back off chain.
>
> If the cap is 500ppm per block, then the liquidity fees for a 2000sat
> payment ($0.60) are redeemable onchain.
>
This heavily depends on the on-chain fees, and so will need to be
updated as a function of that, and adds another layer of complication.
Thanks for the interesting email,
Clara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230731/6ca8855f/attachment-0001.html>

2023-06-19 17:42:36 UTC

- reply

📅 Original date posted:2023-05-11
🗒️ Summary of this message: Join the jamming call on May 15 at 5 pm UTC to discuss HTLC endorsement and local reputation tracking in Lightning Network.
📝 Original message:
Hi List,
A reminder that we've got another jamming call coming up next week.
Monday 15 May
5 pm UTC
https://meet.jit.si/UnjammingLN
In this meeting, we’d like to discuss HTLC endorsement and local reputation
[1]. We’ve updated the draft spec PR with some details on what we think
reputation tracking should look like, and would like to get some early
feedback.
Feel free to add agenda items [2].
See you there,
Carla and Clara
[1] https://github.com/lightning/bolts/pull/1071
[2] https://github.com/ClaraShk/LNJamming/issues/14
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230511/438ac3c1/attachment.html>

2023-06-19 17:42:26 UTC

- reply

📅 Original date posted:2023-05-31
🗒️ Summary of this message: The HTLC endorsement model introduces a coupling effect between routing scoring algorithms and channel liquidity, with potential issues of reputation systems.
📝 Original message:
Hi,
> I think the distinction you're proposing between routing fees and reputation revenue matters in the HTLC endorsement model. For the example I'm using let's say Caroll and Bob share the same exact parameters, *reputation_revenue* = 1,000, *routing_window*=100 and *routing_window*=10, where the reputation revenue of Bob towards Caroll is made from multiple incoming links.
>
> For each HTLC forwarding request issued from Alice, Bob has to make the decision between refusing Alice HTLC forward over the Caroll incoming link, and lose an opportunity of fee income, or accept the HTLC and suffers from a damage if Alice reveals a posteriori as a jamming attacker.
>
> Bob can also forward but not endorse Alice's HTLC. All of this is a
function of how much credit Bob gives to Alice's judgment. In case of
jamming, the damage that Alice inflicts should be proportional to the
revenue she recently created for Bob, and so the more damage, the higher
the threshold.
>
> This is unclear to me how the compensation mechanism works in the chain of nodes that have high reputation with each other, and I still think the HTLC endorsement mitigation suffers from the classic issues of reputation systems (i.e whitewashing).
>
> This system guarantees that if a node was jammed, it was paid a
significant some prior to the attack happening. There is no claim about who
is paying or the cost of the attack.
I think there is a coupling effec introduced between the historical
liquidity buckets of routing scoring algorithms and the introduction
of endorsment scheme with adjustement of the channel liquidity and
slots in function of local topology reputation.
>
>
> See the LDK scoring engine comments here : https://github.com/lightningdevkit/rust-lightning/blob/eec5ec6b50720144fc23503c3ee9c1c8850517ac/lightning/src/routing/scoring.rs#L336
>
>
The reading on the channel liquidity can change for different users using
different routes, but the information a node gets is what liquidity is
available for them (and not the state of the channel in general). This
indeed can fluctuate more than it does now, but so is the liquidity
available for a specific node.
Best,
Clara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230531/adab622d/attachment-0001.html>

2023-06-19 17:42:24 UTC

- reply

📅 Original date posted:2023-05-10
🗒️ Summary of this message: The Lightning Network's reputation system is susceptible to sudden behavioral changes and whitewashing attacks, but fees can put a price on having a good reputation. Nodes do not gossip about peer reputation, and data collection will inform future decisions.
📝 Original message:
Hi Christian,
Thanks for your comments! We will discuss this further in the upcoming call
on the 15th, would be great to see you there!
> this is an intrinsic issue with reputation systems, and the main
> reason I'm sceptical w.r.t. their usefulness in lightning.
> Fundamentally any reputation system bases their expectations for the
> future on experiences they made in the past, and they are thus always
> susceptible to sudden behavioral changes (going rogue from a prior
> clean record) and whitewashing attacks (switching identity, abusing
> any builtin bootstrapping method for new users to gain a good or
> neutral reputation before turning rogue repeatedly).
>
In the Lightning Network, fees are a native way to put a price on having a
good reputation (see details here [0]). In the design that we suggest, the
reputation gained today cannot be used in the distant future, and funds
need to be invested continuously to keep a good reputation. Good reputation
is also a function of the general environment, and so if there is a fee
spike, reputation will change. It is true that nodes can go rogue, but this
is why we aim for the price of a good reputation to be similar to the
amount of damage they can create.
> This gets compounded as soon as we start gossiping about reputations,
> since now our decisions are no longer based just on information we can
> witness ourselves, or at least verify its correctness, and as such an
> attacker can most likely "earn" a positive reputation in some other
> part of the world, and then turn around and attack the nodes that
> trusted the reputation shared from those other parts.
>
Notice that we are not gossiping about our peer's reputation. The only
thing that a node communicates to its neighbor is whether they see an HTLC
as endorsed or just neutral, that is, should this HTLC be granted access to
all of the resources or just the restricted part.
> I'd be very interested in how many repeat interactions nodes get from
> individual senders, since that also tells us how much use we can get
> out of local-only reputation based systems, and I wouldn't be
> surprised if, for large routing nodes, we have sufficient data for
> them to make an informed decision, while the edges may be more
> vulnerable, but they'd also be used by way fewer senders, and the
> impact of an attack would also be proportionally smaller.
>
This is something we hope to learn once we'll start collecting data from
our brave volunteers :)
Cheers,
Clara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230510/e8f3be68/attachment-0001.html>

2023-06-19 17:42:22 UTC

- reply

📅 Original date posted:2023-05-08
🗒️ Summary of this message: The proposed HTLC endorsement scheme has a vulnerability where local reputation can be abused during high routing fees, and should aim for reputational transitivity.
📝 Original message:
Hi,
I think the HTLC endorsement scheme as proposed is still suffering from a
> vulnerability as local reputation can be built up during periods of low
> routing fees, endorsement gained and then abused during periods of high
> routing fees. Therefore, it sounds to me this scheme should aim for some
> reputational transitivity between incoming traffic and outgoing traffic.
> Namely, the acquisition cost of the local reputation should be equal to the
> max timevalue damage that one can inflict on a routing node channel
> accessible from its local counterparty granting this high-level of
> reputation.
>
This is the reason we have a moving window for the calculation.
Note that if there is a channel between Alice and Bob, then the reputation
of Alice from Bob's point of view is a function of Bob's total revenue in
the latest time period. If Bob experiences a spike in routing fees, nodes
might lose their reputation, but it would not work the other way around.
That is, one cannot gain reputation during low fee times and use it when
fees are high.
See further details in this email [0]
Best,
Clara
[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003857.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230508/abc0a16c/attachment-0001.html>

2023-06-09 13:12:51 UTC

- reply

📅 Original date posted:2023-03-06
🗒️ Summary of this message: The criteria for endorsement decisions and the distribution of liquidity/slots on outbound channels are unclear in the local reputation scheme. There may also be exploitable reputation asymmetries.
📝 Original message:
Hi,
This is unclear on which criterias the endorsement decision is made
>
A node endorses an HTLC if and only if it came from a neighbour that has
reputation 1 that endorsed it.
> Additionally, this is unclear how the available liquidity/slots on a given
> outbound channel are initially distributed between all the inbound channels
> (e.g proportional to the capacity) and how they're balanced once the
> inbound channels start to accumulate reputation.
>
The quotas are for any incoming HTLC that is either from a neighbour with
reputation 0, or is not endorsed. For each channel, the quotas
are independent of other channels and independent of the neighbour that
forwarded the HTLC.
> I don't know if this local reputation scheme precises how reputation is
> slashed in case of HTLC failure, and if any "grace" amount/rate is granted
> to the inbound channel counterparty, e.g Alice.
>
> Independently of those considerations, I think this local reputation
> scheme might suffer from exploitable reputation asymmetries by a jamming
> adversary.
> Let's say you have the topology:
>
> Alice - Bob - Caroll - Dave
>
> Alice accumulated a reputation of 1 towards Bob and same for Bob towards
> Caroll. As `fee_base_msat` Bob picked up 1000 msat and Caroll picked up
> 2000 msat. If Alice forwards a HTLC to Bob and it is endorsed by him
> before relay to Caroll, Alice can now inflict a 50 sat damage to Caroll,
> while only encumbering the lower-priced reputational cost towards Bob.
>
> This concern could hold in case of asymmetries arising from the dynamic
> adjustment of routing fees during an evaluated period of time. E.g both Bob
> and Caroll requires routing fees of 1000 msat. Alice builds up a reputation
> of 1 towards Bob during this period N. At period N+1, Caroll bumps her
> routing fees to 2000 msat. From now on, Alice can exploit this asymmetry.
>
In general, if Bob is a low flow node (resulting in it having a low
threshold for reputation), he cannot have a high reputation with Carroll as
he will never forward enough. Taking into account the differences in fees
is interesting, but should be checked further.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230306/88a444fc/attachment.html>

2023-06-09 13:12:50 UTC

- reply

📅 Original date posted:2023-03-03
🗒️ Summary of this message: The benefits of continuous solutions over binary should be understood before taking a more complicated direction. Reporting truthfully may not always be rational.
📝 Original message:
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/e91b930a/attachment.html>

2023-06-09 13:12:50 UTC

- reply

📅 Original date posted:2023-03-03
🗒️ Summary of this message: A continuous solution can differentiate between an active attacker and a low-traffic neighbor, unlike a binary solution that blocks all low-reputation nodes. Reporting c truthfully is crucial to avoid reputation penalties.
📝 Original message:
> 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.
>
If it's very cheap to behave like a neighbour with poor connectivity, why
wouldn't the attacker mimic this, and then block?
Differentiating between a potential attacker and just a low-traffic
neighbour is very difficult. I think that instead of "low/high reputation"
a better way to think about it is "unknown/endorsed", and just consider
which neighbour needs access to all resources and which one doesn't.
The idea of different bins was brought up a few times and might help a bit,
but I am not sure at all that it is worth the complication.
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.
>
It might be that there is a strong motivation to underestimate than
overestimate. That is – the punishment for underestimating by X is
significantly smaller than for overestimating by X (or vice versa). The
formula you choose can affect this significantly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230303/4c8fa6ae/attachment.html>

2023-06-09 13:12:49 UTC

- reply

📅 Original date posted:2023-03-03
🗒️ Summary of this message: The writer questions the benefits of reporting high confidence in a node's reputation, suggesting that a strategy of always reporting confidence 0 may be best.
📝 Original message:
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/ca1a5168/attachment.html>

2023-06-09 13:12:48 UTC

- reply

📅 Original date posted:2023-03-02
🗒️ Summary of this message: Thomas suggests that local reputation is more important than upfront fees in preventing slow jamming attacks. He proposes a formula for continuous reputation scores and suggests using more than one bit for confidence values.
📝 Original message:
Hi Thomas,
I really like the idea of taking into consideration the failures. In our
proposal, a failure won't benefit your reputation, as the neighbour is
trying to reach a fee threshold, but taking it into account instead of
ignoring it could be helpful against an adversary trying to manipulate
parameters.
Could you elaborate a bit about "*c, the confidence given by the previous
node.*" It looks from the formula (that has *1/c* component) that the lower
the confidence, the higher the reputation, and I am not sure that this is
the goal. Some numerical examples could help clarify the dynamics you are
aiming for.
Do you have some estimation of what kind of protection or compensation this
method offers?
Best,
Clara
On Thu, Mar 2, 2023 at 8:14 AM Thomas HUET <thomas.huet at acinq.fr> wrote:
> Hello,
>
> I think the local reputation is more important than upfront fees and
> should be worked on first because 1) the most likely attack against the
> network today is the slow jamming attack against which upfront fees are not
> very effective (an attacker would only consider fast jamming if the network
> is already resilient to slow jamming) and 2) I think that local reputation
> may protect well enough against all types of jamming so that we don't even
> need upfront fees to protect against fast jamming.
> Regarding the formula itself, I would treat all scores as continuous
> values between 0 and 1 instead of binary classes. My proposed formula is
> detailed here:
>
> https://docs.google.com/document/d/1hEt1EzyPFJ3gOY7PAvtm_XotTnlQO2r7LSF8Jx34qgc/edit?usp=sharing
> However my proposal is compatible with Clara's one in that the only thing
> that needs to be communicated to the peers is how confident we are that the
> payment will succeed and all the rest is done locally and everyone can use
> their own formula. I would just prefer this confidence value to be more
> than one bit but my formula would work with anything, even zero bits. The
> advantage of using more bits is that we can be more precise in which HTLCs
> we reject and reduce the number of innocent casualties.
>
> Thomas
>
> Le jeu. 16 févr. 2023 à 22:29, Clara Shikhelman <
> clara.shikhelman at gmail.com> a écrit :
>
>> Hi List,
>>
>> We’re writing to seek early feedback on a draft for a neighbour
>> reputation setting recommendation as a jamming mitigation. The main idea is
>> that allowing full access to liquidity and slots in a channel can result in
>> jamming. To prevent this, we allow full access only to neighbours that
>> forward HTLC that resolve quickly and generate more profit than the damage
>> they can potentially create.
>>
>> The full suggested jamming mitigation solution includes upfront fees
>> together with reputation, see [1] for details.
>>
>> In the previous episodes:
>>
>> As presented here [1], we suggest a two part jamming mitigation strategy.
>> Reputation-based forwarding is aimed to solve “slow jamming”, where the
>> jamming transaction takes a long time to resolve.
>>
>> The main idea is that each node gives a binary reputation to its
>> neighbour. Each channel has a quota of liquidity and slots (say 50% of the
>> channel size and 50% of the slots in the channel) dedicated to transactions
>> coming from neighbours with reputation 0, or for transactions coming from
>> neighbours with reputation 1 that were not endorsed by the neighbour.
>>
>> For example, when Alice asks Bob to forward to Charlie then:
>>
>> If (Alice has reputation 1 with Bob) and (Alice endorses transaction):
>>
>> Forward and endorse
>>
>> Else:
>>
>> If (amount < available liquidity quota) and (available slots in quota>0):
>>
>> Forward HTLC without endorsing
>>
>> Reduce available liquidity and slots
>>
>> Else:
>>
>> Reject
>>
>> Reputation:
>>
>> The question we discuss here is how does Alice gain “good” reputation
>> (i.e., a score of 1). Alice starts at 0, and she gains and keeps her good
>> reputation of 1 by continuously paying more fees to Bob than the damage she
>> can inflict.
>>
>> The 3 main parameters for reputation that each node operator picks are S,L
>> and M. Our recommendations are as follows:
>>
>> -
>>
>> S should be chosen as the maximum time an HTLC can be unresolved in
>> any of Bob’s channels.
>> -
>>
>> M is the revenue generated by Bob’s node in the time S, representing
>> the damage Alice could inflict.
>> -
>>
>> L is the time in which Alice should generate M revenue for Bob for
>> her to have a good reputation of 1. We suggest L=10S.
>>
>>
>> Alice has reputation 1 if, in the last L seconds, she has forwarded
>> payments that generated M satoshi in fees.
>>
>> As an example:
>>
>> -
>>
>> Bob has a maximum CLTV delta of 2 weeks [2]
>> -
>>
>> Over the last 2 weeks, he has earned 0.5 BTC in routing fees
>> -
>>
>> Alice will be considered to have good reputation if she has forwarded
>> 0.5 BTC of routing revenue to Bob over the last 20 weeks
>>
>>
>> Formally:
>>
>> Let t be the current time, and let S and L be constants.
>>
>> M is calculated to be the revenue of Bob in time [t-S,t]. The revenue of
>> Bob is the sum of fees from transactions forwarded by any neighbour besides
>> Alice + any payments received by Bob. Note that Bob can choose to also take
>> into account utility gained from sending payments or anything of value
>> to the node operator.
>>
>> Alice has reputation 1 if in the time [t-L,t] she has forwarded HTLCs
>> that paid M in normalized fees.
>>
>> We normalize fees by resolution time to reward payments that resolve
>> quickly and discount slow resolving payments. Here we assume 10 seconds is
>> the “normal” resolution time, this number can be bikesheded, and we round
>> up to avoid penalizing transactions resolved quicker than the “normal”.
>>
>> The fee from a single transaction is normalized by the time it took for
>> the HTLC to resolve, counted in slots of 10 seconds. That is:
>>
>> Normalized_fee = (fee)/[ceiling(time_to_resolve/10s)]
>>
>>
>>
>> Some notes
>>
>> 1.
>>
>> The reputation management happens locally, that is, the only protocol
>> change needed is the ability to signal endorsement as a TLV in
>> UpdateAddHTLC. The various parameters can be selected for various
>> risk preferences.
>> 2.
>>
>> We currently suggest a binary reputation for simplicity. Having
>> several buckets could be interesting to study, yet we don’t think that the
>> complexity and the possible privacy issues are worth the potential benefits.
>> 3.
>>
>> For most use cases, having reputation 0 is more than enough. If we
>> send and receive transactions at a low rate, we usually don’t need the full
>> liquidity and slots available in a channel. Reputation mostly comes into
>> play only when a channel is under attack, and then not all transaction are
>> allowed to go through.
>> 4.
>>
>> Following this thread [3]: it is important to note that we are only
>> giving reputation to our direct neighbours. An advantage of this is that we
>> have repeated interactions with them. In practice, this is also the only
>> clean data we have to use when deciding whether to forward an HTLC or not.
>>
>>
>> Best,
>>
>> Carla and Clara
>>
>>
>> [1]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
>> [2]
>> https://github.com/lightningnetwork/lnd/blob/de94a4ea5e81799330a72dfde111817b38565d99/htlcswitch/link.go#L51
>> [3]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003842.html
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230302/a33c0a42/attachment-0001.html>

2023-06-09 13:08:51 UTC

- reply

📅 Original date posted:2023-05-31
📝 Original message:
Hi,
> I think the distinction you're proposing between routing fees and reputation revenue matters in the HTLC endorsement model. For the example I'm using let's say Caroll and Bob share the same exact parameters, *reputation_revenue* = 1,000, *routing_window*=100 and *routing_window*=10, where the reputation revenue of Bob towards Caroll is made from multiple incoming links.
>
> For each HTLC forwarding request issued from Alice, Bob has to make the decision between refusing Alice HTLC forward over the Caroll incoming link, and lose an opportunity of fee income, or accept the HTLC and suffers from a damage if Alice reveals a posteriori as a jamming attacker.
>
> Bob can also forward but not endorse Alice's HTLC. All of this is a
function of how much credit Bob gives to Alice's judgment. In case of
jamming, the damage that Alice inflicts should be proportional to the
revenue she recently created for Bob, and so the more damage, the higher
the threshold.
>
> This is unclear to me how the compensation mechanism works in the chain of nodes that have high reputation with each other, and I still think the HTLC endorsement mitigation suffers from the classic issues of reputation systems (i.e whitewashing).
>
> This system guarantees that if a node was jammed, it was paid a
significant some prior to the attack happening. There is no claim about who
is paying or the cost of the attack.
I think there is a coupling effec introduced between the historical
liquidity buckets of routing scoring algorithms and the introduction
of endorsment scheme with adjustement of the channel liquidity and
slots in function of local topology reputation.
>
>
> See the LDK scoring engine comments here : https://github.com/lightningdevkit/rust-lightning/blob/eec5ec6b50720144fc23503c3ee9c1c8850517ac/lightning/src/routing/scoring.rs#L336
>
>
The reading on the channel liquidity can change for different users using
different routes, but the information a node gets is what liquidity is
available for them (and not the state of the channel in general). This
indeed can fluctuate more than it does now, but so is the liquidity
available for a specific node.
Best,
Clara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230531/adab622d/attachment-0001.html>

2023-06-09 13:08:50 UTC

- reply

📅 Original date posted:2023-05-17
📝 Original message:
Hi,
> The lack of transitivity of the reputation acquisition cost (e.g based on
> historical fees earned from forwards originating from the peer) between the
> hops of the payment path still raises a vulnerability issue for the
> endorsement scheme, I think.
>
> Namely, let's say you have Alice, Bob and Caroll where endorsement has
> been obtained by Alice on the Bob incoming link by paying fees for an
> amount of 1000 sats for the last 100 blocks. Caroll offers a far higher
> pricing on her incoming link from Bob, 10000 sats as `fee_base_msat` on her
> endorsed slots. It sounds to me there is nothing preventing Alice from
> sacrificing her earned reputation to inflict a loss of routing fees damage
> on Caroll incoming link ?
>
I think it's important to differentiate between fees a node charges and
*reputation_revenue*. Reputation is determined as a function of the latter.
If Caroll has a very high *reputation_revenue* and Bob has a very low one,
then Bob probably won't have a high reputation with Caroll, as the amount
of fees he forwards to Caroll is smaller than the damage he can create.
That is, if Caroll is a huge node and Bob is a raspberry pi, then Bob will
never have a good reputation with Caroll. If they have similar
*reputation_revenue*, then getting a good reputation with Bob is as
difficult as getting a good reputation with Caroll.
In your example (if I got it correctly) Bob's *reputation_revenue* = 1,000,
*reputation_window*=100 and *routing_window*=10. Could you explain what are
Caroll's parameters are in your example? The *fee_base_msat* does not
indicate Carolls *reputation_revenue* (unless Alice is the only one
transacting on the Bob-Caroll channel, and then she is the one paying for
Bob's reputation).
That being said, we use *reputation_revenue *to estimate the damage an
attacker can create. If there is a chain of nodes that have high reputation
with each other, and they are jammed, they would be compensated for the
revenue lost during the attack. If Bob finds that having a high reputation
with Caroll is crucial and 1,000 sats will not compensate him for loosing
it, then he should either never endorse anything on that channel, or at
least put a higher bar than *reputation_revenue*.
There is an independent new observation on the effect of dynamic reputation
> windows on payment reliability, as those windows are not announced to the
> rest of the network, sudden changes in the links throughput based on HTLC
> resolution might break the historical liquidity buckets of routing scoring
> algorithms (at least in the way we're doing it for LDK), I think ?
>
Not sure what you mean by that.
Best,
Clara
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230517/d00db6ae/attachment.html>

2023-06-09 13:08:49 UTC

- reply

📅 Original date posted:2023-05-10
📝 Original message:
Hi Christian,
Thanks for your comments! We will discuss this further in the upcoming call
on the 15th, would be great to see you there!
> this is an intrinsic issue with reputation systems, and the main
> reason I'm sceptical w.r.t. their usefulness in lightning.
> Fundamentally any reputation system bases their expectations for the
> future on experiences they made in the past, and they are thus always
> susceptible to sudden behavioral changes (going rogue from a prior
> clean record) and whitewashing attacks (switching identity, abusing
> any builtin bootstrapping method for new users to gain a good or
> neutral reputation before turning rogue repeatedly).
>
In the Lightning Network, fees are a native way to put a price on having a
good reputation (see details here [0]). In the design that we suggest, the
reputation gained today cannot be used in the distant future, and funds
need to be invested continuously to keep a good reputation. Good reputation
is also a function of the general environment, and so if there is a fee
spike, reputation will change. It is true that nodes can go rogue, but this
is why we aim for the price of a good reputation to be similar to the
amount of damage they can create.
> This gets compounded as soon as we start gossiping about reputations,
> since now our decisions are no longer based just on information we can
> witness ourselves, or at least verify its correctness, and as such an
> attacker can most likely "earn" a positive reputation in some other
> part of the world, and then turn around and attack the nodes that
> trusted the reputation shared from those other parts.
>
Notice that we are not gossiping about our peer's reputation. The only
thing that a node communicates to its neighbor is whether they see an HTLC
as endorsed or just neutral, that is, should this HTLC be granted access to
all of the resources or just the restricted part.
> I'd be very interested in how many repeat interactions nodes get from
> individual senders, since that also tells us how much use we can get
> out of local-only reputation based systems, and I wouldn't be
> surprised if, for large routing nodes, we have sufficient data for
> them to make an informed decision, while the edges may be more
> vulnerable, but they'd also be used by way fewer senders, and the
> impact of an attack would also be proportionally smaller.
>
This is something we hope to learn once we'll start collecting data from
our brave volunteers :)
Cheers,
Clara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230510/e8f3be68/attachment-0001.html>

2023-06-09 13:08:48 UTC

- reply

📅 Original date posted:2023-05-08
📝 Original message:
Hi,
I think the HTLC endorsement scheme as proposed is still suffering from a
> vulnerability as local reputation can be built up during periods of low
> routing fees, endorsement gained and then abused during periods of high
> routing fees. Therefore, it sounds to me this scheme should aim for some
> reputational transitivity between incoming traffic and outgoing traffic.
> Namely, the acquisition cost of the local reputation should be equal to the
> max timevalue damage that one can inflict on a routing node channel
> accessible from its local counterparty granting this high-level of
> reputation.
>
This is the reason we have a moving window for the calculation.
Note that if there is a channel between Alice and Bob, then the reputation
of Alice from Bob's point of view is a function of Bob's total revenue in
the latest time period. If Bob experiences a spike in routing fees, nodes
might lose their reputation, but it would not work the other way around.
That is, one cannot gain reputation during low fee times and use it when
fees are high.
See further details in this email [0]
Best,
Clara
[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003857.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230508/abc0a16c/attachment-0001.html>

2023-06-09 13:08:19 UTC

- reply

📅 Original date posted:2023-03-06
📝 Original message:
Hi,
This is unclear on which criterias the endorsement decision is made
>
A node endorses an HTLC if and only if it came from a neighbour that has
reputation 1 that endorsed it.
> Additionally, this is unclear how the available liquidity/slots on a given
> outbound channel are initially distributed between all the inbound channels
> (e.g proportional to the capacity) and how they're balanced once the
> inbound channels start to accumulate reputation.
>
The quotas are for any incoming HTLC that is either from a neighbour with
reputation 0, or is not endorsed. For each channel, the quotas
are independent of other channels and independent of the neighbour that
forwarded the HTLC.
> I don't know if this local reputation scheme precises how reputation is
> slashed in case of HTLC failure, and if any "grace" amount/rate is granted
> to the inbound channel counterparty, e.g Alice.
>
> Independently of those considerations, I think this local reputation
> scheme might suffer from exploitable reputation asymmetries by a jamming
> adversary.
> Let's say you have the topology:
>
> Alice - Bob - Caroll - Dave
>
> Alice accumulated a reputation of 1 towards Bob and same for Bob towards
> Caroll. As `fee_base_msat` Bob picked up 1000 msat and Caroll picked up
> 2000 msat. If Alice forwards a HTLC to Bob and it is endorsed by him
> before relay to Caroll, Alice can now inflict a 50 sat damage to Caroll,
> while only encumbering the lower-priced reputational cost towards Bob.
>
> This concern could hold in case of asymmetries arising from the dynamic
> adjustment of routing fees during an evaluated period of time. E.g both Bob
> and Caroll requires routing fees of 1000 msat. Alice builds up a reputation
> of 1 towards Bob during this period N. At period N+1, Caroll bumps her
> routing fees to 2000 msat. From now on, Alice can exploit this asymmetry.
>
In general, if Bob is a low flow node (resulting in it having a low
threshold for reputation), he cannot have a high reputation with Carroll as
he will never forward enough. Taking into account the differences in fees
is interesting, but should be checked further.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230306/88a444fc/attachment.html>

2023-06-09 13:08:19 UTC

- reply

📅 Original date posted:2023-03-06
📝 Original message:
Hi List,
A reminder that we've got another jamming call coming up today at 19:00 UTC.
Monday 06 Mar
19:00 UTC
https://meet.jit.si/UnjammingLN
Feel free to add additional agenda items here:
https://github.com/ClaraShk/LNJamming/issues/
<https://github.com/ClaraShk/LNJamming/issues/5>5
See you soon!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230306/12138099/attachment.html>

2023-06-09 13:08:18 UTC

- reply

📅 Original date posted:2023-03-03
📝 Original message:
> 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.
>
If it's very cheap to behave like a neighbour with poor connectivity, why
wouldn't the attacker mimic this, and then block?
Differentiating between a potential attacker and just a low-traffic
neighbour is very difficult. I think that instead of "low/high reputation"
a better way to think about it is "unknown/endorsed", and just consider
which neighbour needs access to all resources and which one doesn't.
The idea of different bins was brought up a few times and might help a bit,
but I am not sure at all that it is worth the complication.
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.
>
It might be that there is a strong motivation to underestimate than
overestimate. That is – the punishment for underestimating by X is
significantly smaller than for overestimating by X (or vice versa). The
formula you choose can affect this significantly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230303/4c8fa6ae/attachment.html>

2023-06-09 13:08:17 UTC

- reply

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

2023-06-09 13:08:17 UTC

- reply

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

2023-06-09 13:08:15 UTC

- reply

📅 Original date posted:2023-03-02
📝 Original message:
Hi Thomas,
I really like the idea of taking into consideration the failures. In our
proposal, a failure won't benefit your reputation, as the neighbour is
trying to reach a fee threshold, but taking it into account instead of
ignoring it could be helpful against an adversary trying to manipulate
parameters.
Could you elaborate a bit about "*c, the confidence given by the previous
node.*" It looks from the formula (that has *1/c* component) that the lower
the confidence, the higher the reputation, and I am not sure that this is
the goal. Some numerical examples could help clarify the dynamics you are
aiming for.
Do you have some estimation of what kind of protection or compensation this
method offers?
Best,
Clara
On Thu, Mar 2, 2023 at 8:14 AM Thomas HUET <thomas.huet at acinq.fr> wrote:
> Hello,
>
> I think the local reputation is more important than upfront fees and
> should be worked on first because 1) the most likely attack against the
> network today is the slow jamming attack against which upfront fees are not
> very effective (an attacker would only consider fast jamming if the network
> is already resilient to slow jamming) and 2) I think that local reputation
> may protect well enough against all types of jamming so that we don't even
> need upfront fees to protect against fast jamming.
> Regarding the formula itself, I would treat all scores as continuous
> values between 0 and 1 instead of binary classes. My proposed formula is
> detailed here:
>
> https://docs.google.com/document/d/1hEt1EzyPFJ3gOY7PAvtm_XotTnlQO2r7LSF8Jx34qgc/edit?usp=sharing
> However my proposal is compatible with Clara's one in that the only thing
> that needs to be communicated to the peers is how confident we are that the
> payment will succeed and all the rest is done locally and everyone can use
> their own formula. I would just prefer this confidence value to be more
> than one bit but my formula would work with anything, even zero bits. The
> advantage of using more bits is that we can be more precise in which HTLCs
> we reject and reduce the number of innocent casualties.
>
> Thomas
>
> Le jeu. 16 févr. 2023 à 22:29, Clara Shikhelman <
> clara.shikhelman at gmail.com> a écrit :
>
>> Hi List,
>>
>> We’re writing to seek early feedback on a draft for a neighbour
>> reputation setting recommendation as a jamming mitigation. The main idea is
>> that allowing full access to liquidity and slots in a channel can result in
>> jamming. To prevent this, we allow full access only to neighbours that
>> forward HTLC that resolve quickly and generate more profit than the damage
>> they can potentially create.
>>
>> The full suggested jamming mitigation solution includes upfront fees
>> together with reputation, see [1] for details.
>>
>> In the previous episodes:
>>
>> As presented here [1], we suggest a two part jamming mitigation strategy.
>> Reputation-based forwarding is aimed to solve “slow jamming”, where the
>> jamming transaction takes a long time to resolve.
>>
>> The main idea is that each node gives a binary reputation to its
>> neighbour. Each channel has a quota of liquidity and slots (say 50% of the
>> channel size and 50% of the slots in the channel) dedicated to transactions
>> coming from neighbours with reputation 0, or for transactions coming from
>> neighbours with reputation 1 that were not endorsed by the neighbour.
>>
>> For example, when Alice asks Bob to forward to Charlie then:
>>
>> If (Alice has reputation 1 with Bob) and (Alice endorses transaction):
>>
>> Forward and endorse
>>
>> Else:
>>
>> If (amount < available liquidity quota) and (available slots in quota>0):
>>
>> Forward HTLC without endorsing
>>
>> Reduce available liquidity and slots
>>
>> Else:
>>
>> Reject
>>
>> Reputation:
>>
>> The question we discuss here is how does Alice gain “good” reputation
>> (i.e., a score of 1). Alice starts at 0, and she gains and keeps her good
>> reputation of 1 by continuously paying more fees to Bob than the damage she
>> can inflict.
>>
>> The 3 main parameters for reputation that each node operator picks are S,L
>> and M. Our recommendations are as follows:
>>
>> -
>>
>> S should be chosen as the maximum time an HTLC can be unresolved in
>> any of Bob’s channels.
>> -
>>
>> M is the revenue generated by Bob’s node in the time S, representing
>> the damage Alice could inflict.
>> -
>>
>> L is the time in which Alice should generate M revenue for Bob for
>> her to have a good reputation of 1. We suggest L=10S.
>>
>>
>> Alice has reputation 1 if, in the last L seconds, she has forwarded
>> payments that generated M satoshi in fees.
>>
>> As an example:
>>
>> -
>>
>> Bob has a maximum CLTV delta of 2 weeks [2]
>> -
>>
>> Over the last 2 weeks, he has earned 0.5 BTC in routing fees
>> -
>>
>> Alice will be considered to have good reputation if she has forwarded
>> 0.5 BTC of routing revenue to Bob over the last 20 weeks
>>
>>
>> Formally:
>>
>> Let t be the current time, and let S and L be constants.
>>
>> M is calculated to be the revenue of Bob in time [t-S,t]. The revenue of
>> Bob is the sum of fees from transactions forwarded by any neighbour besides
>> Alice + any payments received by Bob. Note that Bob can choose to also take
>> into account utility gained from sending payments or anything of value
>> to the node operator.
>>
>> Alice has reputation 1 if in the time [t-L,t] she has forwarded HTLCs
>> that paid M in normalized fees.
>>
>> We normalize fees by resolution time to reward payments that resolve
>> quickly and discount slow resolving payments. Here we assume 10 seconds is
>> the “normal” resolution time, this number can be bikesheded, and we round
>> up to avoid penalizing transactions resolved quicker than the “normal”.
>>
>> The fee from a single transaction is normalized by the time it took for
>> the HTLC to resolve, counted in slots of 10 seconds. That is:
>>
>> Normalized_fee = (fee)/[ceiling(time_to_resolve/10s)]
>>
>>
>>
>> Some notes
>>
>> 1.
>>
>> The reputation management happens locally, that is, the only protocol
>> change needed is the ability to signal endorsement as a TLV in
>> UpdateAddHTLC. The various parameters can be selected for various
>> risk preferences.
>> 2.
>>
>> We currently suggest a binary reputation for simplicity. Having
>> several buckets could be interesting to study, yet we don’t think that the
>> complexity and the possible privacy issues are worth the potential benefits.
>> 3.
>>
>> For most use cases, having reputation 0 is more than enough. If we
>> send and receive transactions at a low rate, we usually don’t need the full
>> liquidity and slots available in a channel. Reputation mostly comes into
>> play only when a channel is under attack, and then not all transaction are
>> allowed to go through.
>> 4.
>>
>> Following this thread [3]: it is important to note that we are only
>> giving reputation to our direct neighbours. An advantage of this is that we
>> have repeated interactions with them. In practice, this is also the only
>> clean data we have to use when deciding whether to forward an HTLC or not.
>>
>>
>> Best,
>>
>> Carla and Clara
>>
>>
>> [1]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
>> [2]
>> https://github.com/lightningnetwork/lnd/blob/de94a4ea5e81799330a72dfde111817b38565d99/htlcswitch/link.go#L51
>> [3]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003842.html
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230302/a33c0a42/attachment-0001.html>

2023-06-09 13:08:09 UTC

- reply

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

2023-06-09 13:07:56 UTC

- reply

📅 Original date posted:2023-01-18
📝 Original message:
Hi All,
Time to bring back the anti-jamming discussions!
Our next call will be on January 23rd at 6 pm UTC (notice the time change)
at the usual place: https://meet.jit.si/UnjammingLN.
A draft of the agenda is available here:
https://github.com/ClaraShk/LNJamming/issues/1
Please feel free to add agenda items on the issue!
See you soon,
Clara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230118/74b63c37/attachment.html>

2023-06-09 13:07:41 UTC

- reply

📅 Original date posted:2022-12-09
📝 Original message:
Hi Antoine,
Thanks for your input.
The first item is there because we agreed to start where we left off at the
end of the last meeting.
About your comments on the other items – I think they are very interesting,
but you should probably write them in the relevant thread. Let's keep this
for meeting housekeeping.
I agree about a repository, will do this soon.
As for the frequency, the next one will be in a month because of the
holidays. I like the biweekly because things stay fresh. Of course, there
is no need for everyone to attend, we'll start publishing a summary for
those who can't.
If you would like to write a transcript, it would be very useful and much
appreciated.
Best,
Clara
On Thu, Dec 8, 2022 at 10:31 PM Antoine Riard <antoine.riard at gmail.com>
wrote:
> Hi Clara,
>
> Thanks for rolling the ball forward.
>
> On the agenda, a few more thoughts.
>
> > 1. Which parameters should be considered in reputation-based solutions?
>
> I think before thinking about the parameters of reputation-based
> solutions, we should discuss the security goal we're aiming to achieve with
> any potential jamming solutions. Browsing the solution space some have
> aimed to increase the opportunity cost for the attacker (e.g liquidity
> slots), some to reduce the jamming intensity (e.g circuit breakers), some
> inflicting a on-chain fee damage cost back to the adversary (e.g stake
> certificates), some to achieve economic hedge of the routing hops (e.g
> unconditional
> fees, reputation credentials). As of today, I would say a security goal
> designed in the term of a monetary strategy could be more acceptable to the
> routing hops node operators. Beyond that, I believe there is capturing this
> design goal in a "measurable" notion, such as the unjamming lightning
> paper's breakeven point, and see how we can enrich this "measurable" notion.
>
> > 2. Circuitbreaker [1]
>
> While reviewing the circuitbreaker last week, I started to wonder if there
> wasn't another "hidden" issue while solving channel jamming, namely
> congestion control of the HTLC flows. A node operator is not only
> interested that any liquidity unit allocated for a HTLC forward is paid
> back with routing fees, but also in case of more forward demand than
> liquidity offer, ready to process it (potentially by deferring and sending
> backpressure messages to the HTLC sender). I don't know, though I think
> that can be an interesting point to discuss.
>
> > 3. Onion relay network [2] and its potential uses.
>
> Onion relay network rate-limits have been discussed earlier this year,
> with a probabilistic backpressure scheme proposed. If the onion relay
> traffic starts to have economically-weighable traffic (offers, credentials
> tokens, etc), there could be a risk of onion-jamming. For the bootstrap of
> the onion relay network, I believe this could be solved by leveraging more
> the channel-network topology for the design of a solution. We could re-use
> the evaluation framework from the unjamming lightning paper, I guess.
>
> In the meeting, I think it could be very valuable if we have reliable
> transcripts and if we start to maintain a community repository, where we
> can pin the issues, problems and ideas.
>
> On the frequency of the meeting, note some Lightning developers raised the
> concern that biweekly might be too much:
> https://gnusha.org/lightning-dev/2022-11-23.log (once a month could work
> well too, if we have a sound agenda).
>
> Best,
> Antoine
>
> Le jeu. 8 déc. 2022 à 11:08, Clara Shikhelman <clara.shikhelman at gmail.com>
> a écrit :
>
>> Hi all,
>>
>> The agenda for next week's meeting (Monday the 12th, 7 pm UTC) is the
>> following:
>>
>> 1. Which parameters should be considered in reputation-based solutions?
>> 2. Circuitbreaker [1]
>> 3. Onion relay network [2] and its potential uses.
>>
>> The link to the call: https://meet.jit.si/UnjammingLN
>>
>> See you there,
>> Clara
>>
>> [1]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003781.html
>> [2]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003780.html
>>
>> On Sun, Nov 27, 2022 at 9:48 PM Clara Shikhelman <
>> clara.shikhelman at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> In light of recent conversations ([1],[2]), the agenda for the call
>>> tomorrow (Monday the 28th, 7 pm UTC) is roughly the following:
>>>
>>> 1. Overview of solutions under discussion
>>> 2. Reputation (local/tokens)
>>> 3. Fees
>>>
>>> This is the link to the call: https://meet.jit.si/UnjammingLN
>>>
>>> See you there,
>>> Clara
>>>
>>> [1]
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
>>> [2]
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html
>>> _______________________________________________
>>> 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/20221208/52e3595c/attachment-0001.html>

2023-06-09 13:07:40 UTC

- reply

📅 Original date posted:2022-12-08
📝 Original message:
Hi all,
The agenda for next week's meeting (Monday the 12th, 7 pm UTC) is the
following:
1. Which parameters should be considered in reputation-based solutions?
2. Circuitbreaker [1]
3. Onion relay network [2] and its potential uses.
The link to the call: https://meet.jit.si/UnjammingLN
See you there,
Clara
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003781.html
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003780.html
On Sun, Nov 27, 2022 at 9:48 PM Clara Shikhelman <clara.shikhelman at gmail.com>
wrote:
> Hi all,
>
> In light of recent conversations ([1],[2]), the agenda for the call
> tomorrow (Monday the 28th, 7 pm UTC) is roughly the following:
>
> 1. Overview of solutions under discussion
> 2. Reputation (local/tokens)
> 3. Fees
>
> This is the link to the call: https://meet.jit.si/UnjammingLN
>
> See you there,
> Clara
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
> [2]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.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/20221208/5fc41c64/attachment.html>

2023-06-09 13:07:25 UTC

- reply

📅 Original date posted:2022-11-25
📝 Original message:
Cool, thanks for that.
Have you done any work on the economic aspects of the new tokens and their
secondary markets?
On Thu, Nov 24, 2022, 21:22 Antoine Riard <antoine.riard at gmail.com> wrote:
> Hi Clara,
>
> The main benefit of this "staking"/reputational credentials is to save on
> unconditional fees paid by HTLC senders. They benefit from their past HTLC
> routing success in terms of more credentials allocated to them, and as such
> minimize the overhead cost of their future HTLC sends, or allow them to
> lock liquidity for longer periods. From a routing node viewpoint, a 0-risk
> HTLC forwarding acceptance can be maintained by requesting strict binding
> between credentials acquisition cost and channel liquidity routed. If
> higher returns are seeked, the ratio credentials to liquidity can be
> adjusted, of course coming with higher risks, and I think this is where the
> model built for the current unconditional fees proposal could be useful (if
> we integrate the channel congestion rate factor, I believe).
>
> On top of this monetary paradigm, we can layer a "pure reputation" system,
> where in function of the quality of the identities (e.g
> proof-of-utxo-ownership), HTLC senders are allocated more significant
> liquidity slots. Here, the real bottleneck is the cryptosystem, i.e proving
> a UTXO ownership without revealing any other information. The rationale of
> this "pure reputation" system, we could even save more in
> upfront/unconditional fees in the steady state of the network (however such
> a probabilistic model breaks hard in presence of attackers).
>
> Best,
> Antoine
>
> Le jeu. 24 nov. 2022 à 09:45, Clara Shikhelman <clara.shikhelman at gmail.com>
> a écrit :
>
>> Hi Antoine,
>>
>> It sounds like unconditional fees cover most of what this policy does,
>> without the extra risks that come from creating a new token. Is there a
>> clear benefit to using a token compared to unconditional fees and
>> local reputation?
>>
>> Best,
>> Clara
>>
>> On Wed, Nov 23, 2022 at 9:48 PM Antoine Riard <antoine.riard at gmail.com>
>> wrote:
>>
>>> Hi Clara,
>>>
>>> I think the simplest recommended policy you can devise is credential
>>> shown to the routing hop should cover for full routing fees, therefore the
>>> routing hop benefits from a zero-jamming risk situation. Then you can
>>> appreciate the "liquidity value" credentials requested in function of your
>>> local channel congestion rate, or even network data. Increasing your
>>> returns in exchange of higher risk exposure. And even more, you can lay on
>>> top a reputation layer, where the reputation scores are fully fungible
>>> against monetary credentials, in the acceptance of a HTLC forward request.
>>>
>>> So I think I agree with you a recommended policy is needed, let's just
>>> start with a simple one! And refine it with time once we sense we have
>>> solid foundations.
>>>
>>> Best,
>>> Antoine
>>>
>>>
>>> Le mer. 23 nov. 2022 à 11:00, Clara Shikhelman <
>>> clara.shikhelman at gmail.com> a écrit :
>>>
>>>> Hi Antoine,
>>>>
>>>> To discuss your proposed solution in detail, I think that some kind of
>>>> recommended policy is needed. If presenting one is a low priority, and
>>>> waiting for other things, my main concern is that it will just never happen
>>>> ("any decade now" kind of situation).
>>>>
>>>> Best,
>>>> Clara
>>>>
>>>> On Tue, Nov 22, 2022 at 8:13 PM Antoine Riard <antoine.riard at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Clara,
>>>>>
>>>>> Shared the mail on #lightning-dev Libera chat to get more feedback on
>>>>> schedule.
>>>>>
>>>>> > Do you have a timeline in mind for presenting such a policy?
>>>>>
>>>>> See the comments on the BOLT #1043 PR, for now I'm thinking more to
>>>>> refine the proposed credentials architectural framework.
>>>>> I think dynamic routing policy in function of channel congestion rate,
>>>>> and you combine that with reputation to do active risk-management are far
>>>>> more advanced questions.
>>>>>
>>>>> Best,
>>>>> Antoine
>>>>>
>>>>> Le mar. 22 nov. 2022 à 15:54, Clara Shikhelman <
>>>>> clara.shikhelman at gmail.com> a écrit :
>>>>>
>>>>>> Dear All,
>>>>>>
>>>>>> If the call time (Monday the 28th at 7 pm UTC) doesn't work out for
>>>>>> you, please reach out!
>>>>>>
>>>>>> Thanks for your quick and detailed response, Antoine.
>>>>>>
>>>>>> If by recommend policy, you mean the set of algorithms that should
>>>>>>> guide the token quantity, rate issuance, token acquisition cost, and the
>>>>>>> adaptations in function of the local channel congestion, or even the
>>>>>>> gossips of the other routing nodes, not at all.
>>>>>>>
>>>>>>
>>>>>> Do you have a timeline in mind for presenting such a policy?
>>>>>>
>>>>>> Looking forward to discussing this further over the phone call, will
>>>>>> make some inquiries to make sure the time works for most people.
>>>>>>
>>>>>> Best,
>>>>>> Clara
>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221125/831d4b21/attachment.html>

2023-06-09 13:07:24 UTC

- reply

📅 Original date posted:2022-11-23
📝 Original message:
Hi Antoine,
To discuss your proposed solution in detail, I think that some kind of
recommended policy is needed. If presenting one is a low priority, and
waiting for other things, my main concern is that it will just never happen
("any decade now" kind of situation).
Best,
Clara
On Tue, Nov 22, 2022 at 8:13 PM Antoine Riard <antoine.riard at gmail.com>
wrote:
> Hi Clara,
>
> Shared the mail on #lightning-dev Libera chat to get more feedback on
> schedule.
>
> > Do you have a timeline in mind for presenting such a policy?
>
> See the comments on the BOLT #1043 PR, for now I'm thinking more to
> refine the proposed credentials architectural framework.
> I think dynamic routing policy in function of channel congestion rate, and
> you combine that with reputation to do active risk-management are far more
> advanced questions.
>
> Best,
> Antoine
>
> Le mar. 22 nov. 2022 à 15:54, Clara Shikhelman <clara.shikhelman at gmail.com>
> a écrit :
>
>> Dear All,
>>
>> If the call time (Monday the 28th at 7 pm UTC) doesn't work out for you,
>> please reach out!
>>
>> Thanks for your quick and detailed response, Antoine.
>>
>> If by recommend policy, you mean the set of algorithms that should guide
>>> the token quantity, rate issuance, token acquisition cost, and the
>>> adaptations in function of the local channel congestion, or even the
>>> gossips of the other routing nodes, not at all.
>>>
>>
>> Do you have a timeline in mind for presenting such a policy?
>>
>> Looking forward to discussing this further over the phone call, will make
>> some inquiries to make sure the time works for most people.
>>
>> Best,
>> Clara
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221123/ba980de5/attachment.html>

2023-06-09 13:07:24 UTC

- reply

📅 Original date posted:2022-11-24
📝 Original message:
Hi Antoine,
It sounds like unconditional fees cover most of what this policy does,
without the extra risks that come from creating a new token. Is there a
clear benefit to using a token compared to unconditional fees and
local reputation?
Best,
Clara
On Wed, Nov 23, 2022 at 9:48 PM Antoine Riard <antoine.riard at gmail.com>
wrote:
> Hi Clara,
>
> I think the simplest recommended policy you can devise is credential shown
> to the routing hop should cover for full routing fees, therefore the
> routing hop benefits from a zero-jamming risk situation. Then you can
> appreciate the "liquidity value" credentials requested in function of your
> local channel congestion rate, or even network data. Increasing your
> returns in exchange of higher risk exposure. And even more, you can lay on
> top a reputation layer, where the reputation scores are fully fungible
> against monetary credentials, in the acceptance of a HTLC forward request.
>
> So I think I agree with you a recommended policy is needed, let's just
> start with a simple one! And refine it with time once we sense we have
> solid foundations.
>
> Best,
> Antoine
>
>
> Le mer. 23 nov. 2022 à 11:00, Clara Shikhelman <clara.shikhelman at gmail.com>
> a écrit :
>
>> Hi Antoine,
>>
>> To discuss your proposed solution in detail, I think that some kind of
>> recommended policy is needed. If presenting one is a low priority, and
>> waiting for other things, my main concern is that it will just never happen
>> ("any decade now" kind of situation).
>>
>> Best,
>> Clara
>>
>> On Tue, Nov 22, 2022 at 8:13 PM Antoine Riard <antoine.riard at gmail.com>
>> wrote:
>>
>>> Hi Clara,
>>>
>>> Shared the mail on #lightning-dev Libera chat to get more feedback on
>>> schedule.
>>>
>>> > Do you have a timeline in mind for presenting such a policy?
>>>
>>> See the comments on the BOLT #1043 PR, for now I'm thinking more to
>>> refine the proposed credentials architectural framework.
>>> I think dynamic routing policy in function of channel congestion rate,
>>> and you combine that with reputation to do active risk-management are far
>>> more advanced questions.
>>>
>>> Best,
>>> Antoine
>>>
>>> Le mar. 22 nov. 2022 à 15:54, Clara Shikhelman <
>>> clara.shikhelman at gmail.com> a écrit :
>>>
>>>> Dear All,
>>>>
>>>> If the call time (Monday the 28th at 7 pm UTC) doesn't work out for
>>>> you, please reach out!
>>>>
>>>> Thanks for your quick and detailed response, Antoine.
>>>>
>>>> If by recommend policy, you mean the set of algorithms that should
>>>>> guide the token quantity, rate issuance, token acquisition cost, and the
>>>>> adaptations in function of the local channel congestion, or even the
>>>>> gossips of the other routing nodes, not at all.
>>>>>
>>>>
>>>> Do you have a timeline in mind for presenting such a policy?
>>>>
>>>> Looking forward to discussing this further over the phone call, will
>>>> make some inquiries to make sure the time works for most people.
>>>>
>>>> Best,
>>>> Clara
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221124/ae8ebfc1/attachment.html>

2023-06-09 13:07:23 UTC

- reply

📅 Original date posted:2022-11-22
📝 Original message:
Dear All,
If the call time (Monday the 28th at 7 pm UTC) doesn't work out for you,
please reach out!
Thanks for your quick and detailed response, Antoine.
If by recommend policy, you mean the set of algorithms that should guide
> the token quantity, rate issuance, token acquisition cost, and the
> adaptations in function of the local channel congestion, or even the
> gossips of the other routing nodes, not at all.
>
Do you have a timeline in mind for presenting such a policy?
Looking forward to discussing this further over the phone call, will make
some inquiries to make sure the time works for most people.
Best,
Clara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221122/8760f2a6/attachment.html>

2023-06-09 13:07:22 UTC

- reply

📅 Original date posted:2022-11-21
📝 Original message:
Dear Antoine and list,
I think that another call to discuss jamming would be great. I would
suggest making it a repeating call every 2 weeks, starting from Monday the
28th at 7 pm UTC.
Antoine - Thank you for your work!
I have a few questions to better understand the details.
1. Are the tokens transferable between users? For example, if Ned is a
routing node, and Alice has some of their tokens, can she give these tokens
to Bob?
If yes - could this lead to the creation of a secondary market?
If no - will that slow down the transaction flow that a new node can send?
2. Do you have a recommended policy for the creation of tokens and their
use? Ideally, there will be a policy that would mitigate both slow and
quick jamming, without harming usability too much.
3. You write "the reputation credentials to liquidity units translation can
be severed" - does this mean that the value of the token changes? Is that
in the spirit of changing the fees in a channel?
If this is the case, can't a routing node "trick" a user into buying many
tokens and then bring the price up?
4. How would these tokens work with blinded paths and other
privacy-preserving suggestions?
Thanks again,
Clara
On Sun, Nov 20, 2022 at 11:01 PM Antoine Riard <antoine.riard at gmail.com>
wrote:
> Hi LN Devs,
>
> tl;dr A formalization of a reputation-based scheme to solve channel
> jamming is proposed. The system relies on "credentials" issued by routing
> hops and requested to be attached to each HTLC forward request. The
> "credentials" can be used by a reputation algorithm to reward/punish
> payment senders and allocate channel liquidity resources efficiently. The
> "credentials" initial distribution can be bootstrapped leveraging one-time
> upfront fees paid toward the routing hops. Afterwards, the "credentials"
> subsequent distribution can rely on previous HTLC traffic.
>
> A protocol description can be found here, with few extensions already to
> the BOLTs:
>
> https://github.com/lightning/bolts/pull/1043
>
> There is also a work-in-progress proof-of-concept in LDK (on top of our
> coming soon^TM HTLC intercepting API):
>
> https://github.com/lightningdevkit/rust-lightning/pull/1848
>
> This work builds on previous reputation-scheme research [0] [1]. It also
> integrates the more recent proposals of upfront fees as a straightforward
> mechanism to bootstrap the reputation system. Bootstrapping the system with
> more economically cost-effective privacy-preserving UTXO ownership proofs
> not only add another layer of engineering complexity, there is still a
> proof size vs proof generation/validation trade-off to arbiter between ZKP
> cryptosystems.
>
> Rather to seek for a game-theory equilibrium defined as a breakeven point
> as in the latest unconditional fee research [2], this proposal aims to use
> reputation credentials to allow HTLC traffic-shaping. This not only should
> protect against jamming situations (either malicious
> or spontaneous) but also allow active HTLC traffic-shaping, where a
> routing hop can allow extended channel liquidity lockups based on
> accumulated reputation (e.g for hold-invoices). This is also a reduced
> overhead cost, as upfront fees are only paid at bootstrap, or when the HTLC
> forward behavior can be qualified as "whitewashing" from the routing hop
> viewpoint.
>
> It should be noted, this current reputation-credential architectural
> framework assumes credentials distribution at the endpoint of the network.
> However, the framework should be flexible enough for the credentials to be
> harvested by the LSPs, and then distributed in a secondary fashion to their
> spokes, when they need it, or even attached transparently thanks to
> trampoline. So one design intuition, there is no strong attachment of the
> reputation to the endpoint HTLC sender, even if the protocol is described
> in a "flat" view for now.
>
> Let's evaluate quickly this mitigation proposal against a few criterias
> emerged from recent research.
>
> The mitigation is effective, in the sense a routing hop can apply a
> proportional relationship between the acquisition of the reputation and the
> amount of liquidity resources credited in function of said reputation. In a
> period of steady state, the reputation acquisition cost can be downgraded
> to 0. In periods of channel congestion, the reputation credentials to
> liquidity units translation can be severed, in the limit of routing hop
> acceptable competitiveness.
>
> The mitigation is incentive-compatible, if the credentials are not honored
> by their issuers, the HTLC senders can evict them from the routing network
> view for a while. The successful usage of credentials can lead to more
> credentials allocated for longer and more capacity-intensive channel
> lockups. In case of HTLC failure, the failure source could be forgiven by
> routing hops to maintain the worthiness of the sender credentials.
>
> The mitigation can be made transparent from the user, as the credentials
> harvesting can be done automatically from a pre-allocated budget, similar
> to the fee-bumping reserves requirement introduced by anchor output. At the
> end of today, if we take modern browsers as an example, the average user
> doesn't check manually the TLS certificates (for what they're worth...).
>
> The mitigation can conserve high-level privacy, as the usage of blinded
> signature (or another equivalent cryptosystem breaking signature/message
> linking) should allow the credentials issued during a preliminary phase to
> be undistinguishable during the redeem/usage phase. New CPU/memory DoS
> vectors due to the credentials processing should be watched out.
>
> About the ease of implementation, there are few protocol messages to
> modify, a HTLC intercepting API is assumed as supported by the
> implementation, onion messages support is also implied, landing EC blinded
> signature in libsecp256k1-zkp shouldn't be a big deal, routing algorithms
> adaptations might be more serious but still reasonable. The
> "credentials-to-liquidity" allocation algorithms are likely the new real
> beast, though I don't think any reputation scheme can spare them.
>
> There could be a concern about the centralization inertia introduced by a
> reputation system. Intuitively, the argument can be made that any
> historical tracking (such as routing buckets) favor established LN
> incumbents at the gain of efficiency. A counter-argument can be made, a new
> routing hop can lower the acquisition cost of its issued credentials to
> attract more HTLC traffic (accepting higher jamming risk).
>
> On the ecosystem impacts, it should be studied that this proposal would
> impact things like inbound channel routing fees [3], ratecard [4] or
> flow-control valve [5] and the whole liquidity toolchain. Hopefully, we
> don't significantly restrain the design space for future LN protocol
> upgrades.
>
> On the proposal modularity and flexibility, each routing node has
> oversight on its routing policy, acquisition methods, credentials to
> liquidity rate. New acquisition methods can be experimented or deployed
> when ready, e.g stakes certificates with only e2e upgrade. The credentials
> themselves could have "innate" expiration time if we use things like
> short-lived ZKP [6]. The credentials framework can be extended beyond
> solving jamming, as a generalized risk-management framework for Bitcoin
> decentralized financial network, e.g transaction signature exchange
> ordering in multi-party transactions [7] or finding reliable Coinjoin
> counterparties.
>
> Feedback welcome.
>
> Cheers,
> Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003673.html
> [2]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
> [3]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-July/003643.html
> [4]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003685.html
> [5]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003686.html
> [6] https://eprint.iacr.org/2022/190.pdf
> [7] https://github.com/lightning/bolts/pull/851#issuecomment-1290727242
> _______________________________________________
> 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/20221121/ae6ba7de/attachment.html>

2023-06-09 13:07:17 UTC

- reply

📅 Original date posted:2022-11-07
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221107/6ca7c2c0/attachment-0001.html>

2023-06-09 13:07:16 UTC

- reply

📅 Original date posted:2022-11-03
📝 Original message:
Hi list,
We would like to share with you our recent research on jamming in
Lightning. We propose a combination of unconditional (~ upfront) fees and
local reputation to fight jamming. We believe this can be a basis for an
efficient and practical solution that can be implemented in the foreseeable
future.
The full paper is available [1].
We classify jams into quick (resolve in seconds, mimicking honest payments)
and slow (remain in-flight for hours or days). Fees disincentivize an
attack where quick jams are constantly resolved and sent again. Reputation,
in turn, allows nodes to deprioritize peers who consistently forward slow
jams.
We believe that our proposal is practical and efficient. In particular, we
have shown that the additional (unconditional) fees can be relatively low
(as low as 2% of the total fee) to fully compensate jamming victims for the
lost routing revenue. Moreover, the total unconditional fee paid for all
failed attempts stays low even if the failure rate is reasonably high. This
means that the UX burden of paying for failed attempts is also low. A
straightforward PoC implementation [2] demonstrates one approach to
implementing the fee-related aspect of our proposal.
Further sections provide more details on our approach and results.
# Jamming
As a reminder, jamming is a DoS attack where a malicious sender initiates
payments (jams) but delays finalizing them, blocking channels along the
route until the jams are resolved. Jamming may target liquidity or payment
slots.
We distinguish between quick and slow jamming. Quick jamming implies that
jams are failed and re-sent every few seconds, making them hardly
distinguishable from honest failing payments. In slow jamming, jams remain
in-flight for hours.
# Unconditional fees
We propose unconditional fees to discourage quick jamming. Currently, jams
are free because routing nodes don’t charge for failed payment attempts.
With unconditional fees, however, jamming is no longer free.
Our simulations indicate that unconditional fees don’t have to be too high.
Under certain assumptions about the honest payment flow, a fee increase by
just 2% (paid upfront) fully compensates a routing node under attack. Our
simulator is open-source [3]. A PoC implementation demonstrates one
approach to implementing unconditional fees and only requires minor changes
[2].
We have also considered the UX implications of paying for failed attempts.
We have concluded that this should not be a deal-breaker, as the total
unconditional fee paid stays low even if the failure rate is reasonably
high (even as high as 50%). Privacy and incentives are also discussed in
the paper.
# Reputation
Fees are not very effective in preventing slow jamming: this type of attack
requires only a few jams, therefore, fees would have to be too high to be
effective. Instead, we address slow jamming using local reputation.
As per our proposal, nodes keep track of their peers’ past behavior. A
routing node considers its peer “good” if it only forwards honest payments
that resolve quickly and bring sufficient fee revenue. A peer that forwards
jams, in contrast, loses reputation. Payments endorsed by a high-reputation
peer are forwarded on the best efforts basis, while other (“high-risk”)
payments can only use a predefined quota of liquidity and slots. Unless the
attacker has built up a reputation in advance, it cannot fully jam a
channel with at least some liquidity allocated exclusively to low-risk
payments. Nodes parameterize their channels according to their risk
tolerance.
# Alternatives and Future Work
In this work, we strive for a systematic approach. First, we list five
properties a potential mitigation strategy should have: effectiveness,
incentive compatibility, user experience, privacy and security, and ease of
implementation. Then, we go over the design decisions to be made when
constructing a countermeasure against jamming. Based on the desired
criteria and the available options, we converge on a solution.
Multiple approaches to jamming mitigation have been discussed on this list
and elsewhere. Many of them may well be worth exploring, such as
resolution-time-dependent fee amounts or stake certificates for reputation
building. However, we believe that our solution strikes a good balance: it
addresses the problem in question and is relatively straightforward to
implement.
We would love to bring this idea closer to implementation, and we plan to
discuss it over the next spec meeting [4] (Monday, 2022-11-07). We’d
greatly appreciate your feedback!
Kind regards,
Sergei and Clara
[1] -
https://github.com/s-tikhomirov/ln-jamming-simulator/blob/master/unjamming-lightning.pdf
[2] - https://github.com/sr-gi/rust-lightning/commit/ce606)
[3] - https://github.com/s-tikhomirov/ln-jamming-simulator
[4] - https://github.com/lightning/bolts/issues/1038
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221103/9ca4e3af/attachment-0001.html>

2023-06-09 13:04:23 UTC

- reply

📅 Original date posted:2021-11-15
📝 Original message:
Hi Joost,
A quick way to resolve this is to normalize the payment fees to a [0,1]
scale. Two natural ways to do this are the following.
0 in both of them is some maximum set by the user (maybe with some
reasonable default), 1 could be either the cheapest path or simply 0 sat.
Once we have normalized the fees to a [0,1] scale, we can proceed.
Let [image: \alpha] be the chosen balance parameter, [image: f] the
fee and [image:
p] the success probability. Then the score of a channel will be [image:
\alpha\cdot f + (1-\alpha)\cdot p]
Clara
On Mon, Nov 15, 2021 at 10:26 AM Joost Jager <joost.jager at gmail.com> wrote:
> In Lightning pathfinding the two main variables to optimize for are
> routing fee and reliability. Routing fee is concrete. It is the sat amount
> that is paid when a payment succeeds. Reliability is a property of a route
> that can be expressed as a probability. The probability that a route will
> be successful.
>
> During pathfinding, route options are compared against each other. So for
> example:
>
> Route A: fee 10 sat, success probability 50%
> Route B: fee 20 sat, success probability 80%
>
> Which one is the better route? That depends on user preference. A patient
> user will probably go for route A in the hope of saving on fees whereas for
> a time-sensitive payment route B looks better.
>
> It would be great to offer this trade-off to the user in a simple way.
> Preferably a single [0, 1] value that controls the selection process. At 0,
> the route is only optimized for fees and probabilities are ignored
> completely. At 1, the route is only optimized for reliability and fees are
> ignored completely.
>
> But how to choose between the routes A and B for a value somewhere in
> between 0 and 1? For example 0.5 - perfect balance between reliability and
> fee. But what does that mean exactly?
>
> Anyone got an idea on how to approach this best? I am looking for a simple
> formula to decide between routes, preferably with a reasonably sound
> probability-theoretical basis (whatever that means).
>
> Joost
> _______________________________________________
> 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/20211115/7e7f7ab4/attachment.html>