alicexbt [ARCHIVE] on Nostr: 📅 Original date posted:2023-07-06 🗒️ Summary of this message: The sender is ...
📅 Original date posted:2023-07-06
🗒️ Summary of this message: The sender is alerting Bitcoin developers about a potential DoS attack using package relay in coinjoin. They provide steps and considerations for two coinjoin implementations.
📝 Original message:
Hi Bitcoin Developers,
I think its possible to use [package relay][0] for DoS attack in coinjoin. A few other projects could also be affected by packages. Since its a proposal that adds new P2P messages, transaction relay etc. its as important as any soft fork. Let me know if I am missing something.
Consider there are 2 coinjoin implementations: A and B
1) Register input in A
2) Double spend same input with zero fee to your own address
3) Register unconfirmed UTXO from 2 in B
4) B relays a package in which coinjoin transaction (child) pays for 2 (parent)
Users and coinjoin implementation B, both are incentivized to attack in this case.
Attacker could also use a different approach and register same input in A, B although there are some tradeoffs:
- If input gets included in a coinjoin transaction broadcasted by A, there is nothing much B can do about it. RBF with multiple users isn't easy and costly.
- Implementation with less users participating in a round would have an advantage.
[0]: https://gist.github.com/sdaftuar/8756699bfcad4d3806ba9f3396d4e66a
/dev/fd0
floppy disk guy
Sent with Proton Mail secure email.
🗒️ Summary of this message: The sender is alerting Bitcoin developers about a potential DoS attack using package relay in coinjoin. They provide steps and considerations for two coinjoin implementations.
📝 Original message:
Hi Bitcoin Developers,
I think its possible to use [package relay][0] for DoS attack in coinjoin. A few other projects could also be affected by packages. Since its a proposal that adds new P2P messages, transaction relay etc. its as important as any soft fork. Let me know if I am missing something.
Consider there are 2 coinjoin implementations: A and B
1) Register input in A
2) Double spend same input with zero fee to your own address
3) Register unconfirmed UTXO from 2 in B
4) B relays a package in which coinjoin transaction (child) pays for 2 (parent)
Users and coinjoin implementation B, both are incentivized to attack in this case.
Attacker could also use a different approach and register same input in A, B although there are some tradeoffs:
- If input gets included in a coinjoin transaction broadcasted by A, there is nothing much B can do about it. RBF with multiple users isn't easy and costly.
- Implementation with less users participating in a round would have an advantage.
[0]: https://gist.github.com/sdaftuar/8756699bfcad4d3806ba9f3396d4e66a
/dev/fd0
floppy disk guy
Sent with Proton Mail secure email.