RPC

Everything that automates bitcoin talks to a node this way. Bitcoin Core listens on port 8332 for HTTP requests carrying JSON, answers one call at a time, and by default accepts connections only from the machine it runs on. If a service has ever quoted you a fee estimate or told you a withdrawal confirmed, some RPC call produced that answer.

How it works

An RPC call is an HTTP POST whose body names a method and lists its arguments.

Ask for getblockchaininfo and back comes the chain name, the current height, the verification progress and the size on disk. Ask for listunspent or sendtoaddress and you are driving the node's wallet. Ask for getrawtransaction and you get bytes. The bundled bitcoin-cli program is a thin wrapper that builds the JSON, posts it and prints the reply, so anything you can type at a command line a program can do over a socket.

Authentication has a history worth knowing. Bitcoin Core dropped its built-in SSL support in version 0.12.0, so the interface speaks unencrypted HTTP and nothing else. That same release introduced the cookie file, a random credential written into the data directory at startup and replaced on every restart, which is why bitcoin-cli works on your own machine without you ever setting a password. For remote callers there is rpcauth, which stores a salted hash in the configuration file rather than a plaintext secret. There is still no transport encryption, so reaching a node across a network means an SSH tunnel, a VPN or a Tor hidden service, and nothing else will do.

Each network gets its own port so several daemons can share one machine: 8332 on mainnet, 18332 on testnet3, 48332 on testnet4, 38332 on signet and 18443 on regtest. Mainnet's RPC port sits directly below the peer-to-peer port 8333, and confusing the two is a common first mistake.

The dialect has moved slowly. Bitcoin Core answered a loose variant of JSON-RPC 1.0 for well over a decade, and version 28.0 taught the server to recognise JSON-RPC 2.0 requests and reply in strict conformance with that specification while still accepting the older style. Wallet-specific calls are addressed by path, so a node holding several wallets routes them through /wallet/ followed by the wallet name.

Where you see it

RPC is the seam between bitcoin itself and every product built on top of it.

A Lightning implementation asks a node for blocks and pushes closing transactions through it. Block explorers, mempool dashboards and payment processors such as BTCPay Server sit on a bitcoind instance and wrap it in something friendlier. An exchange's withdrawal system is, at the bottom of the stack, a queue of sendrawtransaction calls. When our exchange reviews note that a platform batches withdrawals, the batching happens in code that ends up here.

This is also where self-hosted setups get compromised. Port 8332 is scanned constantly, and a node published to the open internet with a guessable password and a loaded wallet is a wallet that will be emptied. Keep the interface bound to the local machine, and tunnel in if you need it from elsewhere.

RPC vs RPC byte order

RPC and RPC byte order share an acronym and nothing else, which causes real bugs. RPC is the interface. RPC byte order is a display convention: block and transaction hashes are computed and transmitted in one direction and printed by the RPC layer in the reverse, which is why a txid copied from a block explorer reads backwards compared with the same 32 bytes sitting inside a raw transaction. Feed a copied txid straight into a byte-level parser without reversing it and the lookup will simply never match.