Antoine Riard [ARCHIVE] on Nostr: ð Original date posted:2022-08-17 ð Original message: Gleb Naumenko and I would ...
ð
Original date posted:2022-08-17
ð Original message:
Gleb Naumenko and I would like to present our latest research on the
well-known channel jamming attacks affecting the Lightning Network. For a
reminder on the basis of channel jamming, we would like to point to Gleb's
earlier recollection [0].
We have a serie of research posts available here:
https://jamming-dev.github.io/book/
The research is based on Lightning Network data as of March 2022.
Here's the summary.
Chapter 1 (The impacts of channel jamming) where we discuss:
- how the attacker may steal routing fees or target victim's routing
reputation;
- how the attacker may DoS a goods/service provider;
- the monetary implications victims may bear;
- how jamming could enhance probing;
- how jamming may allow an attacker to drag LN users to other payment
solutions.
Chapter 2 (Channel jamming costs) where we:
- discuss the on-chain aspect and the opportunity aspect of attack cost;
- describe cost optimizations (looping, rebalancing, targeting
surroundings);
- notice that the targeted attack costs are currently as low as
thousands of satoshis;
- notice that attacking the entire network requires locking ~million of
sats a month;
- discuss how an attacker may compensate for these costs.
Chapter 3 (Incremental solutions to channel jamming) where we:
- analyze several low-effort solutions to jamming (slot bucketing, JIT
transaction staging, "active defence");
- realize their fundamental trade-offs, strong and weak points;
- discuss slot bucketing in detail (including "0-bucket strategy"), a
good solution candidate.
Chapter 4 (Solution Design Space) where we:
- make a broad overview of potential solutions (bonding to a payment;
reward/punishment incentives);
- identify known and novel families of solutions, discuss their
trade-offs;
- put them in the context of DLC-over-Lightning and other similar "LiFi"
protocols.
Chapter 5 (Hold-time-dependent bidirectional fee schemes) where we:
- overview the most advanced Upfront Payment fee scheme and identify the
trade-offs;
- discuss why it's hard to guarantee a game theoretic balance;
- suggest improvements.
Chapter 6 (The Reputation Scheme: Stake Certificates + Forwarding Pass)
where we:
- suggest a reputation-based solution based on the combination of two
known ideas;
- discuss the associated challenges and the importance of designing a
strong reputation policy.
At the end, we suggest our subjective view on moving forward with this. The
next steps could be either working on more solutions (for which, we
highlight the potential directions) or choosing one of the already
suggested. Among the suggestions, the ecosystem should decide which set of
trade-offs (including solution complexity) is acceptable.
This research should be seen as the synthesis of numerous ideas presented
by other LN developers over the years, and that we can claim original
authorship of really few of them. We made a solid effort to find public
references, though sometimes the ideas have been communicated to us
offline. If you think we missed mentioning the authorship, please let us
know. We also invite the best scrutiny and verification of model
assumptions and research statements. All mistakes or confusions are our own.
Finally, channel jamming has been one of the oldest high-impact issues
mentioned in the Lightning space [1]. It's likely that any solution will
have long-term impacts on the fundamental economic units of the network,
and therefore we hope that such solution finds the consensus of the LN
develoment community as a whole.
Cheers,
Gleb & Antoine
PS: Thanks to the reviewers
[0] https://blog.bitmex.com/preventing-channel-jamming/
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220817/98c8cdc5/attachment.html>;
ð Original message:
Gleb Naumenko and I would like to present our latest research on the
well-known channel jamming attacks affecting the Lightning Network. For a
reminder on the basis of channel jamming, we would like to point to Gleb's
earlier recollection [0].
We have a serie of research posts available here:
https://jamming-dev.github.io/book/
The research is based on Lightning Network data as of March 2022.
Here's the summary.
Chapter 1 (The impacts of channel jamming) where we discuss:
- how the attacker may steal routing fees or target victim's routing
reputation;
- how the attacker may DoS a goods/service provider;
- the monetary implications victims may bear;
- how jamming could enhance probing;
- how jamming may allow an attacker to drag LN users to other payment
solutions.
Chapter 2 (Channel jamming costs) where we:
- discuss the on-chain aspect and the opportunity aspect of attack cost;
- describe cost optimizations (looping, rebalancing, targeting
surroundings);
- notice that the targeted attack costs are currently as low as
thousands of satoshis;
- notice that attacking the entire network requires locking ~million of
sats a month;
- discuss how an attacker may compensate for these costs.
Chapter 3 (Incremental solutions to channel jamming) where we:
- analyze several low-effort solutions to jamming (slot bucketing, JIT
transaction staging, "active defence");
- realize their fundamental trade-offs, strong and weak points;
- discuss slot bucketing in detail (including "0-bucket strategy"), a
good solution candidate.
Chapter 4 (Solution Design Space) where we:
- make a broad overview of potential solutions (bonding to a payment;
reward/punishment incentives);
- identify known and novel families of solutions, discuss their
trade-offs;
- put them in the context of DLC-over-Lightning and other similar "LiFi"
protocols.
Chapter 5 (Hold-time-dependent bidirectional fee schemes) where we:
- overview the most advanced Upfront Payment fee scheme and identify the
trade-offs;
- discuss why it's hard to guarantee a game theoretic balance;
- suggest improvements.
Chapter 6 (The Reputation Scheme: Stake Certificates + Forwarding Pass)
where we:
- suggest a reputation-based solution based on the combination of two
known ideas;
- discuss the associated challenges and the importance of designing a
strong reputation policy.
At the end, we suggest our subjective view on moving forward with this. The
next steps could be either working on more solutions (for which, we
highlight the potential directions) or choosing one of the already
suggested. Among the suggestions, the ecosystem should decide which set of
trade-offs (including solution complexity) is acceptable.
This research should be seen as the synthesis of numerous ideas presented
by other LN developers over the years, and that we can claim original
authorship of really few of them. We made a solid effort to find public
references, though sometimes the ideas have been communicated to us
offline. If you think we missed mentioning the authorship, please let us
know. We also invite the best scrutiny and verification of model
assumptions and research statements. All mistakes or confusions are our own.
Finally, channel jamming has been one of the oldest high-impact issues
mentioned in the Lightning space [1]. It's likely that any solution will
have long-term impacts on the fundamental economic units of the network,
and therefore we hope that such solution finds the consensus of the LN
develoment community as a whole.
Cheers,
Gleb & Antoine
PS: Thanks to the reviewers
[0] https://blog.bitmex.com/preventing-channel-jamming/
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220817/98c8cdc5/attachment.html>;