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