[Lightning-dev] Jamming Mitigation Call Summary - 03/06

[Carla Kirk-Cohen]

Hi list,

Writing with a summary from our latest jamming mitigations call.
Full transcript is available at [1].

Details for the next call:
* Tuesday 21 March @ 17:00 UTC - *please note change of day/time*
* https://meet.jit.si/UnjammingLN
* Agenda: https://github.com/ClaraShk/LNJamming/issues/9

## Housekeeping
The participants discussed the possibility of adding a rotating chair
for meetings, as suggested on the agenda issue [2]. There was no strong
preference to introduce the structure of a chair, and none of the
attendees volunteered to take on the role for the next meeting, so the
a decision was taken to leave the meetings structured around a communally
sourced agenda.

## Circuit Breaker Update
The circuit breaker UI is being redesigned for a more user friendly
experience, and to make it more mobile-friendly.

## Local Reputation
The majority of the meeting's discussion was centered around approaches
to local reputation tracking, as there have been multiple proposals
suggested on the mailing list.

### Specification
There was some general discussion around taking a simpler approach to
reputation before trying to propose more ambitious algorithms for
tracking whether a peer has "good" reputation. This suggestion aims
for a more pragmatic approach to the long-unsolved quagmire of jamming
mitigation proposals, and a way to make solutions more easily
observable to end users.

The reputation schemes that have been discussed so far depend on the
addition of an "endorsement" fields to update_add_htlcs to help peers
along around communicate whether they believe a HTLC is unlikely to be
part of a jamming attack. The possibility of starting without an
"endorsement" field was floated, though many participants believed that
it was an important part of informing forwarding decisions. Instead,
the possibility of simplifying the local reputation metric that is
used to decide whether a peer's behavior is considered "good" was
raised as a simplifying alternative.

### Upfront Fees
The question was posed whether we will need to introduce upfront fees
if we have an effective local reputation mechanism that can identify
bad behavior. Opinions varied. It was noted that the original
motivation for local reputation paired with upfront fees was to address
attackers that target their attack to sit just beneath a "good"
threshold. General consensus seemed to be that we should focus on
reputation first, with the goal of measuring how effectively we can
address spamming before endeavoring to add upfront fees to the protocol.

### Understanding of Attacks
Discussion also touched on the shifting landscape for the types of
attacks we are trying to mitigate - at present, a mitigation is
proposed and then we think about custom attacks for that exact solution.
Instead, it was suggested that we collect a set of different attack
strategies that we wish to defend against, then compare different
solutions effectiveness. The first, instinctual definition for an attack
being successfully defeated is that it is unable to disrupt honest
traffic.

We agreed to use an issue on the repo that is used to administer these
meetings to track various forms of attacks [3].

### Simulation and Testing
We spent some time discussing the availability of data and possibility
of using simulations to compare various approaches. A few approaches to
empirically examining the problem were discussed:
* "Shadow" deployment of a reputation metric, just logging outcomes, to
  see how it would work on nodes today.
* Data gathering on a collection of nodes in the network to feed into
  a more realistic simulation.
* Simulation of various payment flows using the real network graph.

One drawback that was noted is that we can't use real data to simulate
attacks, since the network is not under attack in the steady state, and
the challenge of realistically representing this type of traffic.

As always, thanks to all who attended!
Carla + Clara

[1] https://github.com/ClaraShk/LNJamming/pull/8
[2] https://github.com/ClaraShk/LNJamming/issues/5
[3] https://github.com/ClaraShk/LNJamming/issues/7
___
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

[Lightning-dev] Jamming Mitigation Call 02/20

[Carla Kirk-Cohen]

Hi List,

A reminder that we've got another jamming call coming up tomorrow.

Monday 20 Feb
19:00 UTC
https://meet.jit.si/UnjammingLN

We'll be talking about local reputation scoring.
Feel free to add additional agenda items here:
https://github.com/ClaraShk/LNJamming/issues/4

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

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

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

[Vincenzo Palazzo]

On Wed Feb 8, 2023 at 9:17 PM CET, Carla Kirk-Cohen wrote:
> Hi list,
>
> Unfortunately we had some technical issues with the recording for
> Monday's call so we're going to have to rely on my memory (a severely
> corrupted data store). Thankfully, Clara jotted down some notes as well,
> but please chime in if you attended and we've missed something out!
>
> Details for next call:
> * Monday 20 February
> * 18:00 UTC (possibly 19:00, be confirmed in a follow up email)
> * https://meet.jit.si/UnjammingLN
> * Agenda: https://github.com/ClaraShk/LNJamming/issues/3
>
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)?

>4. Reputation discussions in LSP Specification
>?Some attendees have been working on a reputation system for the LSP
>specification group [8]. This system is intended to provide standard
>metrics about what makes a node good/bad to connect to in the context
>of a decentralized marketplace. While this work looks at the problem
>from a different perspective, there's a possibility to consolidate
>the efforts. It seems particularly useful in the anti-jamming case
>where a node has newly connected to you, and needs a "start state"
>reputation score. The idea of defining what qualifies as good
>behavior in the Lightning Network is useful across the board. The
>LSP specification group also has bi-weekly calls, and welcomes
>additional participants!

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.

Cheers!

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

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

[Carla Kirk-Cohen]

Hi list,

Unfortunately we had some technical issues with the recording for
Monday's call so we're going to have to rely on my memory (a severely
corrupted data store). Thankfully, Clara jotted down some notes as well,
but please chime in if you attended and we've missed something out!

Details for next call:
* Monday 20 February
* 18:00 UTC (possibly 19:00, be confirmed in a follow up email)
* https://meet.jit.si/UnjammingLN
* Agenda: https://github.com/ClaraShk/LNJamming/issues/3

# Meeting Summary

1. Proof of Forwarding
We started the call with a discussion of the various "proof of
forwarding" schemes that have been kicked around this mailing list
in the past.

Working of the assumption that upfront fees must always be sourced
from the sender, we ran into similar issues around accumulated fees
and differential rates even in the case where we have some proof of
forward, because nodes can still choose to collaborate to "forward"
a payment.

Given the following topology and conditions:
Alice -- Bob -- Carol -- Dave - Evelyn

* Alice is sending a payment to Evenlyn, a popular sink on the network.
* Evenlyn has zero final-hop upfront fees (for simplicity's sake).
* Bob and Carol are malicious actors, each charging 10 msat upfront.
* Dave is an honest node with 4000 msat upfront fees (which is a rational
  upfront fee for a channel to a sink node that would have high success
  case fees).

Using a proof of forward scheme where Alice places a secret in the
_next_ node's onion which is required to claim upfront fees:
* Bob may claim 4020 msat in upfront fees with a secret from Carol
* Carol may claim 4010 msat in upfront fees with a secret from Dave
* Dave may claim 4000 msat in upfront fees with a secret from Evelyn

In the honest case, this nets out to 10 msat for Bob, 10 msat for
Carol, and 4000 msat for Dave. In the dishonest case, Carol can
disclose the forwarding secret to Bob, allowing them to claim the
accumulated 4020 sat, then fail the payment anyway.

We also spoke about the case where the downstream peer refuses to give
up the secret, but this breakdown in cooperation is likely remedied by
closing your channel. We didn't consider the case where upfront fees
do not accumulate along the route, because this exposes us to a whole
lot of (even worse) draining attacks.

We once again discussed the complexity of this nature of jamming
mitigation, how practical it would be to implement it and whether it
is worthwhile pursuing if it will be an imperfect solution to upfront
fee theft.

2. Upfront Fees + Attributable Errors
The next point of discussion was the combination of upfront fees with
attributable errors [1] to allow senders to more severely punish
nodes that choose to steal upfront fees rather than forward the HTLC
(due to the incentive issues noted in [2] when there are large fee
differentials across the route).

This led to a discussion about how effectively senders can enforce
good upfront fee behavior - a question that remains open. We discussed:
- Strict punishment of nodes that fail payments with upfront fees.
- Sender side protections against selection of routes with incentive
  incompatible upfront fees.
- The suboptimal, yet doable, solution of starting with an upper bound
  on upfront fees. This has the drawback of not properly compensating
  nodes that have a legitimate claim to high upfront fees because they
  face high opportunity cost.

3. Experimentation with Circuit Breaker
We discussed the possibility of using circuit breaker[3] in the context
of local reputation (or HTLC endorsement) in two different ways:
(a) To begin surfacing the type of information that end users would
require to decide to endorse a payment, and possibly automating
that decision making.
(b) In conjunction with an experimental TLV to add binary HTLC
endorsement to update_add_htlc, though it was noted that this
would require wider spread adoption of circuit breaker, because
nodes that do not have it installed would not include the TLV on
forwarding. This would also require LND changes to surface TLVs
included with update_add_htlc on the interceptor API.

As always, thank you to all that attended and hope to see ya'll in the
next one!

Best,
Carla + Clara

[1] https://github.com/lightning/bolts/pull/1044
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003834.html
[3] https://github.com/lightningequipment/circuitbreaker
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Jamming Mitigation Call Summary - 01/23

[Antoine Riard]

Hi Clara,


>  * They will likely require a network wide upgrade: when a sender

>makes a payment, the full path will need to understand the new

>feature bit for it to be used.


I believe the upgradeability dimension is different both for circuit breaker
and staking credentials -- Circuit breaker is a point-level deployment and
can be rolled out without cooperation of the channel peers. Staking
credentials is end-to-end and just requires cooperation between endpoints
(HTLC senders and routing hops, not even all on the payment paths).


And I think upfront fees is a link-level one, probably the one requesting the
most cooperation between the community of developers/node operators.


Point-to-point/end-to-end deployment already provides benefits with
"half-state"
deployment, I think. However, you might have "holistic" beneficial effects
of link-level solutions (in terms of economic engineering not in terms of
software compatibility), I don't know.


>  * Sending nodes are unlikely to be incentivised to upgrade to

>support a channel jamming mitigation, as jamming mitigations incur

>additional cost (be it in the form of upfront fees, tokens or some

>other mechanism).


As with any "unpatched" security risks we're encumbering on Lightning
(pinnings, time-dilation, etc), beyond clearly describing the attack in
reference documents and proof-of-concept of the attack against
implementations, the next step to keep raising awareness is a live demo as
much near as one can from really mainet conditions. While we were patching
CVE-2021-41591 and friends, I've been testing the solidity of the fixes on
the Eclair-side in a "black-box" manner. Always worth it, you learn on the
attack bounds.


We could do the same with jamming attacks, as there is a wide-range of
scenarios
to consider (network-wide/merchant/routing hops) and few optimizations
tricks like looping. Just have to be super careful with any demo exploits
toolchain, there is always a question of ethics here.


>  * Routing nodes have no way of knowing whether a payment comes from

>a node that is not upgraded, or simply doesn't want to pay the

>additional cost introduced by a jamming mitigation.


I think a routing node able to know if the payment sender has upgraded could
constitute a version/implementation fingerprint and a downgrade in HTLC traffic
privacy, ideally a routing node should not be able to link payeer/payee.


If a sender does not want to pay the jamming mitigation cost, it might be a
flaw in the incentive-compatibility benefit of a mitigation.


(And in terms of evaluating the
incentives-compatibility/economic-efficiency of any solution, we're going
to run quickly in hard questions of economic methodology, a bit beyond the
software engineering realm).


> It was generally agreed that the network is still in an early enough

> stage that it is fair for relaying nodes to initially upgrade but not

> enforce the feature, and later look at forwarding traffic to determine

> whether it is appropriate to require the feature.


If we look at the recent history of mempool policy upgrades on the
Bitcoin Core-side,
I think it's best practice to be more conservative in terms of "smooth
feature" deployment, even feature-gated beyond some node operator setting. At
time of feature enforcement, some node operators might claim an established
claim on other flows of HTLC traffic, and there would be a question of
backward-compatibility arising.


Independently, there is the fact on how discrepancies in feature activation
could be exploited (privacy-wise or economically-wise). Same issue we have
on the Bitcoin Core-side, when we update the mempool policy, and old nodes
might not see new types of outputs (e.g Taproot spends being non-standard
before the activation iirc).


> This will require sending nodes to opt-in to the new feature before the
network can

> widely enforce it, as no rational routing node will require a feature

> which would reduce its ability to serve un-upgraded traffic (unless

> under attack, which is not the case at present).


I think the corollary holds -- A rational routing node will not require a
feature which would reduce its ability to serve upgraded traffic.


Note, I think the "rational" routing node could be better defined,
otherwise I think we'll run quickly in the same bottlenecked discussions
about "policy rules" compatible with miners incentives, as we're seeing on
the Core-side. So far, I don't think we have a consistent model of miners
incentives.


> A note was also made that wallets tend to upgrade less frequently, in

> part because some providers run forked versions of LN implementations,

> so this horizon may be quite long. It was emphasized that this type of

> network upgrade would require input from wallets, designers and

> application developers anyway, so hopefully by the time we look to

> deploy a change there is rough consensus among the Lightning community

> already.


Yeah, we 

Re: [Lightning-dev] Jamming Mitigation Call Summary - 01/23

[Antoine Riard]

(Reply 2/2)

>  * Whether we should look into a more complicated approach that

>includes a "proof of forward" secret in the next node's onion which

>must be supplied to claim the upfront fee.


One of the hard things with a "proof of forward" is a hop colluding with
the next counterparty in way non-provable to the HTLC sender. I don't think
more reliable onion errors will save the mechanism, as you might always
masquerade your routing node offliness (sure -- it might be penalized by
routing algorithms still probably a period of grace exploitable)


>  * Whether Bob _would_ steal the upfront fee by dropping the payment,

>as it'll impact nodes' desire to route through them in future.


And if you have "floating" upfront fees to adjust to routing node
opportunity cost and the routing algorithms historical buckets are not
correcting the variations, a "upfront fee" adversary might be able to steal
the amount, in a proportion not corrected by the penalty.


>  * Is there a way to deliver upfront fees to nodes along the route

>*without* them adding up along the route (other than the naive

>version of sending each hop a payment, which comes with its own

>problems)? Seems not, but bright ideas are wanted and welcome!


I think the latest update of the Staking Credentials could answer such
description
of "delivering the upfront fees to nodes along the route *without* them
adding up along the route" as the credential issuance is separated from its
redemption.


On a few other ideas, "magically" teleporting the fee payment to the
routing hops, it has been browsed in the past [2].


>  * That nodes will decide where they fall in the trade-off of setting

>upfront fees to cover their opportunity cost for high routing fees

>and market pressure to keep these fees low for the sake of

>remaining competitive.


They will probably need to do real-time monitoring of the congestion rates
and outcome results of their HTLC forwarding to adjust in consequence their
routing fees.


>   * A taproot tree for all HTLCs where each leaf has a subset of HTLCs,

> and fees could be incorporated here (summary note: apparently some

> work has been done here, but I couldn't find the link).


The idea of summing up the taproot tree for all HTLCs is discussed here
with past references [3]. I don't know if it's really a viable direction,
as aggregating the claim of HTLCs of different values in the same witness
claims might open the door to transaction-relay games.


>   * If we're confident that a more complicated solution will solve many

> problems, then we should pursue them, otherwise a simple solution

> is possibly a _good enough_ first step.


If the "proof of forward" can be solved by "magic" covenant is still an open
issue. I don't know if it's a viable solution as it's more a hard synchronicity
issue between chain of contracts. However from exploring issue we might
learn interesting design considerations for contracting protocols (at the
very least some semi-formal proof it's not possible)


>  * Should our first attempt at solving this issue be for a future

>steady state where nodes have significant traffic and nodes face

>real opportunity cost (in the form of lost revenue) if they are

>targeted by a jamming attack?


Deferring the most economically-efficient solution we can come from, we might
run into a bunch of incentives-misallignment between generation of nodes
operators and Lightning use-cases. Maybe same as we have seen with lack of
transaction replacement, first-seen RBF, opt-in RBF, mempoolfullrbf, I
believe.


On the other-side, the deployment of a simple solution would enable us to
start to build a consistent model of how the economics of channel
congestion, that we can "transpose" for more advanced solutions (ideally --
all other things being equal).


>  * While circuit breaker isn't necessarily *the* solution to solving

>jamming on LN, it provides us with some data points and a

>practical way for individual operators to address spamming of

>their nodes.


As mentioned above, it sounds like the congestion monitoring and HTLCs
resolution tracking is going to be a standard task among LN
implementations, and that you'll would probably need a piece of
infrastructure like circuit breaker for all implementations.


> Since our last discussion an architecture document was added to the

> proposal [6], details in the mailing list post [7]. The main goal is

> to try to dissociate the people paying the fees from those gaining the

> benefits from the credentials, so that credentials can be paid by a

> LSP (for example).


I think there is a missing footnote, I believe the mail thread might have
been this one:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003822.html


Beyond delegation as mentioned, there are few other design goals targeted:

- strong economic-efficiency due to credentials accumulation

- fungibili

Re: [Lightning-dev] Jamming Mitigation Call Summary - 01/23

[Antoine Riard]

Hi Clara,


(Reply 1/2 - Apparently there is a limit of 80KB on Lightning mailing post)


>  * They will likely require a network wide upgrade: when a sender

>makes a payment, the full path will need to understand the new

>feature bit for it to be used.


I believe the upgradeability dimension is different both for circuit breaker
and staking credentials -- Circuit breaker is a point-level deployment and
can be rolled out without cooperation of the channel peers. Staking
credentials is end-to-end and just requires cooperation between endpoints
(HTLC senders and routing hops, not even all on the payment paths).


And I think upfront fees is a link-level one, probably the one requesting the
most cooperation between the community of developers/node operators.


Point-to-point/end-to-end deployment already provides benefits with
"half-state"
deployment, I think. However, you might have "holistic" beneficial effects
of link-level solutions (in terms of economic engineering not in terms of
software compatibility), I don't know.


>  * Sending nodes are unlikely to be incentivised to upgrade to

>support a channel jamming mitigation, as jamming mitigations incur

>additional cost (be it in the form of upfront fees, tokens or some

>other mechanism).


As with any "unpatched" security risks we're encumbering on Lightning
(pinnings, time-dilation, etc), beyond clearly describing the attack in
reference documents and proof-of-concept of the attack against
implementations, the next step to keep raising awareness is a live demo as
much near as one can from really mainet conditions. While we were patching
CVE-2021-41591 and friends, I've been testing the solidity of the fixes on
the Eclair-side in a "black-box" manner. Always worth it, you learn on the
attack bounds.


We could do the same with jamming attacks, as there is a wide-range of
scenarios
to consider (network-wide/merchant/routing hops) and few optimizations
tricks like looping. Just have to be super careful with any demo exploits
toolchain, there is always a question of ethics here.


>  * Routing nodes have no way of knowing whether a payment comes from

>a node that is not upgraded, or simply doesn't want to pay the

>additional cost introduced by a jamming mitigation.


I think a routing node able to know if the payment sender has upgraded could
constitute a version/implementation fingerprint and a downgrade in HTLC traffic
privacy, ideally a routing node should not be able to link payeer/payee.


If a sender does not want to pay the jamming mitigation cost, it might be a
flaw in the incentive-compatibility benefit of a mitigation.


(And in terms of evaluating the
incentives-compatibility/economic-efficiency of any solution, we're going
to run quickly in hard questions of economic methodology, a bit beyond the
software engineering realm).


> It was generally agreed that the network is still in an early enough

> stage that it is fair for relaying nodes to initially upgrade but not

> enforce the feature, and later look at forwarding traffic to determine

> whether it is appropriate to require the feature.


If we look at the recent history of mempool policy upgrades on the
Bitcoin Core-side,
I think it's best practice to be more conservative in terms of "smooth
feature" deployment, even feature-gated beyond some node operator setting. At
time of feature enforcement, some node operators might claim an established
claim on other flows of HTLC traffic, and there would be a question of
backward-compatibility arising.


Independently, there is the fact on how discrepancies in feature activation
could be exploited (privacy-wise or economically-wise). Same issue we have
on the Bitcoin Core-side, when we update the mempool policy, and old nodes
might not see new types of outputs (e.g Taproot spends being non-standard
before the activation iirc).


> This will require sending nodes to opt-in to the new feature before the
network can

> widely enforce it, as no rational routing node will require a feature

> which would reduce its ability to serve un-upgraded traffic (unless

> under attack, which is not the case at present).


I think the corollary holds -- A rational routing node will not require a
feature which would reduce its ability to serve upgraded traffic.


Note, I think the "rational" routing node could be better defined,
otherwise I think we'll run quickly in the same bottlenecked discussions
about "policy rules" compatible with miners incentives, as we're seeing on
the Core-side. So far, I don't think we have a consistent model of miners
incentives.


> A note was also made that wallets tend to upgrade less frequently, in

> part because some providers run forked versions of LN implementations,

> so this horizon may be quite long. It was emphasized that this type of

> network upgrade would require input from wallets, designers and

> application developers anyway, so hopefully by the time we look to

> deploy a change 

[Lightning-dev] Jamming Mitigation Call Summary - 01/23

[Carla Kirk-Cohen]

Hi list,

On Monday last week we resumed our fortnightly channel jamming
mitigation calls for 2023.

Details for the next call:
* Monday 02/06 @ 18:00 UTC
* https://meet.jit.si/UnjammingLN
* Agenda: https://github.com/ClaraShk/LNJamming/issues/2

# Meeting Summary
This email attempts to summarize the discussion, but is of course
subject to my errors and opinions so the full transcript is available
at [1]. It is (imperfectly) AI generated, so please reach out to myself
or Clara if you'd like clarification for a specific section.

1. Upgrade Mechanisms
The first topic of discussion was around how we would go about
upgrading the network to support an anti-jamming mitigation. Most
solutions share the following characteristics:
  * They will likely require a network wide upgrade: when a sender
makes a payment, the full path will need to understand the new
feature bit for it to be used.
  * Sending nodes are unlikely to be incentivised to upgrade to
support a channel jamming mitigation, as jamming mitigations incur
additional cost (be it in the form of upfront fees, tokens or some
other mechanism).
  * Routing nodes have no way of knowing whether a payment comes from
a node that is not upgraded, or simply doesn't want to pay the
additional cost introduced by a jamming mitigation.

It was generally agreed that the network is still in an early enough
stage that it is fair for relaying nodes to initially upgrade but not
enforce the feature, and later look at forwarding traffic to determine
whether it is appropriate to require the feature. This will require
sending nodes to opt-in to the new feature before the network can
widely enforce it, as no rational routing node will require a feature
which would reduce its ability to serve un-upgraded traffic (unless
under attack, which is not the case at present).

A note was also made that wallets tend to upgrade less frequently, in
part because some providers run forked versions of LN implementations,
so this horizon may be quite long. It was emphasized that this type of
network upgrade would require input from wallets, designers and
application developers anyway, so hopefully by the time we look to
deploy a change there is rough consensus among the Lightning community
already.

2. Upfront Fees
Next, we discussed the draft proposal for upfront fees [2] that
implements the first of a two-part jamming mitigation described in [3].
As it stands, the PR describes the simplest possible way to introduce
upfront fees to the protocol:
  * Upfront fees are expressed as a ppm of a channel's success-case
fees, and charged on the outgoing link of a route.
  * Nodes can advertise custom upfront fee rates if desired, but to
save gossip bandwidth we assume a network-wide default of 1%.
  * Upfront fees accumulate along the route (as htlc payment amounts
do), and are simply pushed to the `to_remote` balance on
`update_add_htlc`.
  * Final hop nodes advertise an upfront fee policy in bolt 11 invoices
(or bolt 12 blinded routes) which is sufficiently padded to
obfuscate their location in the route.

The interaction between upfront fees and possible future protocol
changes such as inbound fees and negative fees was briefly discussed,
specifically the case where a node sets low (or negative) fees to
attract traffic then fails payments to accumulate upfront fees. As is,
all implementations’ algorithms optimize for factors other than fees -
specifically avoiding a node once it's produced failures - and we
suspect that careful sender-side behavior will mitigate this risk.
However, it was also acknowledged that a node that attempts this attack
may be able to fool multiple individual senders and still be able to
accumulate some fees.

We then discussed the shortcomings of the "simplest possible" upfront
fees in [2], specifically focused on the following scenario where
nodes receive 1% of their success-case fees as an upfront payment:
  * Alice is sending a payment to Dave, who is a popular sink node in
the network.
  * Bob -> Carol has low/default routing policy: 1000 msat success
case / 10 msat upfront fee
  * Carol -> Dave has high fees: 400,000 msat success case / 4000 msat
upfront fee
  * Dave advertises no success case fee (is recipient) / 100 msat of
upfront fee chosen for his invoice.

Alice -- Bob -- Carol -- Dave

Since we need to source all of these funds from the sender (Alice), the
forwarding of funds is as follows:
  * Alice pushes 4110 msat to Bob.
  * Bob _should_ push 4100 msat to Carol, claiming his 10 msat upfront
fee.
  * Carol _should_ push 100 msat to Dave, claiming her 4000 msat
upfront fee.

However, Bob has no real incentive to forward the HTLC to Carol and
push her the 4100 msat because that value is more than the fees he'll
earn from successfully forwarding and settling the HTLC (10 msat
upfront fees + 1000 msat success case fees). It's worth noting that
this type of fee differential al

[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

[Loki Verloren via Lightning-dev]

Hi,

I am quite busy and focused on developing the Indranet lighting monetised onion 
relay network project, but I dropped my 2c in the hat relating to this, I just 
wanted to make a comment regarding related spam mitigation strategies which 
also form the basis of my project.

When nodes in the network will not process data in a message without being 
paid, the cost of spamming useless data rises dramatically. The asymmetries 
that can exist between generating data and processing it lead to 
vulnerabilities, not just DoS of network but attacking memory and processing 
capacity of nodes.

Might I suggest that if the idea of charging for services existed, and a scheme 
for accounting the consumption of pre-paid service were to exist, similar to 
the one I am devising for Indra, it would have the same benefit also for 
Lightning network in general: potential to earn a strongly guaranteed margin of 
profit, and that leading to the eventual growth of the network as it isn't a 
loss-leader investment. Wherever the economics favor attackers, making such 
services paid only or paid plus a dribble of free service, like the Bitcoin 
mempool, attackers will look elsewhere for easy prey.

I will be keeping an eye on how security protocols develop with LN and hope to 
be able cross-pollinate where things intersect. I do think that onion routing 
is a loss-leader unless it has anonymous payments in it, and anonymous payments 
themselves are a utility for LN. 


- l0k1

> Subject: Re: [Lightning-dev] Jamming mitigation call
> Message-ID:
> CALZpt+GsNhZcv1u6_hjgt=1WpGE0nE5ygqHN3EUhjHTO9T=y...@mail.gmail.com
> 

> Content-Type: text/plain; charset="utf-8"
> 

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

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

Re: [Lightning-dev] Jamming mitigation call

[Antoine Riard]

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

[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