This guide explains Bitcoin Core startupnotify in plain English. It focuses on what the subject is, why it matters and what a beginner should remember.
TL;DR
- What it is: Bitcoin Core 0.21 added startupnotify, a configuration option that runs a command after the node finishes its startup sequence. It can bridge Core into a service manager or monitoring system, but it executes local code with the node process’s authority.
- Why it matters: startupnotify is a useful lifecycle signal, not a complete readiness contract. Safe use keeps the executed command small and trusted, tolerates repeats and makes every dependent service prove its own chain, wallet and index prerequisites.
- 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.
Bitcoin Core startupnotify in simple English
Bitcoin Core startupnotify: Define precisely what Core promises at hook time and add separate probes for RPC response, selected chain, block and header progress, required indexes, peers and loaded wallets.
Simple example
A node operator is checking Bitcoin Core startupnotify. Do not assume a failed command stops Core or that success means a downstream service accepted the event.
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.
Readiness boundary
Define precisely what Core promises at hook time and add separate probes for RPC response, selected chain, block and header progress, required indexes, peers and loaded wallets.
Execution authority
The command inherits the node service account and environment. Use an absolute path to a root-owned executable, a minimal environment and no writable command directory or shell interpolation from untrusted data.
Idempotency
Restarts, crashes and administrative actions can invoke the hook repeatedly. Make the receiver idempotent, include node and boot identity and treat duplicate notifications as expected.
Failure handling
Do not assume a failed command stops Core or that success means a downstream service accepted the event. Capture exit status through a wrapper, log minimally and alert independently.
Service orchestration
Prefer a small local signal to direct privileged control. The receiver should run its own health gates and start only the precise dependent service for the intended network.
Secrets and logs
Do not embed credentials, wallet names or customer data in command arguments where process listings may expose them. Use protected local files or sockets and redact operational logs.
How specialists test it
Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.
Frequently asked questions
What is the main point of Bitcoin Core startupnotify?
Bitcoin Core startupnotify: Define precisely what Core promises at hook time and add separate probes for RPC response, selected chain, block and header progress, required indexes, peers and loaded wallets.
For Bitcoin Core startupnotify, what should a beginner know about readiness boundary?
Define precisely what Core promises at hook time and add separate probes for RPC response, selected chain, block and header progress, required indexes, peers and loaded wallets.
For Bitcoin Core startupnotify, what should a beginner know about execution authority?
The command inherits the node service account and environment. Use an absolute path to a root-owned executable, a minimal environment and no writable command directory or shell interpolation from untrusted data.
For Bitcoin Core startupnotify, what should a beginner know about idempotency?
Restarts, crashes and administrative actions can invoke the hook repeatedly. Make the receiver idempotent, include node and boot identity and treat duplicate notifications as expected.
Conclusion
startupnotify is a useful lifecycle signal, not a complete readiness contract. Safe use keeps the executed command small and trusted, tolerates repeats and makes every dependent service prove its own chain, wallet and index prerequisites.
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.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.