Skip to main content
£0.00 0

Basket

No products in the basket.

ASIC mining knowledge centre

Bitcoin Core waitfornewblock RPC: New Tip Notification Guide

Bitcoin Core waitfornewblock RPC made simple. See what the feature does, where its limits sit and which checks node or wallet operators should make.

Bitcoin Core waitfornewblock RPC guide cover

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.

Bitcoin Core waitfornewblock RPC technical diagram
Extension or reorg: the fields, validation boundary and operational evidence that implementations need to agree.

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.

On this page

Search More Guides

Continue Reading

Explore more practical guidance on ASIC hardware, profitability, setup, hosting and maintenance.

Need Advice for Your Mining Setup?

Use our guidance to build your shortlist, then speak to our team when you want help comparing hardware, power, hosting or repairs.
Contact our team
Browse ASIC miners