Tor-only transaction broadcast onlynet=onion alternative

jb55 commented at 4:42 pm on May 21, 2020: member

It would be nice if there was a way to tell core to only broadcast transactions over Tor, but use clearnet for everything else.

As far as I can tell the only way to guarantee transaction broadcast over Tor is to use onlynet=onion, which means that all network traffic goes over Tor. The problem is that this introduces latency for blocks/confirmations and transactions. Some users might only want to use Tor to try to protect “first broadcast” transaction origin analysis which can be a problem with sybil attacking clearnet nodes. This can still be a problem on Tor as well, but can be more difficult to pull off.

Some bitcoin software such as wasabi and joinmarket already implement this by establishing a new Tor circuit, broadcasting the transaction, and then disconnecting. Perhaps bitcoin could do this as well?

Some things that were brought up when I mentioned this on IRC by @naumenkogs, @luke-jr and others:

For the resistance to first-broadcast analysis to be effective, the node should treat the transaction as if it wasn’t theirs to begin with. I’m not familiar with the network code, so I’m not sure if anything would have to change relay policy-wise.

Would be happy to hear other thoughts on what would be required to implement this, or if there’s something I’m missing, as it’s something I would be interested in implementing if there are enough concept acks.

TL;DR rationale:

A nodes wants to recieve blocks/confirmations/transactions as soon as possible with the lowest latency
A node wants increased broadcast privacy without paying the full cost of onlynet=tor latency

jb55 added the label Feature on May 21, 2020

ghost commented at 3:53 am on June 4, 2020: none

onlynet=onion guarantees that outgoing connections are made through Tor; incoming clearnet connections are still allowed. I think there’s no reason to exclude non-broadcast activity from the Tor segment since being connected to more networks can only increase partitioning resistance.

That said, I think that onlynet=onion can create false expectations in terms of privacy because a node operating on both networks (due to incoming connections) will still broadcast through the clearnet.

It would be good to have something like: broadcast-network=ipv4,ipv6,onion and make it inherit the onlynet parameter, or else default to Tor if Tor is running locally.

Would there be any interest in this?

kristapsk commented at 12:08 pm on February 11, 2022: contributor

Some bitcoin software such as wasabi and joinmarket already implement this by establishing a new Tor circuit, broadcasting the transaction, and then disconnecting.

No, JoinMarket does not do that. Transaction broadcast happens through Bitcoin Core. But not always by the initiator of the coinjoin (taker), by default it will be one of the participiants in coinjoin randomly.

kristapsk commented at 12:11 pm on February 11, 2022: contributor

Related (duplicate) - #14692.

MarcoFalke commented at 6:58 pm on February 11, 2022: member

For the resistance to first-broadcast analysis to be effective, the node should treat the transaction as if it wasn’t theirs to begin with. I’m not familiar with the network code, so I’m not sure if anything would have to change relay policy-wise.

I think the general idea is that you should consider your mempool to be an open book to all your inbound and outbound peers. So adding a wallet transaction to the mempool, which is readable by all your clearnet peers, and then sending the transaction on tor only will make it more than trivial for all clearnet peers to mark all your wallet transactions. See #15668 (comment) .

So I think one solution would be to never put the transaction in the mempool, but have logic in the wallet to create a one-shot connection to spit out the tx and immediately disconnect. Obviously your peer will learn your network fingerprint (version message), as well as your wallet tx (tx message). Though, with a connection over tor, and a normalized version message this should be conceptually OK.

The reason why I haven’t drafted an implementation yet is because the wallet can’t keep track of non-mempool change. See #11887. And fixing that appears non-trivial at first glance.

jb55 commented at 7:07 pm on February 11, 2022: member

Some bitcoin software such as wasabi and joinmarket already implement this by establishing a new Tor circuit, broadcasting the transaction, and then disconnecting.

No, JoinMarket does not do that. Transaction broadcast happens through Bitcoin Core. But not always by the initiator of the coinjoin (taker), by default it will be one of the participiants in coinjoin randomly.

interesting, when I wrote this I distinctly remember someone telling me that’s how it worked and showed me the code that does it… perhaps I misunderstood the details. thanks for the clarification.

kristapsk commented at 8:46 pm on February 11, 2022: contributor

I distinctly remember someone telling me that’s how it worked and showed me the code that does it…

Wasabi does that, there you are correct, but not JoinMarket.

ghost commented at 11:05 pm on February 11, 2022: none

Yes Wasabi randomly selects one peer to broadcast transaction.

Related issue or feature request: https://github.com/bitcoin/bitcoin/issues/21876

kristapsk commented at 5:27 pm on February 12, 2022: contributor

With default config in JoinMarket tx broadcast also is done by random peer, we just don’t do multiple Tor circuit thing. Communication anyway happens not directly between peers, but via IRC server.

ghost commented at 5:35 pm on February 12, 2022: none

Communication anyway happens not directly between peers, but via IRC server.

Is this being replaced with lightning?

kristapsk commented at 5:41 pm on February 12, 2022: contributor

Is this being replaced with lightning?

Work in progress. But not replaced, both can exist in parallel.

Tor-only transaction broadcast onlynet=onion alternative #19042