From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 13 Aug 2026 11:58:07 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wuacw-0006uB-5u for bitcoindev@gnusha.org; Thu, 13 Aug 2026 11:58:07 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-448bb8bd2efsf333894fac.0 for ; Thu, 13 Aug 2026 11:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1786647480; x=1787252280; 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:references:in-reply-to:message-id:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to:content-type; bh=+iO3Da3mhHZa02cIbAspDso1fPzQegfXs6M1lIvPv8A=; b=Ie8TDQc/z8qFU3pkOWWMxOaJkAIyjFPag5VRPTqPnUx8FeS9y1YL/UlwCiZNiI0H2p YCmZIgGqCq4i6EO88vTw+HJrOI8aWtV6TTyi1C/ba5mzA2drKAbbxL0TgVwY9kSr5ClC pgb5SpiIughTNGo91zNXAxxIcnG+uZadeY6SeE9oZaFowLoCS0mHQ+lOn73/s2eVdPY0 dAurcVrqoDTp6AZ7lhO4LudRG9Y+ChHFh8lmpi2QgxHMYHKU1k48O9Jxc/706k5LHQ4O C30DUvpnkQjHaAdvBPdRGZESvF8Zu5TGC9jX0ZdcEagbxZZXCuakvvBQXJQcJVa2lBrR WV/w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786647480; x=1787252280; 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:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to:content-type; bh=+iO3Da3mhHZa02cIbAspDso1fPzQegfXs6M1lIvPv8A=; b=OS6sHGAxL2rrjSC2dK8AoNW0GyeGj4Vkn+AThupoBk8ItrT5HVtdF32IV2imeTx57a PYFC6Gs13IIfxJTABA+1VQ+vtSIxuDw9raWQKbtSfPBy2any+tnJfF+jKuN4BwOWuHQH bXwSimhsrXz98/xCXAFl4WyyVHuHCRjbB17hrE6MpJWcvsLD+ISJotBHkA8hqZg9vqxZ N+4Fre8G9v29f9gjsfaNRVlSyleJTRYK5vS89U5tWRlqKB/oBx8ZyJ04pMMN/QvxzTbp /1RuZ5mV8jvatbr484MdApRe15jPVoaOF/YCTVV7qWcqO1j+b0llEBD1obSXfA1iSG2r 3Q5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786647480; x=1787252280; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=+iO3Da3mhHZa02cIbAspDso1fPzQegfXs6M1lIvPv8A=; b=QtmLvzRVLdl7F9Mlyep8kI7/Te40hdU6zJxgA4u58qHeqrT0KAXDn+AY4NtRMebl9y JutiHBc/c42ArhhwFum1+5JI9a2mNCJ23MW9W1RYnYmlcagraLVcY6B7kuaNsRjrrZJl 0S/riY/HemyDI2d8xVljMKcbRv0kIZfje3GQIN0i6Fkcsd31rhG7XIPeraJCVlFDjsGT 6sIKADG7ZRUZQAsBjIR2jLvTKNDdBXuR6nqgUHcJ/66FViZSaacOJ0s/dW6OyaeyjiKc 06Y35eii4+zBm6JpHbdgig3LvLxNvA7RHZYIC1KvITuRfu4VLbtGeO2vkFwOsTWKH/Fi e/mg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AHgh+RoApnI2GtxZd0U3H8tzv9F+A2r+LqDYwEKdrUn1+xZJ+ZqVUx+BwJ4mUXgA+90E2PCW1g7EOpNd1B1F@gnusha.org X-Gm-Message-State: AOJu0YxU8FTf6m4z4CxiYPe76lvjWUFCgxSGN+qqA0beDdkzIyo8HO6w L8Zj5AffdeeW00d6Ch0kfyzElMMVLhrjzFyMiby0XlF9ukcv44LU/E/x X-Received: by 2002:a05:6820:178a:b0:6aa:f920:6b1a with SMTP id 006d021491bc7-6b0d61b5723mr608030eaf.16.1786647479744; Thu, 13 Aug 2026 11:57:59 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Aa7YSPRUaOgYGQnjQENixYtq3G9nBmIBfzBU0WG3gmFMifX6OA==" Received: by 2002:a05:6871:7403:b0:45e:435c:5ea with SMTP id 586e51a60fabf-45e5c043ed0ls932070fac.1.-pod-prod-06-us; Thu, 13 Aug 2026 11:57:53 -0700 (PDT) X-Received: by 2002:a05:6808:220f:b0:496:3a1:e44f with SMTP id 5614622812f47-4b2412f2c27mr180119b6e.6.1786647473049; Thu, 13 Aug 2026 11:57:53 -0700 (PDT) Received: by 2002:a05:690c:a642:b0:80b:2194:fea2 with SMTP id 00721157ae682-82320fd1896ms7b3; Thu, 13 Aug 2026 11:53:12 -0700 (PDT) X-Received: by 2002:a05:690c:6a82:b0:81f:3b6d:a0a4 with SMTP id 00721157ae682-83711ffe4a9mr1462017b3.25.1786647192157; Thu, 13 Aug 2026 11:53:12 -0700 (PDT) Date: Thu, 13 Aug 2026 11:53:11 -0700 (PDT) From: Ram To: Bitcoin Development Mailing List Message-Id: <7bbef0df-dbb5-48d1-9671-b0cec91fcbb0n@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] [BIP Proposal] Stale Tip Relay MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_412784_959997864.1786647191727" 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_412784_959997864.1786647191727 Content-Type: multipart/alternative; boundary="----=_Part_412785_784862514.1786647191727" ------=_Part_412785_784862514.1786647191727 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=20 network.=20 Quite the contrary, seems to open more DoS and fingerprinting vectors. For DoS, the concern is whether a small message can cause disproportionate= =20 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=20 possible to prevent all of them. Currently, I don=E2=80=99t see any resource-exhaustion or bandwidth amplifi= cation=20 vector introduced by this proposal. Processing is bounded by the branch-length, recency and retained-tip limits. Nodes are not required to download stale= =20 block data. Nodes that choose to collect it use the normal block-download=20 mechanisms and resource limits. Implementations may also apply stricter limits,=20 rate-limit abusive peers, or disable the feature. Also on mainnet, producing stale headers requires real proof of work=20 comparable to the active chain. =20 On fingerprinting - supporting staletip does add another observable=20 characteristic. This is a trade-off the node makes when enabling the feature and is common= =20 to=20 optional P2P features generally. Nodes for which this trade-off is=20 unacceptable can disable staletip relay. > About the design, it's not clear to me how that could work in face of mor= e than one competing chain. Each staletip message describes one linear branch. Assuming A1-A2-A3-A4 is= =20 the=20 active chain, the two competing branches would be announced separately: staletip(fork_point=3DA2, headers=3D[B3, B4]) staletip(fork_point=3DA3, headers=3D[C4]) The protocol announces competing branches in separate messages.=20 I=E2=80=99ve 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=E2=80=AFAM UTC-7 Edil Guimar=C3=A3es= de Medeiros=20 wrote: > There's an ongoing effort to document mainnet stale blocks:=20 > https://github.com/bitcoin-data/stale-blocks > As one can imagine, since there is currently no way to recover them from= =20 > the network itself, this > requires constantly monitoring several long running nodes in the hope to= =20 > 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=20 > 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 mor= e=20 > 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, whic= h=20 > is quite common in signet and=20 > the testnets, since each message is designed to relay a single competing= =20 > 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 =C3=A0s 14:28, Ram escr= eveu: > >> 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=20 >> implementation. >> >> Draft BIP: >> >> https://github.com/pseudoramdom/bips/blob/staletip-bip-draft/bip-staleti= p.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 = =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=20 >> found at >> the same height, creating a race in which one of the blocks becomes stal= e=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 a= nd >> 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 o= n the >> losing side become stale, potentially producing several related stal= e >> blocks at once. >> - adversarial mining strategies such as selfish mining [3] =E2=80=93 t= hese >> can cause honest miners' blocks to become stale. >> >> The proposal fills this observability gap with an opt-in P2P message=20 >> 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 t= o=20 >> do if >> that branch later becomes active. >> >> At protocol level, nodes advertise support using BIP 434 `feature`=20 >> message [4],=20 >> and `staletip` messages are only sent to peers that advertised support.= =20 >> Each >> announcement contains the fork point, a sequence of compressed headers,= =20 >> and 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= =20 >> full >> cache to a new peer remains under 10 kB, excluding any blocks=20 >> requested. >> >> The BIP text has more background and the full message format. Comments a= re >> 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= -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 >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/d92f1615-368b-4406-b326-a17= 99c72a555n%40googlegroups.com=20 >> >> . >> > > > --=20 > Edil > --=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/= 7bbef0df-dbb5-48d1-9671-b0cec91fcbb0n%40googlegroups.com. ------=_Part_412785_784862514.1786647191727 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Edil,

Appreciate taking the time to review th= e 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 a= nd fingerprinting vectors.

For DoS, the concern is whether a sma= ll message can cause disproportionate
processing, disk usage, or outg= oing traffic. Merely sending invalid data is
not a new DoS vector; pee= rs already have many ways to do that. It's not
possible to prevent al= l of them.

Currently, I don=E2=80=99t see any resource-exhaustio= n or bandwidth amplification vector
introduced by this proposal. Proce= ssing is bounded by the branch-length,
recency and retained-tip limits= . Nodes are not required to download stale block
data. Nodes that choo= se to collect it use the normal block-download mechanisms
and resource= limits. Implementations may also apply stricter limits, rate-limit
ab= usive peers, or disable the feature.
Also on mainnet, producing stale = headers requires real proof of work comparable
to the active chain.=C2=A0
On fingerprinting - supporting staletip does add another ob= servable characteristic.
This is a trade-off the node makes when enabl= ing the feature and is common to
optional P2P features generally. Nod= es for which this trade-off is unacceptable
can disable staletip relay= .

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

Each staletip m= essage describes one linear branch. Assuming A1-A2-A3-A4 is the
activ= e chain, the two competing branches would be announced separately:
staletip(fork_point=3DA2, headers=3D[B3, B4])
staletip(fork_point= =3DA3, headers=3D[C4])

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

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

Cheers,
Ram

On Tuesday, August 11, 2026 at 7:04:41=E2=80=AFAM= UTC-7 Edil Guimar=C3=A3es de Medeiros wrote:
There's an ong= oing effort to document mainnet stale blocks:=C2=A0https://github.com/bitcoin-data/st= ale-blocks
As one can imagine, since there is currently no wa= y to recover them from the network itself, this
requires constant= ly monitoring several long running nodes in the hope to get them. From a mo= nitoring
and research perspective, this proposal could be useful.=

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

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 /- C4
= A1 - A2 - A3 - A4
= =C2=A0 =C2=A0 =C2=A0 =C2=A0\- B3 - B4

It= 9;s not clear to me how the proposal deals with communicating this, which i= s quite common in signet and=C2=A0
the testnets, since each messa= ge is designed to relay a single competing branch (e.g. B3-B4 above).
=

Left more detailed and editorial comments in the bip re= pository PR.

Cheers.
Edil

Em qua., 29 de jul. de 2026 =C3=A0= s 14:28, Ram <pseudo...@gmail= .com> escreveu:
Hello list,<= br>
This proposal introduces `staletip`, an opt-in P2P message for relay= ing recent
stale tips between peers. Building on AJ Towns' initial w= ork, w0xlt and I have
developed the proposal further and built a proof-o= f-concept implementation.

Draft BIP:
https://github.com/pseudoramdom/bips/blob/stalet= ip-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 =E2=80=93 compact
block relay = and FIBRE aggressively relay the winning chain, while stale
branches fa= ll away. That's great for fast propagation, but it makes the stale
r= ate difficult to observe. Even dedicated monitors [0] have only partial vie= ws:
a stale block seen by one monitor may never reach another.

Th= e stale rate is a useful network-health signal because it is closely relate= d
to block propagation delay. The longer it takes miners to learn about = a newly
found block, the greater the chance that another valid block wil= l be found at
the same height, creating a race in which one of the block= s 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 increas= e in the observed stale rate [2].

A stale block does not by itself i= dentify its cause, but changes in the
rate or shape of stale branches ca= n provide a reason to investigate:

=C2=A0 - a network partition =E2= =80=93 when a partition heals, blocks mined on the
=C2=A0 =C2=A0 losing = side become stale, potentially producing several related stale
=C2=A0 = =C2=A0 blocks at once.
=C2=A0 - adversarial mining strategies such as se= lfish mining [3] =E2=80=93 these
=C2=A0 =C2=A0 can cause honest miners&#= 39; blocks to become stale.

The proposal fills this observability ga= p with an opt-in P2P message called
`staletip`, allowing nodes to proact= ively announce recent stale tips to peers.

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

At protocol level, nodes advertise support u= sing BIP 434 `feature` message [4],
and `staletip` messages are only se= nt 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 rela= y policy:
=C2=A0 - relays only tips within 1000 blocks (about seven days= ) of the active tip,
=C2=A0 =C2=A0 keeping announcements recent and sta= le-tip spam costly on mainnet.
=C2=A0 - limits branches to 20 compressed= headers, covering short-term reorgs
=C2=A0 =C2=A0 without tracking pers= istent 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 announcin= g the full
=C2=A0 =C2=A0 cache to a new peer remains under 10 kB, exclud= ing any blocks requested.

The BIP text has more background and the f= ull message format. Comments are
welcome.

Cheers,
Ram (pseudoramdom)
&=C2=A0
w0xlt

--
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 bitcoindev+...@googlegro= ups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/d92f1615-368b-4406-b326-a1799c72a55= 5n%40googlegroups.com.


--
Edil

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