When you run your own Bitcoin node — the foundation of solo mining and of not trusting anyone else’s copy of the ledger — you talk to it through the JSON-RPC interface. bitcoin-cli is the front door, and behind it sits a catalog of commands grouped into categories: Blockchain, Mining, Network, Wallet, Raw Transactions, Util, Control, and Generating. This reference covers the commands a miner and node operator actually reaches for — the mining category in full, plus the blockchain and network commands that tell you whether your node is healthy and sovereign. Every description here is drawn from the canonical Bitcoin Core RPC documentation.
Two notes before the tables. First, this is a working subset, not the entire ~130-command API — it is the slice that matters for mining and running a node, which is D-Central’s lane. Second, RPC availability and exact fields evolve between Bitcoin Core releases; treat this as the stable core and confirm edge details against bitcoin-cli help <command> on your own node’s version.
Mining RPCs — the solo-mining bridge
These six commands are the literal interface between a Bitcoin node and mining hardware or software. If you are wiring an ASIC or a solo-mining setup to your own node, this is the layer that connects them.
| Command | What it does |
|---|---|
getblocktemplate |
Returns the data needed to construct a block to work on — the previous block hash, the pending transactions to include, the difficulty target, and other parameters a miner needs to build a valid candidate block. |
getmininginfo |
Returns a JSON object of mining-related state: blocks, currentblockweight, currentblocktx, difficulty, networkhashps, pooledtx, chain, and warnings. |
getnetworkhashps |
Returns the estimated network hashes per second based on the last n blocks. Optional nblocks (default 120; -1 for blocks since the last difficulty change) and height (default -1) let you estimate at a specific point. |
prioritisetransaction |
Accepts a transaction ID and a fee delta in satoshis to raise (or lower) how the mining algorithm prioritises that transaction — without actually paying the fee on-chain. |
submitblock |
Attempts to submit a newly solved block to the network. The hexdata parameter carries the hex-encoded block. |
submitheader |
Decodes the given hexdata as a block header and submits it as a candidate chain tip if valid. |
The pairing to understand: a solo miner’s software polls getblocktemplate for work, hashes it, and returns a solved block via submitblock. That loop — running against your own node rather than a pool’s server — is what makes solo mining trustless. For where solo fits versus pooled mining, see our pool vs solo decision guide and the solo-mining probability calculator.
Blockchain RPCs — is my node synced and honest?
These answer the questions every node operator asks: am I fully synced, what’s the chain doing, and how big is the state I’m validating?
| Command | What it does |
|---|---|
getblockchaininfo |
Returns overall chain state: chain (main/test/regtest), blocks, headers, bestblockhash, difficulty, verificationprogress (0–1), initialblockdownload, size_on_disk, and pruned. |
getblockcount |
Returns the height of the most-work fully-validated chain — your node’s current block height. |
getbestblockhash |
Returns the header hash of the best (tip) block on the chain your node considers valid. |
getblockhash |
Returns the header hash of the block at a given height. |
getdifficulty |
Returns the current proof-of-work difficulty as a multiple of the minimum difficulty. |
getmempoolinfo |
Returns mempool statistics: transaction count (size), virtual bytes, memory usage, maxmempool, and the minimum fee rates (mempoolminfee, minrelaytxfee). |
getrawmempool |
Returns the transaction IDs currently in your node’s mempool (optionally with verbose per-transaction detail). |
gettxoutsetinfo |
Returns statistics about the unspent transaction output (UTXO) set: block height and tip hash, output count, UTXO set size metrics, a serialized hash, estimated disk usage, and the total bitcoin amount. |
verifychain |
Re-verifies the local block database to a chosen depth and thoroughness — an integrity check of what your node has stored. |
pruneblockchain |
On a pruned node, manually prunes the block store up to a target height (or timestamp), reclaiming disk while keeping full validation. |
Network RPCs — who is my node talking to?
| Command | What it does |
|---|---|
getnetworkinfo |
Returns P2P networking state: version, subversion, protocolversion, connections (plus connections_in/connections_out), networkactive, relayfee, incrementalfee, and warnings. |
getpeerinfo |
Returns data about each connected network node as a JSON array — one object per peer, covering address, direction, version, and traffic. |
getconnectioncount |
Returns the number of connections your node currently has to other nodes. |
Companion reference: the RPC interface talks to your node; bitcoin.conf configures it — prune, dbcache, rpcauth, blocksonly and the settings that shape a sovereign or solo-mining node.
Why this matters for sovereignty
Every command above runs against a ledger you validate. A pool tells you what it wants you to believe about the chain; getblockchaininfo and getbestblockhash tell you what your own node has independently verified. Solo mining against getblocktemplate means the block you’d find is your block, built from your mempool policy — no custodian, no permission. That is the practical shape of the sovereign stack: own the node, own the template, own the ledger.
To go deeper: our Bitcoin node implementations reference compares the software that exposes this API, the mining pools hub covers the custodial-to-solo spectrum, and the Bitcoin Mining Field Manual ties the node layer to the hardware, firmware, and pool layers around it. For any command’s exact arguments on your release, bitcoin-cli help <command> is authoritative.
