This guide explains Bitcoin Core waitfornewblock RPC in plain English. It shows what the command does, what its result means and what it cannot prove.
TL;DR
- What it is: Bitcoin Core 30.0 exposes waitfornewblock as a public RPC and adds an optional current_tip argument. The call waits for the active tip to differ from that supplied state, or for a timeout or node shutdown.
- Why it matters: waitfornewblock is a low-overhead tip-change primitive, not a complete event system. Durability comes from checkpointing, explicit comparison, ancestry reconciliation and idempotent downstream processing.
- Current position: Require a second reviewer and explicit rollback or expiry, and pause payments, signing or network-dependent services until post-change evidence is complete.
What this means in simple English
An RPC is a command sent to one Bitcoin Core node. It can ask that node for information or request a local action. A successful reply describes that node; it does not automatically prove what happened across the Bitcoin network.
Beginners can focus on the input, the result and the limit of that result. Operators should test the command on the exact Bitcoin Core version they run before relying on it.
Simple example
Think of a mempool as one node’s waiting room for valid transactions that have not yet entered a block. Different nodes can have different waiting rooms, and the contents can change from one second to the next.
Key terms in plain English
- Bitcoin Core:
- Widely used software that validates Bitcoin and can provide wallet, network and operator tools.
- RPC:
- A command that software sends to a node to request information or a local action.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Baseline tip
Supply the last processed hash and height as current_tip where supported. This closes the race between reading the tip and beginning the blocking call.
Return paths
A new tip, timeout and node exit all return a hash and height. A response is not proof of change; compare it with the supplied baseline.
Extension or reorg
A higher height usually represents extension but is not sufficient proof. Query headers or chain ancestry to identify replacements, same-height changes and deeper reorganisations.
Timeout design
The millisecond timeout defaults to zero. Choose bounded waits for health checks and cancellation, while ensuring client and reverse-proxy limits exceed the chosen server wait.
Processing loop
Persist the last fully processed tip, wait from that state, compare, fetch the path difference, apply idempotently and commit the new checkpoint only after downstream work succeeds.
Failure recovery
On transport failure or restart, query the active tip and reconcile from the durable checkpoint. Never assume a missed connection means no blocks arrived.
Scaling
One coordinated watcher can distribute internal events more safely than many unbounded RPC waiters. Add back-pressure, deduplication and observability for lag and reorg depth. Build a revision-pinned evidence pack on an isolated node, wallet or protocol harness.
Frequently asked questions
What is Bitcoin Core waitfornewblock RPC?
Bitcoin Core 30.0 exposes waitfornewblock as a public RPC and adds an optional current_tip argument. The call waits for the active tip to differ from that supplied state, or for a timeout or node shutdown.
Is Bitcoin Core waitfornewblock RPC active or supported today?
Require a second reviewer and explicit rollback or expiry, and pause payments, signing or network-dependent services until post-change evidence is complete.
Why does Bitcoin Core matter?
waitfornewblock is a low-overhead tip-change primitive, not a complete event system. Durability comes from checkpointing, explicit comparison, ancestry reconciliation and idempotent downstream processing.
Do beginners need to use the technical details?
No. The command is mainly for people who operate Bitcoin Core or software connected to it. Other readers can use the article to understand what an operator or service is measuring.
Conclusion
waitfornewblock is a low-overhead tip-change primitive, not a complete event system. Durability comes from checkpointing, explicit comparison, ancestry reconciliation and idempotent downstream processing.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
