👩🔧Great paper by @ClaraShik and @serg_tikhomirov on lightning jamming mitigations at eprint.iacr.org/2022/1454.pdf
🚨I expect all #lightning payments in future to have some tiny anti-spam fee attached (even if they fail): the paper suggests 2% of success fees (~0.001% of amount RN).
That's looking at my node's mean fee for my LN payments of 0.05% (shockingly low, TBH, so I expect that to increase).
I told people to anticipate this at Lightning Conf in 2018, but that was an age ago, so let's revisit: why add a pre-pay fee?
Well, probing is currently free: you only pay if payment succeeds, so you can just deliberately fail them all. This is great incentive for nodes to actually work, but is free probes makes it easy to violate privacy as well as jam the network up for others.
If #Bitcoin confuses you, it's important to remember that we're trying to change *accepted social norms*. That's weird, slow and confusing.
In my Linux days we were dealing with "that's not how you construct software", Bitcoin is "that's not how you construct money". 1/7
For Linux I had read and sympathized with RMS's GNU Free Software vision at University, but it took Linux to actually show me it actually *worked better*. But I was the "weird Linux guy" for a long time, then inside a "weird Linux bubble". 2/7
What happened in the 25 years between "Free Software exists if you can't afford real software" and "all important software is Open Source"? Between the social norm of Digicash as a proprietary patented solution and Bitcoin as anonymous FOSS? 3/7
So @alexbosworth doesn't understand the Lightning Spec process. I thought Lightning Labs had been so quiet in the last two years because (1) @roasbeef is the only one there who's allowed to do spec stuff (2) profitability lead them to pivot to proprietary centralized offerings.
Turns out they've decided they can leverage network dominance into protocol control, and the spec process isn't "real".
Mea culpa: I have spent far too much time on the spec process, and not enough on implementation polishing and marketing. That changes today.
Lightning Labs has claimed ownership of the Lightning network in many ways: I've been reluctant to call them out in public. But the lightning network and community deserves better.
They didn't implement it first, they didn't implement it best. Their community is great though!
There are three types of spam problem in #Bitcoin#LightningNetwork; let's call them "local", "slow" and "fast". local spam is someone sending or requesting too much data: that's a Simple Matter of Code, with ratelimiting etc. Let's talk about the other two:
"fast" spam is sending many failed payments. You can't tell what will succeed, and you can't blame the sending peer (they may not be the source). This attack is free since we only pay on success. The answer is to require an up-front payment, but
it has to be small (making sure your incentive is to succeed), and it should not leak information on where you are in the path. I've been unable to find a scheme I'm happy with though, see latest attempt at lists.linuxfoundation.org/pipermail/ligh….
I used #clightning's new multifundchannel with every one of the 1837 nodes on testnet. Most are dead, many timed out, some already had channels, and two didn't respond to open_channel, but 106 made it! Here's the open tx: blockstream.info/testnet/tx/cde…
Thanks to @niftynei for the freshly mined testnet coins, @ZmnSCPxj for the new multifundchannel plugin. We've been able to do this in theory for over a year, but now it's trivial! Though I had to use python: bash told me "Argument list too long".
I had to manually kill the two non-responsive open_channels, since we don't time out. Issue opened for next release (too minor for rc2 imho): github.com/ElementsProjec…
lnprototest is vital for lightning development. It's a simple place to rapidly implement new features for testing: very hackable! It also lets us test things that real implementations don't do. It's an easy on-ramp for interoperability testing.
For example, I accidentally broke #clightning accepting unknown odd packets. Nothing broke! But this is vital for future upgrades, where we want to rely on this "you will ignore this, not barf" behaviour. lnprototest's predecessor found this.
Testing all the paths of opening a channel lead me to find the CVE-2019-12998. And now we're working on dual-funding channels, it's vital we thoroughly test opening negotiation.