In the meanwhile, all the end-users and lsps funds are quite exposed to be powned or continuously DoSed.
What a weird complaint. It's perfectly feasible for professionals to run Lightning nodes in such a way that they don't expose any public IP's to DoS attack. Binance is a good example: their lightning node has $5 million worth of channel capacity without a public IP. And for outgoing connections, there's lots of anti-DoS proxies out there that terminate outgoing connections in such a way that people on the receiving end don't get a unique IP address to DoS attack.
This feels like the rant of someone who is just butt hurt that their exploit didn't get as much attention as they wanted. Or maybe they were annoyed that their "OMG LIGHTNING IS BROKEN!" exploit got quickly fixed in multiple different ways, none of which were invented by him.
Drama drama drama...
Binance is a good example: their lightning node has $5 million worth of channel capacity without a public IP. And for outgoing connections, there's lots of anti- DoS proxies out there that terminate outgoing connections in such a way that people on the receiving end don't get a unique IP address to DoS attack.
I don’t need a node public IP to launch a channel jamming of your node, as long as you’re announcing your local topology to the rest of the network.
This feels like the rant of someone who is just butt hurt that their exploit didn't get > as much attention as they wanted. Or maybe they were annoyed that their "OMG > LIGHTNING IS BROKEN!" exploit got quickly fixed in multiple different ways, none > of which were invented by him.
Feel free to share your Lightning node pubkey. My pleasure to do a public demonstration of the fixes “robustness” at your own expenses. As a note, I suggested most of the fixes implemented by LN open-source maintainers.
Drama drama drama...
Lessons of human sciences, conflict is not necessarily a negative situation as it’s an opportunity for newer norms, ideas and solutions to emerge.
reply
Why don't you just release channel jamming code? If it's a real exploit, people should be experimenting with it openly.
reply
First reason, I don’t know who you are, I have no public track records available on your intentions and what you would do with such offensive toolchain.
Second reason, I’m not your bitch and I don’t owe you this code.
As a side-note, other lightning researchers have already done demonstration of channel jamming: https://bitcoinmagazine.com/technical/good-griefing-a-lingering-vulnerability-on-lightning-network-that-still-needs-fixing
On replacement cycling attacks, I’m still looking for volunteers, you’re free to share me your lightning node pubkey, though I would need a social proof or fingerprint this is really your node and you’re fully consenting to your funds being powned as a bug bounty.
I’m sure the community will thank you for your financial contribution to the advance of Bitcoin research.
reply
First reason, I don’t know who you are, I have no public track records available on your intentions and what you would do with such offensive toolchain.
The fastest ways to get issues fixed is demonstrations. Same as the rest of the security industry has learned. And it may make for better fixes as more people can experiment with the issues and find ways to improve on the attacks.
reply
As is posted on the mailing list at time of disclosure, I’ve been looking for someone among other lightning devs run and play the “defensive” side in replacement cycling attacks, in a traditional “blue / red” fashion. No one has raised the hand.
You’re still free to publish your mainet lightning node pubkey and give me your private consent for demonstration / experimentation. Beyond, I did test replacement cycling attacks locally and it was working well.
We did test some lightning attacks in the past in a real-world setup, though I think you’re missing point than you have so much known attacks affecting lightning that senior protocol devs don’t have time to test, experiment, research and fix them anymore. And as such, jeopardizing their end-users bitcoin financial interests.
reply
Not every form of Lightning DoS requires use of an IP address. Channel jamming and other attacks on liquidity, for example.
reply
Unfortunately bitcoiners don't want to hear the truth on this sort of thing.
It'll take a while for bitcoiners to separate their bitcoin itself from just one early L2 implementation.
reply
"LN is broken!" "Reach 100 m dollar hedgefund"
These do not really show humility, a trait that I think would be very important to collaborate on Bitcoin.
reply
I’ll appreciate the comment on humility if it was coming from one of my bitcoin technical peer working on the protocol. Otherwise it’s pointless, and to be honest if you’re working on bitcoin security you’ll need toughness and character before humility.
I don’t misappreciate humility as a virtue and it’s good to have some - I’m just saying this might not be the supreme principle to collaborate on a Bitcoin.
reply
Welcome back!
Ah there we go with the "developer privilege". Serves my point I guess.
reply
“Developer privilege” ? I don’t get it. Let me know if I’m missing some post-modern reference :)
reply
Privilege - working for free without any guaranteed salary. 😁
reply