Your Transaction Doesn't Teleport

You hit send. Somewhere in the next two to thirty seconds, your transaction ripples outward across a few thousand nodes scattered across every inhabited continent. Not instant. Not through a central server. It moves the way a rumor moves through a crowd: person to person, hop by hop, with all the distortions and delays that implies.

That topology, the actual shape of how Bitcoin nodes connect to each other, is doing two jobs at once. Getting your transaction confirmed as fast as possible. And keeping anyone from tracing it back to the device you sent it from. The problem is those two goals are in direct, mechanical tension. Understanding why is the part most guides skip.

The Gossip Protocol and Why Faster Means More Exposed

Bitcoin nodes communicate using a flooding protocol. When your wallet broadcasts a transaction, it goes to your node's peers, typically eight outbound connections by default in Bitcoin Core. Each of those peers validates it and forwards it to their peers. Within a few seconds, the transaction has touched hundreds of nodes. Within a minute or two, it's essentially everywhere.

Speed comes from redundancy. The more connections a node has, the faster a message saturates the network. A well-connected node with fifty peers propagates a transaction roughly twice as fast as a minimal node with eight. Miners, who need transactions fast to fill blocks competitively, often run heavily connected nodes or use dedicated relay networks like FIBRE, which cut block propagation times to under a hundred milliseconds across continents.

Here's the wrinkle. That same redundancy is what lets a surveillance node deanonymize you. If an adversary runs a supernode peering with hundreds or thousands of other nodes simultaneously, it hears about transactions very early in their propagation. The first node to tell the adversary about a transaction is statistically likely to be close to the origin in the network graph. With enough vantage points, timing analysis can triangulate the originating IP address with meaningful accuracy. Researchers at UC Berkeley and collaborating institutions demonstrated this was practically feasible against the pre-Dandelion network, and the finding was not subtle.

Faster propagation means your transaction arrives at surveillance nodes sooner, with a cleaner timing signal. Privacy and speed pull in opposite directions. That's not a bug to be patched; it's a structural property of the design.

How Dandelion Tried to Square the Circle

Bitcoin Improvement Proposal 156, known as Dandelion and later refined as Dandelion++, proposed a two-phase broadcast to attack this tradeoff directly.

The stem phase: when your node creates a transaction, instead of flooding immediately, it sends to exactly one peer. That peer passes it to exactly one of their peers. This continues for a random number of hops, somewhere between two and ten, chosen probabilistically. During this phase, the transaction is invisible to the broader network. A single, thin line of transmission. Hence the stem.

The fluff phase: at a random point along the stem, one node switches to normal flooding. The transaction explodes outward in the familiar gossip pattern.

The result is that by the time surveillance nodes hear the transaction, it looks like it originated from the node that entered the fluff phase, not from your wallet. The anonymity set isn't perfect, but it's substantially larger. A passive adversary watching the network can no longer reliably point at the first node to broadcast and say "that's the sender."

The catch: the stem phase adds latency. A transaction sitting in the stem for several hops before flooding is a transaction that reaches miners later. In a network where block times average ten minutes, a few extra seconds rarely matters for ordinary payments. For time-sensitive use cases, like replacing a stuck transaction before a block is found, that delay has real cost.

Dandelion++ is implemented in several Bitcoin node clients and is on the roadmap for broader adoption. It's not a silver bullet. A sufficiently resourced adversary running nodes at many network positions can still make probabilistic inferences. Still, the improvement over naive flooding is real and measurable.

The Small World Problem: Why Network Shape Matters More Than Node Count

Bitcoin's network is what graph theorists call a small-world network. Any node can reach any other node in roughly six to eight hops on average, even across tens of thousands of nodes. Same structural property as the "six degrees of separation" idea in social networks, and equally good at collapsing the apparent distance between strangers.

Small-world topology is excellent for propagation speed. Less excellent for privacy. When the graph diameter is small, timing attacks need fewer vantage points to triangulate origin. A surveillance adversary doesn't need to be directly connected to you. They just need to be within two or three hops, which in a small-world network is almost everyone.

Consider the concrete case. Two people, call them Amara and Jens, both running full Bitcoin nodes from home ISP connections. Amara runs a default Bitcoin Core node with eight outbound peers and no Tor. Jens routes his node through Tor, accepting the latency hit of roughly 200 to 400 milliseconds per hop. Amara's transaction reaches miners faster. Jens's transaction, by the time any adversary hears it, appears to originate from a Tor exit node somewhere in Europe, not from his home IP in Stockholm. Amara optimized for speed. Jens optimized for privacy. The network topology punished each of them for the choice they didn't make.

Tor routing is, frankly, the most practical tool available to ordinary users today for unlinking transactions from IP addresses. I2P support has been added to Bitcoin Core as well. Both add latency. Neither is magic.

What People Get Wrong About "Confirmed" Meaning "Safe"

There's a widespread assumption that once a transaction is confirmed in a block, the privacy question is settled. Wrong, in an important and specific way.

Confirmation is about finality, not anonymity. The propagation phase, those first few seconds before any miner touches your transaction, is when IP-layer deanonymization happens. By the time your transaction appears in a block, any adversary watching the network has already logged which IP address first announced it. The blockchain record is pseudonymous by design. The propagation record, held in server logs of surveillance nodes, is potentially not pseudonymous at all.

This is why on-chain privacy tools like CoinJoin, which mix transaction outputs to break the transaction graph, don't address propagation privacy. They solve a different problem. A CoinJoin transaction broadcast from an unprotected IP is still linkable to a physical location at the moment of broadcast, even if the coins themselves become harder to trace afterward. The two threat models don't overlap as much as people want them to.

So here's the question worth sitting with: are you actually protecting against the threat you face, or the one that's easier to explain? If you're routing your node over Tor or I2P and using Dandelion-enabled software, you're addressing both the IP layer and the timing-analysis layer simultaneously. That combination is the actual threat model worth thinking about.

Bitcoin's network topology isn't an accident. It's a set of engineering choices made under real constraints, and those choices encode a genuine tradeoff. The pipes connect the way they do for reasons, and the reasons have consequences.