Introducing txCast

Jan 21 · 3 min read

Randomised Bitcoin (testnet) transaction broadcasting to break timing analysis. Visit for more.


When attempting to use Bitcoin privately we often focus on the method of receiving relevant bitcoin blocks in a private way; Either by using a full node and downloading all blocks, or using bip158 block filters and downloading individual relevant blocks from random nodes over fresh tor circuits.

What is less often considered is the manner in which we broadcast transactions, and the privacy implications associated with each method.

Methods include;

  • Broadcasting from your own full node to your peers (clearnet / tor)
  • Broadcasting via a 3rd party node via a website / api (clearnet / tor)

We are concerned with the leakage of two pieces of data:

Data Leak 1: Association of transactions & your IP

If you link your transaction(s) with your IP then you have undone, or at least undermined your previous work to improve your privacy using bitcoin.

Adversary 1: Malicious Node Peer

In Bitcoin Core, random delays are added before forwarding transactions in order to obscure the transaction source. Specifically, all transactions are delayed until the next broadcast event, which occurs at Poisson-distributed times [Pieter Wuille: 1, 2]. This makes it difficult for an individual malicious node peer to have any certainty regarding associating transactions & IP addresses.

Adversary 2: Network Wide Sybil Attack

It is possible (and cheap) for an adversary to learn the structure of the Bitcoin network, and as a result, link transactions to IP addresses. Dandelion is a good potential solution to this problem, but it is not currently implemented.

If this attack is currently ongoing (we can’t know) we can mitigate by either broadcasting to new peers each time we send a transaction, or by broadcasting from the same 3rd party node which many other people use to broadcast. For the latter technique we must defend against the (above) malicious node peer scenario, and we can do this by connecting over a new tor circuit each time we broadcast.

Data Leak 2: Association between transactions based on timing analysis

Separate to the details of how our transactions are broadcast is the issue of when they are broadcast / confirmed.

This is a particular issue for mixed coins in a hot wallet (used for mixing for example) which a user later decides to send to a hardware wallet for more secure storage. In this scenario it is likely that a user will want to deal with all their utxos in one session — which makes clustering easy to detect.

If a bunch of similar utxos (for example bech32 CoinJoin outputs) which have been dormant for a number of months are all spent in the same block it is possible that a blockchain analyst could cluster the utxos based on timing analysis.

Note that this does not require there to be address reuse or coin merging.

A prototype solution: txCast

For the purpose of getting the ball rolling I have developed a python script which uses blockstream’s API (accessed via tor) to broadcast transactions. The user inputs the signed transactions to broadcast & the maximum delay they can accommodate (minutes, hours, days) and the script does the rest.

It is not ready for mainnet use yet, I will make an announcement when it is. If you are interested in trying it out and improving it please visit the repository:

I have little coding experience so I would appreciate any feedback / suggestions that you can offer.


Written by


More From Medium

Related reads

Related reads


Aug 27, 2018 · 10 min read


Related reads

Nic Carter
Jun 19, 2019 · 16 min read


Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade