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

[Antoine Riard]

Hi Clara, Sergei

Congrats for the paper!

Here are a few in-flight thoughts browsing the paper.

On introducing a general framework for evaluating attack mitigations, I
think this is relevant as scarce resources wastes, of which jamming is a
subcase is echoed multiple times not only in Lightning, but in multiple
other L2 protocols. For Lightning: at channel peer selection, or for any
multi-party operation like a dual-funded or splicing, the timevalue of the
UTXOs committed can be wasted by a lazy or malicious counterparty. For
Coinjoin/Swaps: again UTXO opportunity cost can be wasted, or a swap HTLC
holded for nothing. I hold the hope that any solution we can nurture for
jamming could be reused and refined in other Bitcoin "decentralized
financial networks".

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

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.

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.

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

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.

On the analysis of the unconditional fee, I think my main objection would
be the lack of integration of the time uncertainty of the honest use-cases,
making it hard to classify between quick and slow jamming. As you say "The
borderline between quick and slow jamming depends on a subjective
definition of the maximal honest payment resolution delay" An attacker
should hold all its HTLC jamming for a duration of "maximal honest payment
resolution delay" minus 1. Without even scoping L2s protocol like s

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 don't

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

[Thomas HUET]

Hi,

I agree that the local reputation solution is very promising (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). What I really
like about it is that it's quite simple and can be quickly deployed without
even needing to coordinate with others or upgrade the network.
I had a similar idea but your solution adds a "I endorse this payment" bit
which I think can make the method a lot more effective (and unfortunately
breaks the "can be deployed without upgrading the network" but I think it's
worth it). 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.
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.
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.

Thanks for your work.
Thomas

Le lun. 7 nov. 2022 à 19:23, Clara Shikhelman 
a écrit :

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

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

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

[Matt Corallo]

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.MattOn 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/UnjammingLNPlease 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.# JammingAs 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 feesWe 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.# ReputationFees 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 

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

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

[Matt Corallo]

On 11/15/22 12:09 PM, Clara Shikhelman wrote:
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,


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.


and in general nodes shouldn't be motivated to send a lot of failed payments, and should adopt 
better routing strategies.


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.


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

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

[Michael Folkson via Lightning-dev]

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

Right, the trade-offs here are really tricky to navigate and to whatever extent 
this is possible the choice of what trade-offs to make should be pushed to the 
user. For example, not knowing the real time channel balances clearly hurts 
routing success. If this degraded routing success from 95 percent to say 90 
percent the network as a whole would probably be willing to pay that routing 
success "cost" to ensure better balance privacy. But if it degraded routing 
success from 95 percent to say 50 percent I expect much of the network wouldn't 
be willing to put up with that terrible routing success percentage and routing 
nodes would probably seek to broadcast their channel balances either in gossip 
or out of band.

Similarly a routing node not knowing the source of the payment and the 
intermediate nodes on the route is fine (it is clearly *much* better for 
privacy) assuming jamming attacks occur rarely. But if the network is being 
paralyzed regularly by jamming attacks a routing node is going to show a lot 
more interest in which Lightning node it is routing payments for and which 
other Lightning nodes are also part of the route. You aren't going to want to 
continue to be subject to jamming attacks by the same Lightning node.

Hence I stick by this from a protocol developer perspective.

"Decisions protocol developers make will impact what data can be collected and 
how easy that data is to collect (there are already some tricky trade-offs with 
regards to privacy, routing success and transparency for when things go wrong) 
but beyond that protocol developers should leave it to others."

A protocol developer (and individual implementation developer I guess) is going 
to have to wrestle with these trade-offs and to what extent options can be 
pushed to the user. But protocol reputation tokens that can be sold or 
transferred to an attacker or worse collected through gaming the system, ouch. 
The protocol developer has taken a problem (jamming attacks) that already 
exists and added an additional problem (reputation) which no doubt will be 
addressed by adding an additional problem on top of that and another on top of 
that etc etc.

--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3


--- Original Message ---
On Sunday, December 4th, 2022 at 02:03, Matt Corallo  
wrote:


> 
> On 11/15/22 12:09 PM, Clara Shikhelman wrote:
> 
> > 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,
> 
> 
> 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.
> 
> > and in general nodes shouldn't be motivated to send a lot of failed 
> > payments, and should adopt
> > better routing strategies.
> 
> 
> 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.
> 
> Matt
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev