Against bitcoin p2p network sybil attackers.

[chris-belcher]

Regarding https://www.reddit.com/r/Bitcoin/comments/2yvy6b/a_regulatory_compliance_service_is_sybil/

Obviously coinjoin doesn't directly help against this IP tracking. But this project can still help.

We should introduce a method where the taker (coinjoin-initiator) can send the fully-signed tx hex to one of the makers (market-makers who wait-to-coinjoin) who will then broadcast it. The taker would choose to broadcast the txhex himself, or send it to one randomly chosen maker to broadcast. In this way the coinjoin tx could come from many IPs instead of just the taker's.

Naturally this kind of bad actor could also be a sybil in the joinmarket. But all communicating is encrypted under private messages, so a passive observer learns nothing.
If they become a sybil actively participating in coinjoins they will be limited in ways already discussed: To coinjoin everybody's transactions the sybil would need to own a large amount of bitcoins, so would be harshly limited by cost. Also their coinjoining activity will stop other sybils learning what's happening. Because of the feature in #14 the sybil will not be guaranteed to coinjoin with everyone just because they offer the lowest price.

[AdamISZ]

We should introduce a method where the taker (coinjoin-initiator) can send the fully-signed tx hex to one of the makers (market-makers who wait-to-coinjoin) who will then broadcast it.

Agreed, that can only help. Of course, network level obfuscation might be another step up, e.g. Tor, but that's another can of worms, and a bit outside the scope here.

Edit: another small thought, maybe you already considered it, but at the moment a taker is kind of in a "race" to get his tx broadcast out, after the mix steps are completed. This will tend to make it easy to associate activities on a public message channel like IRC (albeit encrypted) with a bitcoin network broadcast.

[chris-belcher]

What does network level obfuscation mean in practice? edit: oh it just means routing through tor.

Regarding the edit. True.
The taker has to be in a race to claim the UTXO inputs, otherwise malicious takers could negotiate many coinjoins with makers and never broadcast them to use up all the maker's UTXOs.
The person controlling the IRC server will be easily able to make that link. Hopefully it shouldn't be an issue for another messaging channel like subspace.

[chris-belcher]

Wrote the code for the maker side. 919e97f

Disabled on taker side for now.

[chris-belcher]

There could be a script called pushtx.py which connects to the network and sends a tx to a maker, either chosen by random or chosen by the user.

A similar kind of thing can be in the ob-watcher.py html page

[chris-belcher]

Could requesting a maker to push lots and lots of transactions could get that maker banned by other bitcoin nodes? This may be a DOS opportunity.

Might not be a problem, mining pools and blockchain explorers with /pushtx.php must deal with this somehow

[chris-belcher]

An example of a paper that actually does this: https://arxiv.org/pdf/1612.06747v3.pdf

Nice paper with interesting results. They actually do spin up their own nodes which collect ip-address/transaction linkages. Then combined with the graph between bitcoin addresses they can figure out bitcoin-address/ip-address linkages.

Note that the data collection happened in late-2013, and the Bitcoin Core transaction relay algorithm has been changed significantly in the meantime to improve privacy (the assumptions in the introduction to the paper are therefore wrong today)