From: Ram <pseudoramdom8@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Stale Tip Relay
Date: Thu, 13 Aug 2026 11:53:11 -0700 (PDT) [thread overview]
Message-ID: <7bbef0df-dbb5-48d1-9671-b0cec91fcbb0n@googlegroups.com> (raw)
In-Reply-To: <CANJiN3+KetUeNjjeRgd7xgCSF+vAakDtH7ysPC+h4DqtHJPsLA@mail.gmail.com>
[-- 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 --]
prev parent reply other threads:[~2026-08-13 18:58 UTC|newest]
Thread overview: 3+ 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 [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=7bbef0df-dbb5-48d1-9671-b0cec91fcbb0n@googlegroups.com \
--to=pseudoramdom8@gmail.com \
--cc=bitcoindev@googlegroups.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