[BIP Proposal] Stale Tip Relay

Stale blocks occur when two valid blocks are produced at nearly the same height, leading to one being orphaned after the chain resolves. Existing relay mechanisms such as compact block relay and FIBRE have limitations in detecting these events because they emphasize rapid propagation along the longest chain. Consequently, many stale branches go unnoticed unless there is dedicated monitoring, and even then, only fragments of these branches may be observed. The introduction of staletip aims to address this gap by facilitating an optional peer-to-peer messaging framework where nodes can exchange information about recently seen stale tips. This system leverages BIP 434 feature messages for capability signaling and includes mechanisms for sharing compressed header sequences and status flags, all while maintaining efficiency through constraints like a 1000-block recency window, a maximum chain segment length of 20 headers, and a cache size limited to 10 recent tips.

The collaborative development process has been transparent and inclusive, with resources such as the Draft BIP and Proof-of-concept made publicly available for review. By enhancing the observability of stale rates and associated block propagation dynamics, staletip offers deeper insights into potential issues like network partitions or adversarial mining tactics. These improvements can facilitate faster responses to reorganizations and enable more robust diagnostics, which are crucial for maintaining the resilience and security of the Bitcoin protocol.

Alongside the protocol development, ongoing efforts to document mainnet stale blocks play a vital role in research and transparency. Since the Bitcoin network lacks a native mechanism for retrieving historical stale blocks, this initiative depends on long-term node operation and collective documentation, as reflected in the open-source repository here. While this data collection enhances understanding of network events, it also raises concerns regarding increased exposure to denial-of-service (DoS) attacks and fingerprinting risks. The current design's capacity to handle multiple competing chains remains limited, especially in environments like signet and testnets where frequent forks occur. Only one branch per message can be relayed, highlighting a need for further refinement to ensure comprehensive communication across all active blockchain segments.

Security and privacy remain at the forefront of the discussion surrounding staletip. Potential DoS vectors were examined, but the proposed implementation mitigates resource exhaustion through strict limits on branch length, recency, and retained-tip caches. Nodes are not compelled to download obsolete blocks, and standard mitigation techniques—such as rate-limiting or disabling problematic features—remain applicable. The issue of fingerprinting, whereby enabling staletip could reveal unique behavioral patterns, is acknowledged as an inherent trade-off for enhanced observability. Importantly, participation in staletip remains optional, allowing node operators to weigh the benefits against possible privacy risks.

Feedback from contributors emphasizes a cautious, incremental approach to deploying these enhancements. One suggestion advocates for initially limiting the relay to stale headers rather than full block content. This strategy preserves most of the diagnostic value without impacting mining incentives or altering broader network economic behavior. Relaying headers alone makes the existence of stale blocks observable without affecting the incentive structure related to mining on conflicting chains. More extensive changes involving additional block data, such as pool attribution or validity proofs, should only be considered after evaluating their impact on miner incentives and network stability.

In summary, the staletip proposal represents a thoughtful step forward in improving the transparency and responsiveness of the Bitcoin network to stale block events. Ongoing dialogue, code reviews, and real-world testing will continue to guide its evolution, ensuring that both the operational integrity and the security of the protocol are preserved while expanding the community’s insight into block propagation phenomena.