Broadcast to a single peer #5
Conversation
The problem with blasting transactions to multiple peers is that it increases the chance of landing on a surveillance node. This isn't a problem when using Tor; it is mainly a problem for clearnet connections. This change ensures that we broadcast to just one peer and then wait for a roundtrip confirmation in the form of an `inventory` message from other connected peers. This is marginally slower than the blasting strategy but it increases both privacy for clearnet connections and gives us certainty in the form of verifying that our transaction has propagated through the network. The selected broadcast peer is given 10 seconds for our transaction(s) to appear on the network, after which we rotate the peer. Other changes: - bump version to 0.4.0 for both lib and bin - redo the `Report` struct to better reflect completion outcomes - deprecate the `--tesnet` switch in bin in favor of `--network` - remove the `send_unsolicited` option (unnecessary)
|
Hi @alfred-hodler ! |
Yes.
It doesn't wait because there are many other heuristics that we could be identified by. We are sending a very identifiable version message, so something would have to be done on that front too, which is very hard. If that level of surveillance is a concern, such as targeted heuristics, we just need to use Tor -- at that point these heuristics and fingerprints don't really matter anymore. |
|
Does this broadcast always to a single peer, regardless of whether Tor is available or not? I think a good strategy would be:
|
that is suboptimal, since ISP can see a spike of Tor traffic on the sender end and correlate it with the appearance of a transaction in mempool. If do this, at least add a flag please. I would like to have Wasabi grade privacy and they send to one peer even though Tor (and onion) is used. And it works quite fast in Wasabi, because most peers do their job of broadcasting transaction further. |
|
I'm trying to build it on Debian Sid. Earlier Debian versions have too old Still failing to build it. |
|
@vasild I agree with @starius in that it's not really necessary to broadcast to multiple peers. Transaction propagation seems to be very fast. Connecting to at least one onion peer would be nice if we have Tor, but to get there some refactoring is needed since the primary way of getting peers is currently through DNS seeds and those don't return onion domains. This is something that we can put on the roadmap for the future. @starius It seems that some generic constructs weren't compatible with your version of Rust. I've just issued an update, please pull and try again. |
|
@alfred-hodler It builds now. It works! I tested it a couple of times in signet. Thank you very much for the tool! I'll definitely add it to my favorite tool collection and use instead of Wasabi to broadcast transactions! One thing which is confusing is that it expects me to type Ctrl+D after entering the transaction. I pressed just Enter instead and thought that it is not working. Can you catch Enter as well, not only Ctrl+D, please? Or at least print in the prompt that the user has to press Ctrl+D after typing the transaction. Another thing. I know that terminals don't work very well with long inputs (longer than 4096 characters). I ran into this issue in Also, I see that option --tor-mode has the following options: What if the user is forwarding all network traffic to Tor using operating systems capabilities (e.g. running in QubesOS behind Whonix Gateway). Then port 9050 may not be available locally, but just normal network traffic is sent through Tor and
Can you also deal with this, please? E.g. send some popular user agent. |
Ctrl-D (or Ctrl-Z on Windows) means "end of stream" and that's a pretty standard way to terminate stdin. Tools that read their input through stdin always take this approach and don't terminate on Enter. More interactive programs might indeed handle different types of input, but this tool is meant to follow a Unix philosophy. In the end, if we terminated with Enter, we wouldn't be able to enter multiple transactions, which is possible right now (whether this is a good idea is a different discussion).
The 4096 char limit seems to be real. It's something I can deal with in the next version.
The tool wouldn't use onion peers either way because we are getting them through DNS seeds, which return A type records -- meaning that domain names (which includes .onion) aren't included there. We have some hardcoded onion peers but that's just in our hardcoded lists -- which are used only for fallback in case the DNS method doesn't work. Some redesign/refactor there might be needed to get this to work. I'd be interested in getting some help in the form of a high quality PR.
If you're using the library, you can override the user agent right now. The binary uses the default one. The problem with the whole user agent business is that the version message contains a lot more than that, such as our block height and local time. Unless you set those too, it's obvious you're an "unusual" peer. I generally don't think anyone should ever be broadcasting transactions through clearnet, but if they are indeed doing that, fiddling with the user agent won't really help them hide better. |
|
Few more ideas :)
Can you mention Ctrl+D / Ctrl+Z on Windows in the prompt message, please? I was waiting for few minutes after pressing Enter, thinking that the tool is stick, until I remembered Ctrl+D thing :)
After reading and parsing the first transaction the tool could make next prompt like this: This will make the tool more interactive, not like If can be disabled with Also,
Bitcoin Core has a large list of hardcoded onion (and other types of) peers. Does it make sense to ember the whole list into the tool? https://github.com/bitcoin/bitcoin/blob/master/contrib/seeds/nodes_main.txt
If only I had Rust skills to do it. I'll ask my friends who write in Rust to take a look :)
Some idea. Let's connect to the first peer with some default settings (e.g. default user agent, block height = 0 etc), memorize what it responded and connect to the second peer using data returned by the first peer. Then connect to the third peer using the data returned by the second peer etc. |
Here you go: 90ad6b9
Ok, that's an interesting take on this tool. Initially I envisioned it a simple BYOW (Bring Your Own Wallet) solution where you do all the validation elsewhere and just pipe the output into this. Your suggestion would make this tool more of a full fledged "swiss army knife" in some sense and that would come with its own complexity.
We already have those, but we're only using them for fallback. The problem with using them as a primary source is that these would be very outdated compared with what DNS seeds are returning and only to be used as last resort when you're out of other options.
That would take too long, since handshakes take a while to complete. Right now we connect to a bunch of peers in parallel and this proposal would make that process serial/sequential. The whole process would take longer than now, and I'm not sure that it's worth it. We could just expose a Either way, we should probably move this type of discussion elsewhere. |
The pattern of connect-send-tx-disconnect is unique enough to distinguish that this is the first broadcast of the transaction, most likely by its owner. The individual fields in the version message cannot obfuscate this, but they can undesirably reveal further information if they are not generic enough (e.g. clock, odd height). This may allow linking repeated broadcasts to an otherwise unrelated transactions.
Given the above that would bring zero-value, but it would make it possible for the user to shoot themselves in the foot by specifying an unique user agent. |
The problem with blasting transactions to multiple peers is that it increases the chance of landing on a surveillance node. This isn't a problem when using Tor; it is mainly a problem for clearnet connections.
This change ensures that we broadcast to just one peer and then wait for a roundtrip confirmation in the form of an
inventorymessage from other connected peers.This is marginally slower than the blasting strategy but it increases both privacy for clearnet connections and gives us certainty in the form of verifying that our transaction has propagated through the network.
The selected broadcast peer is given 10 seconds for our transaction(s) to appear on the network, after which we rotate the peer.
Other changes:
Reportstruct to better reflect completion outcomes--tesnetswitch in bin in favor of--networksend_unsolicitedoption (unnecessary)