Re: [Lightning-dev] LN Summit 2023 Notes

[Clara Shikhelman]

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 

Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation

[Clara Shikhelman]

Hi,


> Sure, I understand that in case of an attack, a routing node should have
> been paid a significant fee sum by the peer originating the jamming
> traffic. However from my understanding this is unclear with the proposed
> htlc endorsement system than the fees paid are fully economically
> compensating the damage inflicted to the victim ?
>

The only damage we can observe in the protocol is routing fees. If we go
ahead with our suggestion, it will straightforward to choose a different
threshold based on the preference of a node. We have some suggestions for
receiving nodes, for example.


> Or if it's a proportional compensation, and if proportional the ratio
> between the fees and the reputation is static or dynamic, and if dynamic
> which are the criterias of evaluation ?
>

The difficulty to gain reputation is proportional to the amount of damage
that can be inflicted.


>
> Note, outlawing the cost of the attack from the system guarantees sounds
> contrary to the htlc endorsement design goal shown in your gist: "the goal
> of this proposal is to produce a mitigation that has...a significant cost
> to persistent attackers", or are the design goals proposed elsewhere ?
>

 "A significant cost", unlike right now where it's practically free.
Because we don't know how deep are the pockets of the attacker, our focus
is on compensating the victim.


> So I still don't know the precise problem to be solved by any jamming
> mitigation, in a formal fashion, nor the correctness conditions required of
> a solution. As far as I can tell, such information is not present in the
> "unjamming lightning" paper (while the paper claims to "systematically
> analyze the solution space" it does not formalize the problem, at least in
> terms of abstract definition that holds independently of the solution
> adopted).
>
I think there is still an undervaluation of how much the liquidity griefing
> issues affecting Lightning and second-layers, of which jamming is only one,
> is novel from the viewpoint of financial cryptography/computer security
> literature. At the best, I think we should aim to evaluate the
> effectiveness of any jamming solution with the same conceptual rigor as
> modern cryptanalysis (understood notions like shannon cipher, perfect
> security, switching lemma).
>
Without such rigor of analysis, I don't think we'll be able to give
> "measurable" bounds to any solution, and know when there is a wreckage
> because we're modifying some subtle parameters like channel opening
> default, or the adversaries can access superior sources of information to
> decide when to launch a jamming attack where the sum paid does _not_ cover
> the operational cost of a routing hop.
>

Because a lot of the criteria are "soft" (UX, ease of implementation), we
cannot prove theorems. We are working on further simulations for the
quantifiable criteria, to see if theory meets practice.
Note that DDoS attacks are notoriously difficult to mitigate (see [0], for
example), so we are trying to do our best in the context of lightning using
the available tools.


> So if you recognize that htlc endorsement can fluctuate the link-level
> liquidity more than it does now, at the very least it would be good to come
> with simulations on how it might downgrade HTLC routing traffic ?
>

Simulation running as we speak.

Best,
Clara

[0]
https://www.sciencedirect.com/science/article/abs/pii/S1389128603004250?casa_token=BauKTUZ1yEYA:Ny9OvPXunkvLZgJD1bYQ_amV-rsMVRbYKozWchYB9ZpFZ3dNFfJnK74UYl7di9R24aDhrw
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation

[Clara Shikhelman]

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
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation

[Clara Shikhelman]

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

>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

[Lightning-dev] Jamming call May 15th

[Clara Shikhelman]

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
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation

[Clara Shikhelman]

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
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation

[Clara Shikhelman]

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
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming

[Clara Shikhelman]

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.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

[Lightning-dev] Jamming Mitigation Call Today

[Clara Shikhelman]

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

See you soon!
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming

[Clara Shikhelman]

> 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.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming

[Clara Shikhelman]

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  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 
> 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?
>>
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming

[Clara Shikhelman]

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?
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Local Reputation to Mitigate Slow Jamming

[Clara Shikhelman]

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  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.shikhel...@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.
>>
&

[Lightning-dev] Local Reputation to Mitigate Slow Jamming

[Clara Shikhelman]

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

Re: [Lightning-dev] Jamming Mitigation Call Summary - 02/06

[Clara Shikhelman]

Hi Vincent,

Thanks to write this down, do you think that it is a good idea
> to make a public google calendar (or other kind of shared calendar)?
>

Let's try this out:
https://calendar.google.com/calendar/u/2?cid=Mjc1ODRlNDNhMjE4NDQyYWMyN2JiZDY4NTlkNWQyZTU5ZWE3NGJiMWM2Mzk4Y2VmMzNhYTcwYWYzYjZjOTc2OEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t


There is also an ongoing attempt to define a kind of standard
> for the lightning network metrics started more thatn 1 year
> ago, and I also discussed in Oakland (but maybe some people
> was scared by the word `server`)
>
> The source code is available here https://github.com/LNOpenMetrics
> and for now the basic idea is to collect some data from different
> kind of node and analyze them before taking any decision to define
> any kind of protocol support via BOLT or BLIPS (I also I'm more inclined
> to a BLIPS because I think that different kind of node mobile vs LSP)
> can deserve different kind of metrics/reputation.
>
> There are some data already accessible via public API (for now)
> https://api.lnmetrics.info
> where it is possible to see some forwarding payment scoring by channels
> and node
> uptime.
>
>
This could be very useful, thanks for pointing it out!

Best,
Clara
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

[Lightning-dev] Jamming mitigation call for 2023

[Clara Shikhelman]

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
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Jamming mitigation call

[Clara Shikhelman]

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 
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 
> 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.shikhel...@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
>>

Re: [Lightning-dev] Jamming mitigation call

[Clara Shikhelman]

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 
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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Unjamming lightning (new research paper)

[Clara Shikhelman]

Hi Matt,



> Indeed, it may be explainable, but its still somewhat painful, I think. I
> do wonder if we can enable
> probing via a non-HTLC message and do immediate pre-send-probing to avoid
> paying upfront fees on
> paths that will fail.
>
>
This could be a good idea, but I think that it shouldn't be a prerequisite
for unconditional fees.


> I don't think so - today there are at least three different routing goals
> to maximize - (a) privacy,
> (b) fees, (c) success rate. For "live" payment, you probably want to lean
> towards optimizing for
> success rate, and many nodes do today by default. But that isn't the full
> story - many nodes do
> background rebalancing and they prefer to take paths which optimize for
> fees, trying many paths they
> think are likely to fail to see if they can rebalance with lower fees. I
> don't think we should tell
> those users/use-cases that they aren't allowed to do that or they're doing
> something "wrong" - I
> think choosing to optimize for fees (or, in the future, privacy) is an
> important thing to allow, and
> ideally make as reliable as possible, without charging extra for it.
>

I agree that fees and privacy are important, and play a bigger role in
transactions that are not very time sensitive. That being said, locking up
funds in channels knowing that with a decent probability the nodes along
the route won't be compensated at all is not great. If it's on a small
scale, we don't have to think about this as "wrong". The sender is asking
the nodes along the route to provide a service (lock up funds and provide
information about liquidity) and is paying a small fee for it.

Speaking of "wrong" - on Monday we'll be discussing further parameters to
be considered in reputation schemes. I think that your input will be very
valuable.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

[Lightning-dev] Jamming mitigation call

[Clara Shikhelman]

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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Clara Shikhelman]

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  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 
> 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 
>> 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.shikhel...@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 
>>>> 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.shikhel...@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
>>>>>>
>>>>>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Clara Shikhelman]

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 
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 
> 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 
>> 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.shikhel...@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
>>>>
>>>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Clara Shikhelman]

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 
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 
> 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
>>
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Clara Shikhelman]

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
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch

[Clara Shikhelman]

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

Re: [Lightning-dev] Unjamming lightning (new research paper)

[Clara Shikhelman]

Thanks to everyone that came to the meeting, it was a great conversation
and gave us a lot to think about!

Matt – I don't know that I agree with "... upfront payments kinda kill the
lightning UX ...". I think that upfront fees are almost essential, even
outside the context of jamming. This also helps with probing, general spam,
and other aspects. Furthermore, I think that the UX is very explainable,
and in general nodes shouldn't be motivated to send a lot of failed
payments, and should adopt better routing strategies.

About Rusty's suggestions, I plan to look at it again, but if I
remember correctly, there are privacy issues there.

I agree that we should tread carefully and not rush into things, let's keep
discussing this. I'll try to set up another meeting sometime soon.

On Mon, Nov 14, 2022 at 4:39 PM Matt Corallo 
wrote:

> Thanks for committing all the time today. I’m much happier with (binary,
> not-so-)local reputation than I was in the past, at least as better than
> other reputation systems.
>
> I believe you’ve stated a few times that local reputation by itself is far
> from sufficient and that’s why we need upfront payments. Intuitively this
> makes sense to me but I’m sure you have more data to back that up. It’s
> come up a few times that upfront payments kinda kill the lightning UX if
> they’re at all nontrivial. Just restating here to make sure we’re on the
> same page.
>
> One thing I think we need to research more is how this compares to Rusty’s
> old proof-of-channel-closure idea. Philosophically it’s quite nice to
> punish the one holding an HTLC over punishing the sender, especially in a
> world where people are getting options in USD<->BTC through HTLCs or
> sending to mobile nodes that sit on payments. Practically I’m not sure if
> there’s a strong need to worry about a large hub sitting on HTLCs to jam
> instead of a sender  being involved, but having zero mitigation against it
> also seems wrong.
>
> As always I’m a bit dubious of doing something, especially that required
> network-wide upgrade, until we’re confident it’s the right direction. Even
> binary HTLC reputation flags, I think, carry a very large privacy cost so
> it’s strongly worth exploring every alternative before we commit.
>
> Matt
>
> On Nov 10, 2022, at 10:35, Clara Shikhelman 
> wrote:
>
> 
> Hi all,
>
> We are planning a call to discuss this proposal further. It will be on
> Monday the 14th, at 7 pm UTC here:
> https://meet.jit.si/UnjammingLN
>
> Please let me know if this conflicts with any other Bitcoin event.
>
> Hope to see you all there!
>
> On Thu, Nov 3, 2022 at 1:25 PM Clara Shikhelman <
> clara.shikhel...@gmail.com> wrote:
>
>> 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 u

Re: [Lightning-dev] Unjamming lightning (new research paper)

[Clara Shikhelman]

Hi all,

We are planning a call to discuss this proposal further. It will be on
Monday the 14th, at 7 pm UTC here:
https://meet.jit.si/UnjammingLN

Please let me know if this conflicts with any other Bitcoin event.

Hope to see you all there!

On Thu, Nov 3, 2022 at 1:25 PM Clara Shikhelman 
wrote:

> 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

Re: [Lightning-dev] Unjamming lightning (new research paper)

[Clara Shikhelman]

Hi,

Thanks for your comments!

 (I'm less convinced about the unconditional fee as it changes a core
> principle of the network which means that we'll never reach consensus on
> it).
>

I think this is a core principle that opens the network to several attacks
and should be changed. Furthermore, there will be nothing stopping nodes
from setting their unconditional fee to zero, if they wish to take the risk.


>  However if we change the protocol, we may as well make it a continuous
> risk score instead of a binary low/high-risk. Also, having only two classes
> (high and low-risk) protects the the low-risk class but makes the high-risk
> class even easier to attack, having a continuous policy should mitigate
> this problem.
>

Could you elaborate on how having more than two classes help? It seems to
me that if you have a limit on the resources, you are easier to jam anyway.
The main advantage of having two classes is that it's simpler.


> And while I agree with the general idea of throttling based on a local
> reputation, I think we need more work to find a good formula to compute
> this reputation. I don't have a good formula myself but relying on "A
> satoshis per second" doesn't seem wise. There are huge disparities between
> nodes and even for a given node, traffic is fluctuating a lot. I think a
> more reliable indicator would be the proportion of successful payments.
>

It is important that gaining a good reputation would be difficult. For
example, if I only need a high proportion of successful payments, I can
just send a single one and gain a 100% success rate. Maybe a better wording
would be "X satoshis in fees during a time period of Y"


> The beauty of this solution is that we don't need a standardized formula
> for reputation, everyone can use its own. However getting a good one is
> hard so we need a default recommandation.
>

As different nodes have different needs and different risk preferences, I'm
slightly hesitant to give a general default. We can think about different
profiles and offer several options.


Thanks again,
Clara
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Unjamming lightning (new research paper)

[Clara Shikhelman]

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 

[Lightning-dev] Unjamming lightning (new research paper)

[Clara Shikhelman]

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
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org

Re: [Lightning-dev] Route reliability<->fee trade-off control parameter

[Clara Shikhelman]

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  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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev