This guide explains Bitcoin Core 26.0 release in plain English. It summarises the important changes, who they affect and what should be checked before an upgrade.
TL;DR
- What it is: Bitcoin Core 26.0 adds experimental BIP 324 v2 transport, assumeUTXO snapshot loading and monitoring, package submission, address-manager reporting, Taproot Miniscript and stricter wallet and configuration behaviour. These features have distinct trust and completion boundaries.
- Why it matters: Core 26.0 combines transport, synchronisation, wallet and API changes. Safe adoption separates optional experiments from the base upgrade and keeps background validation visible until the snapshot chainstate is fully justified.
- 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 26.0 release in simple English
Bitcoin Core 26.0 release: BIP324 v2 transport is experimental and off by default. When enabled it is negotiated per connection while v1 remains supported.
Simple example
A node operator is checking Bitcoin Core 26.0 release. When enabled it is negotiated per connection while v1 remains supported. Getpeerinfo exposes protocol type and session ID.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- 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.
- Mempool:
- A node’s changing local collection of valid, unconfirmed transactions.
- UTXO:
- An unspent transaction output: a piece of bitcoin that can be used as an input to a later transaction.
V2 transport
BIP324 v2 transport is experimental and off by default. When enabled it is negotiated per connection while v1 remains supported; getpeerinfo exposes protocol type and session ID.
Network diversity
Nodes with several reachable networks try to maintain an outbound connection to each. Monitor actual peers rather than assuming configured reachability equals diversity.
AssumeUTXO
loadtxoutset creates a usable snapshot-backed chainstate while the original chainstate validates in the background. Getchainstates reveals whether snapshot trust has been retired.
RPC surface
hash_serialized_2 was removed, submitpackage remained experimental without package relay, and new RPCs include getprioritisedtransactions, getaddrmaninfo and importmempool.
Wallet changes
Some corrupted wallets no longer load, new legacy-wallet creation is gated, descriptor hardened markers use h and wallet RPCs report lastprocessedblock context.
Strict configuration
Ignored datadir configuration, invalid logging options and several other ambiguous settings now cause errors. Resolve them rather than weakening diagnostics.
How specialists test it
Node operators test the release on a representative non-production system. They check startup, normal operation, failure handling and restart before changing a live node. Connected wallets, monitoring and mining services should also be checked.
Frequently asked questions
What is the main point of Bitcoin Core 26.0 release?
Bitcoin Core 26.0 release: BIP324 v2 transport is experimental and off by default. When enabled it is negotiated per connection while v1 remains supported.
For Bitcoin Core 26.0 release, what should a beginner know about v2 transport?
BIP324 v2 transport is experimental and off by default. When enabled it is negotiated per connection while v1 remains supported.
For Bitcoin Core 26.0 release, what should a beginner know about network diversity?
Nodes with several reachable networks try to maintain an outbound connection to each.
For Bitcoin Core 26.0 release, what should a beginner know about assumeutxo?
loadtxoutset creates a usable snapshot-backed chainstate while the original chainstate validates in the background.
Conclusion
Core 26.0 combines transport, synchronisation, wallet and API changes. Safe adoption separates optional experiments from the base upgrade and keeps background validation visible until the snapshot chainstate is fully justified.
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.