[bitcoindev] [BIP Proposal] Stale Tip Relay

[Ram <pseudoramdom8@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3873 bytes --]

Hello list,

This proposal introduces `staletip`, an opt-in P2P message for relaying 
recent
stale tips between peers. Building on AJ Towns' initial work, w0xlt and I 
have
developed the proposal further and built a proof-of-concept implementation.

Draft BIP:
https://github.com/pseudoramdom/bips/blob/staletip-bip-draft/bip-staletip.md

Proof-of-concept:
https://github.com/w0xlt/bitcoin/tree/staletip-v4

Today, once a block loses a race and goes stale, it stops propagating – 
compact
block relay and FIBRE aggressively relay the winning chain, while stale 
branches fall away. That's great for fast propagation, but it makes the 
stale
rate difficult to observe. Even dedicated monitors [0] have only partial 
views:
a stale block seen by one monitor may never reach another.

The stale rate is a useful network-health signal because it is closely 
related
to block propagation delay. The longer it takes miners to learn about a 
newly
found block, the greater the chance that another valid block will be found 
at
the same height, creating a race in which one of the blocks becomes stale 
[1].
An elevated stale rate could also expose validation or relay bottlenecks.
For example, the May 2023 "inv-to-send" bug degraded block propagation and
coincided with a roughly 10x increase in the observed stale rate [2].

A stale block does not by itself identify its cause, but changes in the
rate or shape of stale branches can provide a reason to investigate:

  - a network partition – when a partition heals, blocks mined on the
    losing side become stale, potentially producing several related stale
    blocks at once.
  - adversarial mining strategies such as selfish mining [3] – these
    can cause honest miners' blocks to become stale.

The proposal fills this observability gap with an opt-in P2P message called
`staletip`, allowing nodes to proactively announce recent stale tips to 
peers.

An added benefit is potentially faster reorg handling: if a node already 
knows
the relevant headers, and perhaps has the block data, it has less work to 
do if
that branch later becomes active.

At protocol level, nodes advertise support using BIP 434 `feature` message 
[4], 
and `staletip` messages are only sent to peers that advertised support. Each
announcement contains the fork point, a sequence of compressed headers, and 
a
flag indicating whether the sender can serve the stale tip block. 

The proposed default relay policy:
  - relays only tips within 1000 blocks (about seven days) of the active 
tip, 
    keeping announcements recent and stale-tip spam costly on mainnet.
  - limits branches to 20 compressed headers, covering short-term reorgs
    without tracking persistent chain splits and keeps each announcement 
under
    1 kB.
  - keeps at most 10 recent tips in the relay cache, so announcing the full
    cache to a new peer remains under 10 kB, excluding any blocks requested.

The BIP text has more background and the full message format. Comments are
welcome.

Cheers,
Ram (pseudoramdom <https://github.com/pseudoramdom>)
& 
w0xlt <https://github.com/w0xlt>

[0] https://github.com/bitcoin-data/stale-blocks
[1] 
https://delvingbitcoin.org/t/propagation-delay-and-mining-centralization-modeling-stale-rates/2110
[2] https://b10c.me/observations/15-inv-to-send-queue/
[3] https://arxiv.org/abs/1311.0243
[4] https://github.com/bitcoin/bips/blob/master/bip-0434.md

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/d92f1615-368b-4406-b326-a1799c72a555n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 4437 bytes --]