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.
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