offer alternative methods for customizing TX broadcast privacy #1056
Conversation
Transactions which are first seen being broadcast from a user's node are more likely to be heuristically associated with the node runner personally. To break this heuristic, node runners might choose to broadcast a TX indirectly through alternative channels to disassociate that TX from the bitcoin node. This PR adds two new ways for users to broadcast transactions through electrs: 1. The `pushtx` crate. This initiates a short-lived set of P2P connections which publishes a transaction to random peers resolved from DNS seeds. The most private way to do this is using TOR, hiding the IP address of the sender. 2. A custom script option. This allows users to customize the behavior of electrs broadcasting. It should return a zero status if the broadcast was successful, and emit an error message with a non-zero status otherwise.
Kixunil
left a comment
Kixunil
left a comment
There was a problem hiding this comment.
Personally, I doubt that sending a tx to random peers over clearnet helps. If a node detects another node connecting to it, then just sending a single tx and then disconnecting it can just assume the transaction is being broadcasted by the connecting client. So in effect it likely leaks privacy. As such I would probably refrain from adding it.
You need Dandelion for this to work privately.
src/config.rs
Outdated
| skip_block_download_wait: config.skip_block_download_wait, | ||
| disable_electrum_rpc: config.disable_electrum_rpc, | ||
| tx_broadcast_method: config.tx_broadcast_method, | ||
| tx_broadcast_script: config.tx_broadcast_script, |
There was a problem hiding this comment.
It'd be better to have another internal enum TxBroadcastMethod that carries Script(String) variant and do the conversion where you do the checks.
There was a problem hiding this comment.
I gave it a try with this commit: d695a22
i think adding another type makes the namespacing a bit messier as now we have pub types TxBroadcastMethod, TxBroadcastMethodConfigOption, and TxBroadcaster. But it does help us avoid an unwrap call in electrum.rs, so either works for me.
@Kixunil I strongly agree, and that's why the Perhaps I could add some extra warnings to the |
|
Added extra warnings for |
Good point but this should be explicitly documented, so good that you did. FTR this is also useful on Whonix I think. |
|
Thanks for the suggestions @Kixunil, added both 🙂 |
src/electrum.rs
Outdated
| let tx_bytes = Vec::from_hex(tx_hex).context("non-hex transaction")?; | ||
| let tx = deserialize(&tx_bytes).context("invalid transaction")?; | ||
| let txid = self.daemon.broadcast(&tx)?; | ||
| let txid = self.tx_broadcaster.broadcast(&tx)?; |
There was a problem hiding this comment.
Why use Arc<Daemon> instead of just Daemon? A &Daemon can be passed to the broadcast method here.
|
Hi @Kixunil and @romanz, sorry it's been a while since I fixed conflicts on this PR. I've been using the As for the |
|
One minor annoyance is that the |
3 participants
Transactions which are first seen being broadcast from a user's node are more likely to be heuristically associated with the node runner personally. To break this heuristic, node runners might choose to broadcast a TX indirectly through alternative channels to disassociate that TX from the bitcoin node. Unfortunately bitcoind does not offer this option natively (yet).
This PR adds two new ways for users to broadcast transactions submitted to an
electrsserver:The
pushtxcrate. This initiates a short-lived set of P2P connections which publishes a transaction to random peers resolved from DNS seeds. The most private way to do this is using TOR, hiding the IP address of the sender.A custom script option. This allows users to customize the behavior of electrs broadcasting. It should return a zero status if the broadcast was successful, and emit an error message with a non-zero status otherwise.