Personal
Bitcoin Full Node in Docker
A Bitcoin full node that reaches the network only over Tor and keeps the full transaction index, configured for asking questions about the chain rather than for validating one wallet.
A Compose stack that brings up a Bitcoin full node, a Tor proxy, a Mempool dashboard, a block explorer, and a small Python client for talking to the node from a script.
- Stack
- Bitcoin Core v27 · Tor · Mempool · BTC RPC Explorer
- Networking
- onlynet=onion, no clearnet peers
- Storage
- Unpruned block data and a full transaction index
- Repository
- VincenzoImp/bitcoin-fullnode-docker
The problem
Analysis over Bitcoin usually starts by calling somebody’s API, and that has two costs that only show up later. The provider sees every query, which for chain analysis means telling a third party exactly which addresses you are interested in. And the answers arrive already shaped: whatever the endpoint chose to expose, at whatever granularity.
What I built
Five containers on one network. The node’s configuration is where the decisions are.
onlynet=onion with the Tor proxy means the node connects to peers only through Tor. There is
no clearnet peer fallback. This keeps the node’s IP address out of direct peer connections;
the Python client’s RPC queries go to the local node.
txindex=1 with prune=0 keeps a complete index of every transaction, which is what makes the
node answer arbitrary lookups rather than only questions about its own wallet. The Python client
wraps the RPC interface in about ten methods – blocks, transactions, mempool, peers, fee
estimates, address balances – so a notebook can query the chain directly.
Hard parts
Tor-only costs you the initial sync. Downloading several hundred gigabytes through onion circuits is materially slower than over clearnet, and it makes the node’s availability depend on Tor’s. That is the price of not announcing an IP, and it is paid once, at the worst possible moment: the beginning.
Retaining the history needed for analysis. Unpruned block data and txindex enable arbitrary
historical transaction lookups at a storage cost that grows with the chain. Pruning reduces disk
usage but removes the historical blocks those queries need.