Bitcoin Optech #417: Draft BIP Proposes Sharing Stale Block Tips

When Two Miners Solve the Puzzle at Once

Bitcoin mining is a race. Every ten minutes on average, miners around the world compete to add the next block to the blockchain. Sometimes two miners solve the puzzle at almost the same moment. Both blocks are valid, but only one can stay in the chain. The loser is called a stale block — or an orphan block tip. Most software simply discards it.

Stale blocks are not a sign that Bitcoin is broken. They happen naturally when the network is large and miners are spread across the globe. A node in Tokyo might briefly accept a block that a node in Frankfurt never saw, and vice versa. The Bitcoin network resolves the tie automatically by extending whichever chain grows longer first, following the longest-chain rule.

The problem is that once a stale block is discarded, its data disappears. Developers lose a record of how two competing blocks raced. The `bitcoin-data/stale-blocks` GitHub dataset, maintained by Bitcoin researchers, tries to preserve some of this data manually. But manual collection is slow and incomplete. A formal protocol for sharing stale tips would do the job automatically and consistently across every participating node.

A Draft BIP to Share What Nodes Already Know

Bitcoin Optech Newsletter #417, published August 7, 2026, leads with a draft Bitcoin Improvement Proposal — a BIP — that would change how nodes handle orphaned block tips. Right now, when a node decides a competing block lost the race, it drops that block and moves on. The draft BIP would instead let nodes send those stale headers to their peers over the existing peer-to-peer network.

The proposal's authors, including developer Anthony Towns, argue that sharing stale tips gives every participant a better view of what is actually happening on the Bitcoin mining network. If stale blocks appear more often than expected, that could point to a validation bottleneck — perhaps a new block format that some nodes process slowly. Catching those bottlenecks early helps developers fix problems before they become serious.

One further motivation is transparency about selfish mining. Selfish mining is a theoretical attack where a miner secretly builds extra blocks before announcing them, gaining an unfair advantage. Stale tip data is consistent with this behavior, though slow propagation and geographic distance also produce stale blocks. The draft BIP does not have an official number yet; it remains a pre-numbered proposal open for community comment.

What the March 2026 Reorg Revealed

The draft BIP did not appear in a vacuum. In March 2026, a two-pool reorganization occurred at block 941,881. A reorganization — often called a reorg — happens when the network briefly follows two competing chains and then switches to the longer one. At block 941,881, two different mining pools produced competing blocks, forcing the rest of the network to pick a winner and discard the loser.

That event highlighted exactly the kind of data gap the draft BIP targets. Researchers could see that a reorg happened by looking at the chain afterward, but the detailed header data from the losing block had already been discarded by most nodes. Without that data, it is hard to know how long the two chains competed, which pool found each block first, and whether propagation delays played a role in the outcome.

Better stale-tip data would give researchers precise tools to answer those questions after future events. Monitoring tools like the Bitcoin mining dashboard already track block times and pool shares in real time, but they cannot reconstruct what happened inside a reorg with the precision that shared stale-tip headers would deliver. The March 2026 event at block 941,881 gave concrete evidence that the information gap is real and costly.

Libsecp256k1 and the Rest of Newsletter #417

Beyond the draft BIP, Newsletter #417 covers a new release of libsecp256k1, the cryptographic library that Bitcoin Core uses to create and verify digital signatures. The release adds a BIP352 silent payments module, a feature that lets senders pay a receiver without reusing an address — making it harder to link transactions together. The Bitcoin wallets guide explains how Bitcoin addresses and transactions work for anyone starting from scratch.

The same release ships hardware-optimized SHA256 code and delivers roughly an 11% improvement in signature verification speed. Faster verification helps nodes process new blocks and transactions more quickly, which is especially valuable for anyone running a full node on modest hardware. The specific release version cited in the newsletter could not be confirmed from a primary source at time of publication, so that detail should be treated with caution.

Newsletter #417 also summarizes several active proposals for changing Bitcoin's consensus rules. Each sits at an early discussion stage and would require broad community agreement before any rule change takes effect. The proposals target distinct problems — signature efficiency, resistance to quantum computers, extra data storage, and transaction expiry conditions — reflecting the breadth of protocol-level work that Bitcoin developers are actively debating.

• CISA (Cross-Input Signature Aggregation, BIP460): batches signatures across inputs to shrink transaction size
• Post-quantum output types: new address formats designed to withstand future quantum computer attacks
• SegData: stores extra data inside segregated witness fields
• Input-triggered expiry: automatically invalidates certain unspent outputs after a defined condition

Sharing Stale Tips to Keep Bitcoin's Network Honest

The draft BIP for stale block tip relay is a small but precise change to how Bitcoin nodes talk to each other. Bitcoin's peer-to-peer network already relays unconfirmed transactions through the mempool, broadcasts new blocks, and shares block headers between thousands of nodes worldwide. Adding a new message type for stale tips would use that same infrastructure to collect data that currently vanishes every time a miner loses a close race.

If the proposal advances and wins a BIP number, node software authors would need to add support for the new message type. That work is not trivial, but it is also narrowly scoped. No change to Bitcoin's consensus rules is required. Nodes that do not upgrade would still function normally; they simply would not receive or forward stale tips. Adoption would grow gradually as more software added support.

Newsletter #417's lead topic is ultimately about making Bitcoin's peer network more informative without adding complexity. The draft BIP asks nodes to share data they already hold — the losing block header from a close race — rather than discarding it. That modest shift would give researchers, developers, and node operators a clearer window into how the network resolves miner competition: the same race that makes Bitcoin function reliably in the first place.