Re: [bitcoindev] [BIP Proposal] Stale Tip Relay

[Anthony Towns <aj@erisian.com.au>]

On Thu, Nov 05, 2026 at 11:19:58PM +0000, 'Antoine Poinsot' via Bitcoin Development Mailing List wrote:
> I'd like to suggest an incremental approach, and to start relaying only stale
> headers at first.

The reference implementation [0] offers three modes: no stale relay,
stale header relay only, or stale block relay, and defaults to none:

```
Argsman.AddArg("-staletips=<mode>", "Track recent stale tips for later relay. Options are 'none', 'headers', or 'blocks' (default: none)", ArgsManager::ALLOW_ANY, OptionsCategory::NODE_RELAY);
```

[0] https://github.com/w0xlt/bitcoin/tree/staletip-v4

Are you arguing that the default should not be "blocks", or that "blocks"
should not be a supported option at all, or that even writing up a
specification on how one might relay stale blocks is improper?

> This gives you most of the benefits, without having to make an argument that the
> protocol change does not negatively affect mining incentives.

I think there are a few simple arguments why this does not meaningfully
affect mining incentives:

 (a) any miner that would benefit from improved stale block relay can
     cheaply implement this themselves; this is cheap particularly when
     compared to the resources needed to deploy an attack controlling
     a significant portion of mainnet hashrate.

 (b) mining incentives are centred on the block with the highest
     cumulative proof of work, which is never a stale block; so this
     can have at most second order effects: ie, far weaker than the
     incentives to avoid mining stale blocks in the first place

 (c) it only changes relay speeds, and relay of a new tip that's based
     off previously stale blocks is already quite fast, so any incremental
     improvement here only has the potential for a very small impact.

There are, I think, two main benefits to relaying stale blocks at the same
height as the current tip [1]:

 * it gives awareness to the network as a whole into what exactly is
   being mined, removing concerns that an honest miner working on a
   stale block might have been engaging in a block-withholding attack
   when a reorg later occurs

 * it makes it apparent if there is were double-spends, or if a
   significant percentage of hashrate is censoring transactions (either
   due to a widely accepted soft fork, or due to an attempted 51% attack).

(That you can reorg faster if the stale tip is extended and becomes part
of the most work chain, rather than the one you had picked is a benefit,
but the only case I can think of that making a meaningful difference is
you had an attacker mining a chain of slow-to-validate attack blocks,
with an alternative chain being built that excluded those, and furthermore
if many nodes also supported parallel validation of stale tips, so that
nodes could easily follow/reorg to the fast-to-validate chain, even if
it frequently had less work)

[1] I don't think there's any concern about sharing stale blocks that
    have signficantly less cumulative work than the current tip, which
    already occurs via the stale-blocks repo at
    https://github.com/bitcoin-data/stale-blocks/

> 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.

I think we can put numbers on this, based on reported numbers from "erin"
during the two-block reorg around block 941880 [2]:

 * it takes about 1.2s to download three blocks for a 2-block reorg
 * it takes about 1.2s to disconnect a couple of blocks
 * it takes about 1.25s to validate/connect the alternative pair of blocks
 * it takes about 0.7s to connect the new tip

[2] https://bnoc.xyz/t/two-block-reorg-at-height-941880/97/23

If Foundry had mined block 941883 on top of Antpool's 941882 instead of
its own stale block, the comparison would have been something like:

 * Reward: 3.14 BTC for one block versus 9.4 BTC for three blocks
 * Validation time: 0.7s versus 4.3s; so 0.12% versus 0.7% chance of
   a block being found during validation

Assuming Foundry had 20% hashrate, those numbers look like:

 * 3.14 * (99.9% * 80% + 20%) = 3.137 BTC expected, if you find a block
 * 9.4 * (99.3% * 80% + 20%) = 9.347 BTC expected, if you find a block

Those numbers don't change much if you have less hashrate -- a
one-block-a-week miner who had somehow hit two stale blocks in a row
would get the same logic:

 * 3.14 * (99.9% * 99.9% + 0.1%) = 3.139 BTC expected, if you find a block
 * 9.4 * (99.3% * 99.9% + 0.1%) = 9.334 BTC expected, if you find a block

You can dive deeper into selfish-mining attack scenarios there, but the
only difference is the 1s or 2s to relay the ancestor blocks for a new
most-work-tip, which you can set your own infrastructure up to optimise
for, if it turns out to matter.

I think that two-block reorg is also a good example where knowing in
advance both that the stale blocks existed and what their contents were
would have been helpful. You can see examples of people jumping to
the conclusion that this was an attack at:

 * https://bnoc.xyz/t/two-block-reorg-at-height-941880/97/32
 * https://x.com/wk057/status/2036674054971703361
 * https://stacker.news/items/1460047

Had the stale blocks that were found 1s/1.2s after the AntPool/ViaBTC
blocks been quickly propagated via stale block relay, that would have
refuted concerns about selfish mining -- both the block timestamp and
transactions in the block would demonstrate the block was published
in a timely fashion. With nTime rolling, the headers alone might not
provide good evidence that there wasn't a selfish mining attack occurring
(though in this case the timestamps appear to have been accurate based on
the stratum job data in the bnoc thread), while the transactions making
up the block likely would, and would also address any concerns about
potential censorship or double-spends shoudl a reorg eventually occur.

> 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.

This is effectively https://en.wikipedia.org/wiki/Precautionary_principle

I don't think it makes sense -- if we're afraid this feature would be
detrimental, then we should be equally worried about it if an attacker
were to implement something similar in secret, and should thus perform
the analysis and, if appropriate, implement countermeasures anyway:

I think the opposite logic is also worth considering here: selfish mining
already suggests (via the gamma parameter) there is an advantage for
an attacker if they can relay their blocks more effectively than honest
miners, so, if anything, having the honest network not relay stale blocks
seems likely to be providing an advantage to an attacker who adds their
own relay infrastructure on top of the honest network's.

> 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.

As per the above, I don't find this concerning; and perhaps more
generally, I don't find relaying information that's backed by
mainnet-levels of proof of work per byte to be concerning.

Cheers,
aj

-- 
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/avHvtxnvoNwbczC8%40erisian.com.au.