From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Anthony Towns <aj@erisian.com.au>
Cc: Ram <pseudoramdom8@gmail.com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Stale Tip Relay
Date: Wed, 11 Nov 2026 22:04:55 +0000 [thread overview]
Message-ID: <ktZb1ZnKZJb1qh4uGvGybRoeiMA8nD-BfozO92FtGWs3ELzPPM8QMcwL8qZJVRF9kk0jDdubLPUlxhj2YHk1Ndu2A5uMVGC8swfHAuE-IrQ=@protonmail.com> (raw)
In-Reply-To: <avHvtxnvoNwbczC8@erisian.com.au>
On Monday, November 9th, 2026 at 11:23 AM, Anthony Towns <aj@erisian.com.au> wrote:
> 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:
Just one more knob!
I think an option for this kind of thing is counterproductive. It needs to
be on by default to have an effect anyways, and if we think that it could
impose costs substantial enough that a node runner may want to disable it (i
don't) then we should reconsider our approach to data collection.
> 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?
I argue that the default should be headers.
I would also argue, but that's an implementation discussion, that we shouldn't
support "blocks" unless we intend to turn it on by default.
> > 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.
I think it's more complicated than that. The current public relay network
is an equilibrium that may be costly for each individual miner to deviate
from. For instance, a miner may not want to develop infrastructure to relay
stale blocks, then go lobby other miners to adopt it, for a slight increase
in expected revenue. But that same miner might well tweak their job
distribution, if the relay infrastructure is already deployed across the
network.
I agree the effects are most likely small, i’m just not convinced they are
negligible. My point is that it’s not worth working this out rigorously now,
when relaying headers alone gets most of the benefits without raising the
question.
> 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
Fair, it would make it possible to observe pools that start implementing
some strategic block publications without going all the way to full Selfish
mining.
>
> * 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).
I don't think transaction censorship detection is a valid argument here: at
any non-catastrophic stale rate, this barely gives any more information than
the miner's mainchain blocks.
> [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/
Fair to distinguish between relaying near tip vs historical blocks. But
this is not about sharing, it's about what should be relayed on the public
network in real time, so i don't think the Github repo is relevant here.
> I think we can put numbers on this, based on reported numbers from "erin"
> during the two-block reorg around block 941880 [2]:
We shouldn't read too much into the numbers for a single node in a
single instance, but that ~1-2s figure is roughly what i would expect
(per hop).
(Also, not important to your argument, but there is a typo in your
numbers with a lower hashrate: s/3.139/3.137/)
> 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 disagree. The current public relay network is the status quo. Changing
the default behaviour of the public relay network is not the same as
miners coordinating to deviate from it.
> 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.
The effect here is in the event of a race, non-selfish miners can reorg
faster to a non-selfish miner winning the race. That's true, but the
advantage is dwarfed by that of Selfish mining, and i think all bets
are off anyways if a miner is actively attacking the network.
My point was how this change might incentivize (or not!) a pool operator
to tweak their settings slightly, within the framework of not trying to
bypass the public relay network / pull off an involved attack like
Selfish mining.
>
> > 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.
>
--
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/ktZb1ZnKZJb1qh4uGvGybRoeiMA8nD-BfozO92FtGWs3ELzPPM8QMcwL8qZJVRF9kk0jDdubLPUlxhj2YHk1Ndu2A5uMVGC8swfHAuE-IrQ%3D%40protonmail.com.
prev parent reply other threads:[~2026-11-11 22:18 UTC|newest]
Thread overview: 6+ 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
2026-11-09 16:07 ` Anthony Towns
2026-11-11 22:04 ` '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='ktZb1ZnKZJb1qh4uGvGybRoeiMA8nD-BfozO92FtGWs3ELzPPM8QMcwL8qZJVRF9kk0jDdubLPUlxhj2YHk1Ndu2A5uMVGC8swfHAuE-IrQ=@protonmail.com' \
--to=bitcoindev@googlegroups.com \
--cc=aj@erisian.com.au \
--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