From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 29 Jul 2026 10:28:59 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wp85S-0003rT-KO for bitcoindev@gnusha.org; Wed, 29 Jul 2026 10:28:59 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-451ff8b9acbsf83906fac.0 for ; Wed, 29 Jul 2026 10:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1785346132; x=1785950932; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:sender:from:to:cc :subject:date:message-id:reply-to:content-type; bh=jj+QoV7lrgaUkyKWFX2Af9gY1Kh3s6qOrf7ExndUYWk=; b=K8AK9I48oHSDWKInhUtYUzF1p/IsmLO9laax8B3rAHLPYEajpmKcXCRCpg1xJkYSI/ lZZnU0hVMn95/wc+FZbVU8Y9jgnDwxRHc4Jui75TmizrK/xlg48IZpzBQ3zDt6bwEB7I StjQsm0OnCWt4KuS7+Ff1PDsrajc6eWJrz9Rz81Z+vTg+TvTwXMJr1MwvLy5iU1UgiMv s84KOwvJ4H6UeNILZ4RgPQXh2CPRzkryk7NIk1kLxr7SEmmLAMMOwwHGg+HGSFamoSai 8C8/pFT2EMFdYwtjSeoRXgD64WKo57F69L51iQa/HAKzbXkovjt/0jgYl5p1DdQee+EJ ygAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785346132; x=1785950932; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=jj+QoV7lrgaUkyKWFX2Af9gY1Kh3s6qOrf7ExndUYWk=; b=GR3bXDSZe9vUxFHXW3TjqgUvCM5oBNAWKtcEiDIySDODPswbD77y9HYBGk1pwElB3B wS/qp5S6ahxpJoK5bwgjfcOESmSKqmRhjlnfcnq5qGBrs0BEfFZhMVpu5NodoCuNzugl wmEKGiG+DsmuHn6WGj0ZK7zPmU0dycZs9b3E4dx9nkl/IWRTz/Lyv3FWOpXoyeFLBc3b Ph1RtRCkYl365CHh6V9gsK2NTQyxSAEO+dILHDWT+f2ieWYwlopxRjrSbSYBMwaWhEBn YFhFeVvN1uCH1Hm9ElhD8jRNE1NjvVarJADjJM+aNnHVH2psNXJeSU9HWlIEQhqQnS1p yaug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785346132; x=1785950932; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to:content-type; bh=jj+QoV7lrgaUkyKWFX2Af9gY1Kh3s6qOrf7ExndUYWk=; b=IKDtEE0sER7iZLbyqTdmthoostzhMSACuWErbQtScHiL+BbfimX8nudztxAQ09xwll l0n24S1V30WCRpvGtB+JLFlo5Sv9bZMa32zBGhagt/oKBaIsqznNnDakgQfWXvRjAOnV 7ebocPpFC6o3sVZ5GgJSH39YrfQCkOfjDw7mTQzPI6vfzCd6CRS3CTV5qfnVoGCfzdX5 ly7gHRFdfa+YFiC0g9fjMv+f9nH5ZXvQ9uFEueqpgktyJlTAsA2qy3d7CXpGQYyuYq3Z Ut0RuPGttreQzXLsfSlRi14pyWpaP5Ijzi25G9jXJ38PDITgknBDpmSJe4Qj9P859T1w 85Iw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AHgh+RpkMbhseziTCfiZr+DUOqpbsivVwJpPlRZFNqZd+bvHCDYgTN9E6cA/zZD+TWo5Hr9u4LsKDdT5qrlw@gnusha.org X-Gm-Message-State: AOJu0YxwsrgtGsE/1RYFebSOb+dqolN3Ea91Ho4pE8tavbTXEOtrmbsk yEw6nXXFhP4BWTjltGBJL6WzHoPemte5vdUqu3qKQChSV01qfHip3olG X-Received: by 2002:a05:6870:e247:b0:451:cba2:10ad with SMTP id 586e51a60fabf-458962765e3mr1758140fac.20.1785346132100; Wed, 29 Jul 2026 10:28:52 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Aa7YSPRphnksQ68iac4NUJJ7K+BcP+GEBHJqBg9aHZnadt3x4Q==" Received: by 2002:a05:6871:acc8:b0:440:fd1e:ce26 with SMTP id 586e51a60fabf-458b9535ac2ls3675fac.2.-pod-prod-04-us; Wed, 29 Jul 2026 10:28:47 -0700 (PDT) X-Received: by 2002:a05:6808:c40d:b0:490:b586:1459 with SMTP id 5614622812f47-4ad5b949cfcmr4194319b6e.2.1785346127037; Wed, 29 Jul 2026 10:28:47 -0700 (PDT) Received: by 2002:a05:690c:2b01:b0:81e:e2ea:ecde with SMTP id 00721157ae682-81fb103a256ms7b3; Wed, 29 Jul 2026 10:21:52 -0700 (PDT) X-Received: by 2002:a05:690c:6288:b0:81e:837f:d93b with SMTP id 00721157ae682-81f992be5a5mr39373147b3.53.1785345711509; Wed, 29 Jul 2026 10:21:51 -0700 (PDT) Date: Wed, 29 Jul 2026 10:21:51 -0700 (PDT) From: Ram To: Bitcoin Development Mailing List Message-Id: Subject: [bitcoindev] [BIP Proposal] Stale Tip Relay MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_284938_1349708105.1785345711042" X-Original-Sender: pseudoramdom8@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_284938_1349708105.1785345711042 Content-Type: multipart/alternative; boundary="----=_Part_284939_104976056.1785345711042" ------=_Part_284939_104976056.1785345711042 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello list, This proposal introduces `staletip`, an opt-in P2P message for relaying=20 recent stale tips between peers. Building on AJ Towns' initial work, w0xlt and I= =20 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.m= d Proof-of-concept: https://github.com/w0xlt/bitcoin/tree/staletip-v4 Today, once a block loses a race and goes stale, it stops propagating =E2= =80=93=20 compact block relay and FIBRE aggressively relay the winning chain, while stale=20 branches fall away. That's great for fast propagation, but it makes the=20 stale rate difficult to observe. Even dedicated monitors [0] have only partial=20 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=20 related to block propagation delay. The longer it takes miners to learn about a=20 newly found block, the greater the chance that another valid block will be found= =20 at the same height, creating a race in which one of the blocks becomes stale= =20 [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 =E2=80=93 when a partition heals, blocks mined on t= he losing side become stale, potentially producing several related stale blocks at once. - adversarial mining strategies such as selfish mining [3] =E2=80=93 thes= e 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=20 peers. An added benefit is potentially faster reorg handling: if a node already=20 knows the relevant headers, and perhaps has the block data, it has less work to= =20 do if that branch later becomes active. At protocol level, nodes advertise support using BIP 434 `feature` message= =20 [4],=20 and `staletip` messages are only sent to peers that advertised support. Eac= h announcement contains the fork point, a sequence of compressed headers, and= =20 a flag indicating whether the sender can serve the stale tip block.=20 The proposed default relay policy: - relays only tips within 1000 blocks (about seven days) of the active=20 tip,=20 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=20 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 ) &=20 w0xlt [0] https://github.com/bitcoin-data/stale-blocks [1]=20 https://delvingbitcoin.org/t/propagation-delay-and-mining-centralization-mo= deling-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 --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= d92f1615-368b-4406-b326-a1799c72a555n%40googlegroups.com. ------=_Part_284939_104976056.1785345711042 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello list,

This proposal introduces `staletip`, an opt-in P2P m= essage for relaying recent
stale tips between peers. Building on AJ To= wns' 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/staleti= p-v4

Today, once a block loses a race and goes stale, it stops p= ropagating =E2=80=93 compact
block relay and FIBRE aggressively relay = the winning chain, while stale
branches fall away. That's great for f= ast propagation, but it makes the stale
rate difficult to observe. Eve= n dedicated monitors [0] have only partial views:
a stale block seen b= y one monitor may never reach another.

The stale rate is a usefu= l network-health signal because it is closely related
to block propaga= tion delay. The longer it takes miners to learn about a newly
found bl= ock, 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 bottl= enecks.
For example, the May 2023 "inv-to-send" bug degraded block pro= pagation and
coincided with a roughly 10x increase in the observed sta= le 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 rea= son to investigate:

=C2=A0 - a network partition =E2=80=93 when = a partition heals, blocks mined on the
=C2=A0 =C2=A0 losing side becom= e stale, potentially producing several related stale
=C2=A0 =C2=A0 blo= cks at once.
=C2=A0 - adversarial mining strategies such as selfish mi= ning [3] =E2=80=93 these
=C2=A0 =C2=A0 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 proactivel= y announce recent stale tips to peers.

An added benefit is poten= tially faster reorg handling: if a node already knows
the relevant hea= ders, and perhaps has the block data, it has less work to do if
that b= ranch later becomes active.

At protocol level, nodes advertise s= upport using BIP 434 `feature` message [4],
and `staletip` messages a= re only sent to peers that advertised support. Each
announcement conta= ins the fork point, a sequence of compressed headers, and a
flag indic= ating whether the sender can serve the stale tip block.

The pro= posed default relay policy:
=C2=A0 - relays only tips within 1000 bloc= ks (about seven days) of the active tip,
=C2=A0 =C2=A0 keeping announ= cements recent and stale-tip spam costly on mainnet.
=C2=A0 - limits b= ranches to 20 compressed headers, covering short-term reorgs
=C2=A0 = =C2=A0 without tracking persistent chain splits and keeps each announcement= under
=C2=A0 =C2=A0 1 kB.
=C2=A0 - keeps at most 10 recent tips = in the relay cache, so announcing the full
=C2=A0 =C2=A0 cache to a ne= w 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)
&=C2=A0
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/observati= ons/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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/d92f1615-368b-4406-b326-a1799c72a555n%40googlegroups.com.
------=_Part_284939_104976056.1785345711042-- ------=_Part_284938_1349708105.1785345711042--