P2P Protocol Evolution: Two Proposals
WHY THIS MATTERS
Bitcoin's P2P layer is how nodes gossip blocks, transactions, and addresses. Improving it makes the entire network more resilient, flexible, and future-proof. These two proposals tackle complementary problems in how peers communicate.
PROPOSAL 1
Stale Tip Relay
A new P2P message (
Author: Anthony Towns (ajtowns)
A new P2P message (
staletip) that lets peers announce recent stale block headers and the availability of their content. Helps the network prepare for potential chain reorganisations.Author: Anthony Towns (ajtowns)
PROPOSAL 2
Peer Feature Negotiation (BIP-434)
A new mechanism for peers to announce and negotiate support for individual P2P features, replacing the rigid protocol version bump system.
Author: Anthony Towns (ajtowns)
A new mechanism for peers to announce and negotiate support for individual P2P features, replacing the rigid protocol version bump system.
Author: Anthony Towns (ajtowns)
CONNECTION
BIP-434 provides the framework for negotiating new P2P features. Stale tip relay is exactly the kind of feature that would benefit from this framework — peers can advertise stale tip support without requiring a protocol version bump.
Stale Tip Relay
THE PROBLEM
When two miners find valid blocks at roughly the same height, the network picks one as the active tip and the other becomes stale. Currently, stale blocks are simply discarded. But if a child of the stale block is found next, the entire chain reorganises — and nodes that didn't keep the stale block must download it from scratch, slowing reorg processing.
Block N
→
Block N+1a
active tip
active tip
Block N
↘
Block N+1b
stale (equal PoW)
stale (equal PoW)
→
Block N+2
child of stale → REORG
child of stale → REORG
THE SOLUTION:
staletip MESSAGENodes announce recent stale block headers to peers via a new
staletip P2P message. The message contains the stale header data and signals that the full block content is available for download. Peers can pre-download stale blocks so that if a reorg occurs, they already have the data and can switch chains instantly.
staletip message:
headers: vector of block headers // recent stale tips
availability: bitfield // full block content available?
// Sent when a node discovers a block at the same height
// as its active tip with equal cumulative PoW
headers: vector of block headers // recent stale tips
availability: bitfield // full block content available?
// Sent when a node discovers a block at the same height
// as its active tip with equal cumulative PoW
BENEFIT
Faster reorgs — nodes already have the stale block data when the reorg happens, reducing the window where the network is split. Particularly valuable for miners who lose revenue during slow reorgs, and for Lightning nodes that depend on timely block processing.
Peer Feature Negotiation (BIP-434)
THE PROBLEM WITH PROTOCOL VERSIONS
Historically, every new P2P feature required bumping the protocol version number. This creates a rigid, all-or-nothing system: a node either supports version N (with all its features) or it doesn't. Different implementations (Bitcoin Core, btcd, libbitcoin, etc.) adopt features at different paces, making version numbers meaningless as capability indicators.
OLD WAY
version message:protocol_version = 70016
Implies support for all features up to 70016. No way to say "I support compact blocks but not addr v2."
NEW WAY (BIP-434)
feature messages (sent between version and verack):Each feature gets its own identifier. Peers independently declare which features they support. Granular, composable, decentralised.
PROTOCOL FLOW
Between
version and verack, peers exchange feature support:Node A
→
feature("staletip")
→
Node B
Node A
←
feature("erlay")
←
Node B
feature: // sent once per supported feature, between version and verack
feature_name: string // e.g. "staletip", "erlay"
feature_params: bytes // optional per-feature parameters
feature_name: string // e.g. "staletip", "erlay"
feature_params: bytes // optional per-feature parameters
WHY THIS MATTERS FOR DECENTRALISATION
Version bumps created an implicit dependency on Bitcoin Core's release schedule. BIP-434 lets any implementation adopt any feature independently. A btcd node could support stale tip relay without waiting for Bitcoin Core to define a new protocol version. This is how a multi-implementation ecosystem should work.
How They Fit Together
THE COMPOSABLE P2P FUTURE
BIP-434 is infrastructure; stale tip relay is a feature built on that infrastructure. Together, they demonstrate a pattern for how the P2P protocol can evolve without coordination bottlenecks.
Pre-BIP-434
New P2P feature? Bump protocol version. Wait for all implementations to catch up. Ship everything or nothing.
BIP-434 Deployed
Peers negotiate features individually. Each feature has its own identifier. Implementations adopt at their own pace.
Stale Tip Relay
Registered as a feature via BIP-434. Peers that support it negotiate automatically. Others ignore it — fully backward compatible.
Future Features
Erlay (bandwidth-efficient tx relay), improved addr relay, new block propagation methods — all negotiated the same way.
PATTERN ESTABLISHED
1. Write a BIP defining the feature
2. Register a feature identifier
3. Implement in your node software
4. Peers negotiate support automatically
5. No global coordination required
2. Register a feature identifier
3. Implement in your node software
4. Peers negotiate support automatically
5. No global coordination required
NETWORK BENEFITS
Resilience: Stale blocks pre-downloaded for faster reorgs
Flexibility: Features adopted independently per implementation
Extensibility: Clean path for future P2P improvements
Flexibility: Features adopted independently per implementation
Extensibility: Clean path for future P2P improvements
Modular P2P
From monolithic version numbers to composable feature negotiation