René Pickhardt [ARCHIVE] on Nostr: 📅 Original date posted:2023-01-01 📝 Original message: Happy new year dear ...
📅 Original date posted:2023-01-01
📝 Original message:
Happy new year dear fellow Lightning Network Developers,
last month I have made a small observation why we probably should at most
progress EITHER with `negative fees` [1] OR `upfront fees` [2] but not with
BOTH as adding both features to the protocol would result in a potentially
lucrative attack that I will describe here.
Assumption:
=========
For simplicity of the argument please assume all nodes do payment delivery
by optimizing purely for fees instead of probabilistic payment delivery or
a combination of these two and potentially other features in their cost
function. The Argument will however work as long as fees are part of the
cost function.
The Attack:
=========
1. Malory sets the routing fees of her channel(s) sufficiently negative.
2. Now the cheapest route for all possible payment pairs on the network
goes through Malory.
3. Malory will accept any incoming HTLC but will shortly after the HTLC is
locked in fail the payment without forwarding.
( 4. Depending on the design of upfront fees she may need a collaborating
proxy node)
Outcome:
========
1. After announcing the negative routing fees every node that has seen the
`channel_update` will route through Malory if initiating a payment. This
effectively redirects the entire traffic of the network through her node.
2. Malory has create a DoS attack on her own node but depending on the size
of the network she will not even see it as her channel partners will go
down from the DoS first (or she is able to handle the traffic as she was
prepared)
3. Assuming Malory has enough Channel partners (or collaborates with them)
she can collect the tiny unconditional upfront fees (Depending on the price
of the upfront fees, the size of the network and the base load of payments
per second this may or may not be lucrative)
Also as her fees were so negative most nodes might not even blame her for
the routing failures as they might assume others were just more quickly
sniping that juicy liquidity. Yet Alice has collected some upfront fees of
all payments that are going on at that time.
Some thoughts about mitigation strategies:
=================================
## Working:
* Choose weather to progress with either negative fees or upfront fees will
stop this particular problem to come up.
## Probably not working:
* Forcing channels with negative fees to set the the upfront fee negative
will not work. This is effectively handing out free money to the channel
partner: As soon as someone announces negative fees the channel partner
will send out fake payments and earn the negative upfront fee.
* Allow `channel_updates` only to be relayed from connections that maintain
a channel so that Mallory cannot quickly inform the entire network about
being the most central node by connecting to everyone may help in
combination with rate limiting of payments and reputation ideas but I guess
others are more experienced than me with reputation systems. Also I think
new participants need `channel_updates` even if they don't have channels
yet.
Own thoughts:
===========
As many of you know I am currently writing a paper about the fundamental
limitations of the scaling abilities of the Lightning Network to conduct
Bitcoin payments [3]. Most folks I talk to see deliberate and malicious
channel jamming as a problem. While I agree with the problem I think the
situation is worse. It is my current understanding that natural congestion
resulting from the selfish behavior of both sending and routing nodes will
be a huge challenge for the network. This is amplified by the uncertainty
(for example about liquidity). However, even without uncertainty it will
create an upper boundary of how many payments per second the participants
of the network will be able to conduct. This boundary is more or less given
by the weighted betweenness centrality of the most central node and the
routing throughput that this node is able to handle. More on this is soon
to come here...
That being said, independently of the up-front fees it seems to me that
allowing negative fees tend to increase centralization effects and thus the
price of anarchy and natural congestion. Yet I can't quantify this at this
time and thus I don't know yet if this fundamentally speaks against
negative fees. However as discussed above in combination with upfront fees
there seems to be an economic incentive to abuse both together.
Thanks to Christian Decker for spotting an error in an edge cases when I
initially presented him a similar argument for review.
with kind regards Rene Pickhardt
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003685.html
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
[3] https://twitter.com/renepickhardt/status/1605189724293169153
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230101/7e0f200b/attachment.html>;
📝 Original message:
Happy new year dear fellow Lightning Network Developers,
last month I have made a small observation why we probably should at most
progress EITHER with `negative fees` [1] OR `upfront fees` [2] but not with
BOTH as adding both features to the protocol would result in a potentially
lucrative attack that I will describe here.
Assumption:
=========
For simplicity of the argument please assume all nodes do payment delivery
by optimizing purely for fees instead of probabilistic payment delivery or
a combination of these two and potentially other features in their cost
function. The Argument will however work as long as fees are part of the
cost function.
The Attack:
=========
1. Malory sets the routing fees of her channel(s) sufficiently negative.
2. Now the cheapest route for all possible payment pairs on the network
goes through Malory.
3. Malory will accept any incoming HTLC but will shortly after the HTLC is
locked in fail the payment without forwarding.
( 4. Depending on the design of upfront fees she may need a collaborating
proxy node)
Outcome:
========
1. After announcing the negative routing fees every node that has seen the
`channel_update` will route through Malory if initiating a payment. This
effectively redirects the entire traffic of the network through her node.
2. Malory has create a DoS attack on her own node but depending on the size
of the network she will not even see it as her channel partners will go
down from the DoS first (or she is able to handle the traffic as she was
prepared)
3. Assuming Malory has enough Channel partners (or collaborates with them)
she can collect the tiny unconditional upfront fees (Depending on the price
of the upfront fees, the size of the network and the base load of payments
per second this may or may not be lucrative)
Also as her fees were so negative most nodes might not even blame her for
the routing failures as they might assume others were just more quickly
sniping that juicy liquidity. Yet Alice has collected some upfront fees of
all payments that are going on at that time.
Some thoughts about mitigation strategies:
=================================
## Working:
* Choose weather to progress with either negative fees or upfront fees will
stop this particular problem to come up.
## Probably not working:
* Forcing channels with negative fees to set the the upfront fee negative
will not work. This is effectively handing out free money to the channel
partner: As soon as someone announces negative fees the channel partner
will send out fake payments and earn the negative upfront fee.
* Allow `channel_updates` only to be relayed from connections that maintain
a channel so that Mallory cannot quickly inform the entire network about
being the most central node by connecting to everyone may help in
combination with rate limiting of payments and reputation ideas but I guess
others are more experienced than me with reputation systems. Also I think
new participants need `channel_updates` even if they don't have channels
yet.
Own thoughts:
===========
As many of you know I am currently writing a paper about the fundamental
limitations of the scaling abilities of the Lightning Network to conduct
Bitcoin payments [3]. Most folks I talk to see deliberate and malicious
channel jamming as a problem. While I agree with the problem I think the
situation is worse. It is my current understanding that natural congestion
resulting from the selfish behavior of both sending and routing nodes will
be a huge challenge for the network. This is amplified by the uncertainty
(for example about liquidity). However, even without uncertainty it will
create an upper boundary of how many payments per second the participants
of the network will be able to conduct. This boundary is more or less given
by the weighted betweenness centrality of the most central node and the
routing throughput that this node is able to handle. More on this is soon
to come here...
That being said, independently of the up-front fees it seems to me that
allowing negative fees tend to increase centralization effects and thus the
price of anarchy and natural congestion. Yet I can't quantify this at this
time and thus I don't know yet if this fundamentally speaks against
negative fees. However as discussed above in combination with upfront fees
there seems to be an economic incentive to abuse both together.
Thanks to Christian Decker for spotting an error in an edge cases when I
initially presented him a similar argument for review.
with kind regards Rene Pickhardt
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003685.html
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
[3] https://twitter.com/renepickhardt/status/1605189724293169153
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230101/7e0f200b/attachment.html>;