[bitcoindev] [BIP Proposal] Stale Tip Relay

[bitcoindev] [BIP Proposal] Stale Tip Relay

[Ram]

[-- 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 --]

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

[Edil Guimarães de Medeiros]

[-- Attachment #1: Type: text/plain, Size: 5700 bytes --]

There's an ongoing effort to document mainnet stale blocks:
https://github.com/bitcoin-data/stale-blocks
As one can imagine, since there is currently no way to recover them from
the network itself, this
requires constantly monitoring several long running nodes in the hope to
get them. From a monitoring
and research perspective, this proposal could be useful.

But I'm not so sure about how that improves the main purpose of the
network. Quite the contrary, seems
to open more DoS and fingerprinting vectors.

About the design, it's not clear to me how that could work in face of more
than one competing chain. For
instance, suppose I have:

            /- C4
A1 - A2 - A3 - A4
       \- B3 - B4

It's not clear to me how the proposal deals with communicating this, which
is quite common in signet and
the testnets, since each message is designed to relay a single competing
branch (e.g. B3-B4 above).

Left more detailed and editorial comments in the bip repository PR.

Cheers.
Edil

Em qua., 29 de jul. de 2026 às 14:28, Ram <pseudoramdom8@gmail.com>
escreveu:

> 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
> <https://groups.google.com/d/msgid/bitcoindev/d92f1615-368b-4406-b326-a1799c72a555n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
Edil

-- 
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/CANJiN3%2BKetUeNjjeRgd7xgCSF%2BvAakDtH7ysPC%2Bh4DqtHJPsLA%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 7701 bytes --]

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

[Ram]

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

Hi Edil,

Appreciate taking the time to review the BIP.

> But I'm not so sure about how that improves the main purpose of the 
network. 
Quite the contrary, seems to open more DoS and fingerprinting vectors.

For DoS, the concern is whether a small message can cause disproportionate 
processing, disk usage, or outgoing traffic. Merely sending invalid data is
not a new DoS vector; peers already have many ways to do that. It's not 
possible to prevent all of them.

Currently, I don’t see any resource-exhaustion or bandwidth amplification 
vector
introduced by this proposal. Processing is bounded by the branch-length,
recency and retained-tip limits. Nodes are not required to download stale 
block
data. Nodes that choose to collect it use the normal block-download 
mechanisms
and resource limits. Implementations may also apply stricter limits, 
rate-limit
abusive peers, or disable the feature.
Also on mainnet, producing stale headers requires real proof of work 
comparable
to the active chain.
  
On fingerprinting - supporting staletip does add another observable 
characteristic.
This is a trade-off the node makes when enabling the feature and is common 
to 
optional P2P features generally. Nodes for which this trade-off is 
unacceptable
can disable staletip relay.

> About the design, it's not clear to me how that could work in face of more
than one competing chain.

Each staletip message describes one linear branch. Assuming A1-A2-A3-A4 is 
the 
active chain, the two competing branches would be announced separately:

staletip(fork_point=A2, headers=[B3, B4])
staletip(fork_point=A3, headers=[C4])

The protocol announces competing branches in separate messages. 
I’ve clarified this in the BIP draft. Thanks for pointing it out :)

Thanks again for reviewing. Hope this addresses your concerns.
Feel free to reach out or leave additional comments.

Cheers,
Ram

On Tuesday, August 11, 2026 at 7:04:41 AM UTC-7 Edil Guimarães de Medeiros 
wrote:

> There's an ongoing effort to document mainnet stale blocks: 
> https://github.com/bitcoin-data/stale-blocks
> As one can imagine, since there is currently no way to recover them from 
> the network itself, this
> requires constantly monitoring several long running nodes in the hope to 
> get them. From a monitoring
> and research perspective, this proposal could be useful.
>
> But I'm not so sure about how that improves the main purpose of the 
> network. Quite the contrary, seems
> to open more DoS and fingerprinting vectors.
>
> About the design, it's not clear to me how that could work in face of more 
> than one competing chain. For
> instance, suppose I have:
>
>             /- C4
> A1 - A2 - A3 - A4
>        \- B3 - B4
>
> It's not clear to me how the proposal deals with communicating this, which 
> is quite common in signet and 
> the testnets, since each message is designed to relay a single competing 
> branch (e.g. B3-B4 above).
>
> Left more detailed and editorial comments in the bip repository PR.
>
> Cheers.
> Edil
>
> Em qua., 29 de jul. de 2026 às 14:28, Ram <pseudo...@gmail.com> escreveu:
>
>> 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+...@googlegroups.com.
>> To view this discussion visit 
>> https://groups.google.com/d/msgid/bitcoindev/d92f1615-368b-4406-b326-a1799c72a555n%40googlegroups.com 
>> <https://groups.google.com/d/msgid/bitcoindev/d92f1615-368b-4406-b326-a1799c72a555n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> -- 
> Edil
>

-- 
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/7bbef0df-dbb5-48d1-9671-b0cec91fcbb0n%40googlegroups.com.

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

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

['Antoine Poinsot' via Bitcoin Development Mailing List]

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.

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

[Anthony Towns]

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.