Adam
Bitcoin Core v32.0.0 with privatebroadcast, pruned chain, 1,000 MB mempool. Normal peers can use IPv4, IPv6, Tor, I2P, and CJDNS; private broadcast itself selects privacy-network peers through Tor or I2P.
Tools · Explicit network action
Private Bitcoin Transaction Broadcast
Broadcast one signed raw Bitcoin transaction through either of my Bitcoin Core nodes: Adam or Martti. Both use Bitcoin Core’s private-broadcast mode; you can then optionally observe propagation across five nodes.
This broadcasts a real transaction. Preparing is read-only. Nothing is sent until the separate confirmation step. After confirmation there is no automatic retry if the outcome is uncertain.
Signed raw transaction → BitcoinStats → selected private-broadcast origin → five-node propagation observation
Bitcoin Core · Privacy mode
How private broadcast works
Martti
Bitcoin Core v31.1.0 with privatebroadcast, full archival chain with txindex, 300 MB mempool. It is intentionally Tor-only, so both its normal peer traffic and private-broadcast connections stay on Tor.
After you confirm, BitcoinStats submits the transaction to the selected node exactly once. Bitcoin Core does not first place it in that node’s own mempool or announce it through its existing peers. Instead, it schedules the transaction for private broadcast and opens dedicated, short-lived connections through Tor or I2P. The current implementation sends through three independently selected peers and uses a separate connection for each transaction, providing best-effort concealment of the sender’s IP address and reducing linkage between unrelated broadcasts.
The selected origin may therefore initially report the transaction as absent. It can appear in that node’s mempool later only after it propagates through the wider Bitcoin network and returns through a normal peer connection.
Tor or I2P connection setup and normal peer-to-peer propagation are asynchronous. The first observer detection may happen within seconds, but it can also take several minutes—or remain unseen if other nodes reject the transaction. The timestamps below record when each BitcoinStats-operated node first detected it, not when the first network peer received it.
BitcoinStats makes one submission call and never repeats an uncertain request automatically. After that call succeeds, Bitcoin Core manages its own bounded private-broadcast peer attempts.
Private broadcast is a best-effort privacy mechanism, not an anonymity guarantee.
Official documentation: Bitcoin Core 31.0 release notes · P2P and network changes. Connection counts change continuously; the node operations page shows the current live state.
1 · Prepare
Recommended preflight
Before broadcasting, check whether Andreas, Hal, Martti, Adam, and Peter would currently accept this transaction into their mempools. This optional point-in-time test is read-only and does not broadcast or store the transaction.
Nothing has been submitted. Running this check sends the signed transaction to the five BitcoinStats-operated nodes for one read-only policy test.
Your raw transaction stays in this browser until you prepare it.
2 · Confirm broadcast
- txid
- Virtual size
- Fee
3 · Observe propagation
Private propagation is asynchronous. First detection can take several minutes. Times are server-side observations in UTC. They show when each operated node first reported the transaction, not the first moment any peer on the global network saw it. The observation runs for up to one hour from Prepare and can resume after a refresh in this tab.
Privacy and limits
Usage limits
Prepare and Confirm each count as one request. Up to 4 requests per minute per IP address are allowed, with a maximum of 2 immediate requests, so one normal Prepare + Confirm pair can proceed without waiting. Signed raw transactions may be up to 100 kB. Observation status allows up to 30 checks per minute per IP address; this page checks once every 3 seconds while a watch is active. Shared send capacity is limited to 10 requests per minute and one in-flight request, and the selected node’s private-broadcast queue may also be temporarily busy. The optional five-node acceptance test uses its own published limits.
Privacy disclosure
Your IP address and signed raw transaction reach BitcoinStats over clearnet when you press Prepare. The raw transaction is checked on the selected origin, held only in process memory for each request, and is not stored in the Send + Observe status database. Status access uses a random capability token. After sending, this tab keeps that token in sessionStorage so a refresh can resume read-only status; it is not shared with other tabs and can be removed with “Forget this observation.” Maximum fee is 1,000,000 sats and maximum fee rate is 100 sat/vB.
Mempool Acceptance Test · Raw Transaction Decoder · Transaction Lookup