From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Ram <pseudoramdom8@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Stale Tip Relay
Date: Thu, 05 Nov 2026 23:19:58 +0000 [thread overview]
Message-ID: <3rRzUIQUWDcT-ASQXvovARX12jzE0UWy0RQ8fk7M_z3bW_k2LWPPEvRhoD6sEe3GW3fjCdtzLOZN34TCsB2CI6iRcdjer9Y8QiNwUh2QepI=@protonmail.com> (raw)
In-Reply-To: <d92f1615-368b-4406-b326-a1799c72a555n@googlegroups.com>
Hi,
This is useful, good to see progress on this.
I'd like to suggest an incremental approach, and to start relaying only stale
headers at first.
This gives you most of the benefits, without having to make an argument that the
protocol change does not negatively affect mining incentives.
As you note yourself:
> 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.
This increases the expected revenue of (temporarily) mining on top of your block
in the event you lose a race.
On the other hand, this accelerates convergence slightly as honest miners on the
losing side switch to the winning chain faster.
So clearly such a change affects the incentive structure, and would require
analyzing whether it's a greater force for convergence or divergence, or at all
meaningful.
Performing this analysis for a message which aims to make the *presence* of stale
blocks more observable seems overkill to me. Headers alone are enough for this,
and pre-relaying them does not affect the incentive structure in the same way.
Therefore i suggest to specify and implement relay of stale headers, then later
revisit whether the additional information present in the block content (pool
attribution from the coinbase, and validity, i suppose?) is worth the work on
analyzing the effect on the incentive structure.
Best,
Antoine
On Wednesday, July 29th, 2026 at 1:28 PM, Ram <pseudoramdom8@gmail.com> wrote:
> 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)&
> 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.
--
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/3rRzUIQUWDcT-ASQXvovARX12jzE0UWy0RQ8fk7M_z3bW_k2LWPPEvRhoD6sEe3GW3fjCdtzLOZN34TCsB2CI6iRcdjer9Y8QiNwUh2QepI%3D%40protonmail.com.
prev parent reply other threads:[~2026-11-05 23:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 17:21 [bitcoindev] [BIP Proposal] Stale Tip Relay Ram
2026-08-11 13:51 ` Edil Guimarães de Medeiros
2026-08-13 18:53 ` Ram
2026-11-05 23:19 ` 'Antoine Poinsot' via Bitcoin Development Mailing List [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='3rRzUIQUWDcT-ASQXvovARX12jzE0UWy0RQ8fk7M_z3bW_k2LWPPEvRhoD6sEe3GW3fjCdtzLOZN34TCsB2CI6iRcdjer9Y8QiNwUh2QepI=@protonmail.com' \
--to=bitcoindev@googlegroups.com \
--cc=darosior@protonmail.com \
--cc=pseudoramdom8@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox