From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 11 Aug 2026 07:04:48 -0700 Received: from mail-oo1-f57.google.com ([209.85.161.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 1wtn5z-0007gD-LA for bitcoindev@gnusha.org; Tue, 11 Aug 2026 07:04:48 -0700 Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-6ab0ed783aesf976012eaf.1 for ; Tue, 11 Aug 2026 07:04:47 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1786457081; cv=pass; d=google.com; s=arc-20260327; b=A81yxVojyVeBo03LuwX1I3JFO6LWCu6WOD6y/XiQ8PlTPvx97amR4HZH7cOF6Ecs0o c99IK6tvAJ5xtfyfEWi7MApmheR+EnZgjYqfrPyNDrRL43vbkfSe2MfYe5bgdjAH3HqI UIscpKfyc1jeMpsecEW/vyKwRIUBGhOEjCoLvwhlHk/sWI3LtFQQvyr40KZt5lU4y09D tIVgzGjXBCYueARyFK0eRfcjpIwuK8r1WWOUAjL14z3fhCh/XK42/U/ABdedAYUBMxxf 2X6PUAONL+Fumyijpp6rsHKujYzmLJMhIeAcwatQx5wI2XqsKMl1fwlsW0qi3DRUF89y b/kw== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=ZIVuSQS1WllNMlHVPkSUOHfeHyK/FTt/mWezZM9z3Vo=; fh=8erCZ1Oj1lhrfBJhFvCqJt/svr0tIrDXLveRb8QB+bI=; b=R/sMQ7Pv6ylFb1Of9CuI0VE72CynC7h+l/iFc6i0YvKFCODhkeYmrMLWFy3fvQXwX6 pG7Tme9WzBf82eoiAKINtonqPFl4ZOcc9AS3YxSqafQ5KOoifTm65UQVTQMt2lRlus2s jxnefg2IwgN7y8XNck+hdm4fVk8r8ZePUVht7/qHxFiwoo3uNeBII6Wl7rjrx1XsRt+F uq9QtEvSHypiAZmfFvJrNo4xzRj1dAbtxEFg6LT36ytZBKMqVcryt+Sj7cLTI/HGaAA3 Vz4ZcOWnmd4VpuILSZR8QNEgsVAlmmcvy3SCQODR0Jt0VsSZbmOTr8WcGvoQFm5NLIBg BD6w==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=eETnoZTh; arc=pass (i=1); spf=pass (google.com: domain of jose.edil@gmail.com designates 2a00:1450:4864:20::130 as permitted sender) smtp.mailfrom=jose.edil@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1786457081; x=1787061881; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-type:cc:subject:message-id:date:from :in-reply-to:references:mime-version:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ZIVuSQS1WllNMlHVPkSUOHfeHyK/FTt/mWezZM9z3Vo=; b=LtbHtEIY4po2lNcP5HnVYzJqKcqGYin33I2gP0COayikTJmeKdI7zZITwX50RNNuph Aos+B6fiqhfNWtaOjZB9R5SgPIPSrQKSMPytS5VV3sxqs3GrC50x8uaQKDfaD1FUmh0T dYwMS4xSou/fluiSlW0XEAUusfLV+X86Rfxn0npaStGCGy/kb8sy0FMDXa9YFgZSrTQQ vLIGZbjvF6A6VwUfCLMprjC6s86fRolLB2bQU769l6+7B8vRQgQOFR8sri7rYTkHD4M4 kEgSETn63uP3XQMEyy6MnPj9nDbcaFHxoUsR3tZwQNf66FW47GfDwjoC4NaR0GfKxNTU Wgcg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786457081; x=1787061881; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-type:cc:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ZIVuSQS1WllNMlHVPkSUOHfeHyK/FTt/mWezZM9z3Vo=; b=cV6JggUuo/5omJdMOENnr4FdFledM1PDwYBhP/feBkamuL/ajO/g1V5SMpdwWzhy9c xoCzpgRsN99OnKhhmYuxLPoFQq3hFsyIJxG0VSerTb1kjhzGkSujYbT3JtoDO+2JZoo4 cEtnStWsfI+eCVYinqOkoT0Sbc6ZCjfWUim6uLXXkBnJdsxOIspotC/ewQYVbfwKUGiL ZEV66ZhTXgTP3FkRdkmC5s2T1p1N94EANbpskw/HljEe+Kpx4Re4adxV1oaICYgFGojZ Xi60YPEWb5DhcIXeGyX2b80Qdu8R6DmVWI3J7I+rawnJM/k/A6fSNCNF4O1b5kpWkVQm 48Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786457081; x=1787061881; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-type:cc:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to:content-type; bh=ZIVuSQS1WllNMlHVPkSUOHfeHyK/FTt/mWezZM9z3Vo=; b=RgRxvibt8d6JKn+M3LMsSDW+xGmHDUQZy8Ku4uatSRVyGVF8rcfuBbFpc/H+oJJKE3 uU/vf0p9VSwGIRenVceUz3CgSnDKkyTIUxHuLe1KtlE3m9lGGjJ8mRKN5WQhmfxAZRsy fUZRPWu511hmWDNcEBG0h8rqIndYZ8mGsNn/IRyDKQovMa3IDmZwL34a6HokZPTQsV3+ N2Awm4vO8TJVsjNpQrglPOSln534crYUPUdK8BssGrlicqdmIrnWtNjkXmQNasv66XLZ CbCW3m/LagTOq87D6apyB+tyr5OLUk171juoAU3m3PKJ6Pui/7cSa0B+lc39mQN5GLzQ dWGQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AHgh+RpTVjy+mrREwm+K7ZAMCDIlNRfgKOF2TZGrkUqSPsR5Gxai6XowpqSrZvFoK6HdBaWVSi90w0RrOfPv@gnusha.org X-Gm-Message-State: AOJu0Yz5P0hetwpqkmsgKkwxNbxsL6xb3zdu5+q9rQZGlX3Z8ot6IUvS O4B/3VjSLfKVnX8hiH0XOOxqJHEiOrrDAJA/ozytTVNxxrlPnBNh42ny X-Received: by 2002:a05:6820:308a:b0:6a3:6f5d:4d6c with SMTP id 006d021491bc7-6b0abd8ac0amr247584eaf.6.1786457081084; Tue, 11 Aug 2026 07:04:41 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Aa7YSPRhR3uzuBY694e54joWL1ej+ufkARSeaeuYR5iXYq2BYQ==" Received: by 2002:a05:6870:7129:b0:456:ca23:e921 with SMTP id 586e51a60fabf-4599e14de91ls2573294fac.2.-pod-prod-00-us-canary; Tue, 11 Aug 2026 07:04:34 -0700 (PDT) X-Received: by 2002:a05:6808:250f:b0:497:da7f:1798 with SMTP id 5614622812f47-4b20979b5dfmr45162b6e.12.1786457074686; Tue, 11 Aug 2026 07:04:34 -0700 (PDT) Received: by 2002:ab3:6a42:0:b0:30f:146a:f654 with SMTP id a1c4a302cd1d6-30f146b1568msc7a; Tue, 11 Aug 2026 06:51:31 -0700 (PDT) X-Received: by 2002:a05:6512:1390:b0:5b1:5bb6:d620 with SMTP id 2adb3069b0e04-5b448676956mr562344e87.55.1786456289581; Tue, 11 Aug 2026 06:51:29 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1786456289; cv=pass; d=google.com; s=arc-20260327; b=i5GvDT/a3JQNewXiAUgJQUOnKjO9X/cN0cioMRxmyrvbPR0qHMCrAuR5cn1PfzsE3m Jy5vRpqz0/obXtBDD1baR5Vbe+LRJza/tvrvqJAbcgxadTRkO/31Qzyjv9QeOaWPJJkj NP7z8uT/1ilr0I4jDzIkgrLbaU4QDcANdST7Bm0RNNnNMepGnw4gwsV2APVWTi5x1fjp Nw+sMVmwesLKaeyDkMxUAt8dONIOE3Rpppfw1K1lALKjSteQ/B/NkeaUPw/33VwkmZyj GEfcYYgjXkJrVD98k4dRCOw3APzkUF8wAIW6bFFEuujCZ9m+HDwJyeibNdw0jIhjFNzO dKFA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=ek+q+i1frrGRIw9psEaQ+/dEAhl/vJ9FssiGCalmEH4=; fh=KToalNYOLOY5OcEN8k1qap7GE/GrsMpo+YpfFP5+Yok=; b=oBP4nNYoWY/MeoDmLZH/p4r+gWnDJwdGgx2BZp439daqRBO50eCy1/pZNEScYke2To EzpGwSm/r458z13grHrMU9k5rAArYR/C8/sShwKHoaTP0Yh5NctcU5plsLlzu/dpk9Ie WgtiA6uzNi4LBTEFjvdSgC44LLqONXO1ZiKrI+N6T8TPFuoeToLnw8pllQiLNWQd0mut cQ3U2BtrebeQWjrwjLx2PGg8CIGUJvpDd3B3VONuk8LI3x9CYqP/aA7e9shMT6HMGv68 m5pEsstd29a3N7MFREYq6ljsonBjhVmw0v3bPRCK+bIlPsSkr8M5k+HSzdLRykm2YA0z Q9gQ==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=eETnoZTh; arc=pass (i=1); spf=pass (google.com: domain of jose.edil@gmail.com designates 2a00:1450:4864:20::130 as permitted sender) smtp.mailfrom=jose.edil@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com. [2a00:1450:4864:20::130]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-5b448714bfcsi31465e87.5.2026.08.11.06.51.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Aug 2026 06:51:29 -0700 (PDT) Received-SPF: pass (google.com: domain of jose.edil@gmail.com designates 2a00:1450:4864:20::130 as permitted sender) client-ip=2a00:1450:4864:20::130; Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-5b2aa3be376so2140539e87.0 for ; Tue, 11 Aug 2026 06:51:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1786456289; cv=none; d=google.com; s=arc-20260327; b=kZUkK+r29756oct2EeC4a3VRuqSdlKcTP4c51XToO3cGLZ9Q+WoqL3OStdF5Lrhq5Q TgjShCed+h3ExKrOQEs8IALsu3ZyH8LdzKWChErEnw8eElW1pfQvXbPYbD0WqBoZz5se 8pIdYK3+b7WDaiXHSWaMpMClh9HRw6NQF01Scgf75qH6xSZ2ldg7WuXzqG3VtAiPLUu4 kxbI+blysBdVuTce2RMkWPoQhKHlq+qtcgq4fe1RaZTlrRmww2UVX0gBEFO26e7zw/hY YRsOaVrR24Ui+8R08wKpVkgiewzP1XxIfOCAgAgfAp1tJr/B8lF87BRCEzRv484ifoDA Ay4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=ek+q+i1frrGRIw9psEaQ+/dEAhl/vJ9FssiGCalmEH4=; fh=KToalNYOLOY5OcEN8k1qap7GE/GrsMpo+YpfFP5+Yok=; b=NFdGPVxMfoVEN+AFFMHLtaiSudA7gSLLvTww5yzLsLciK9VvrCiQCRvcxGgEbJJP86 ICJ0PJnv5V73RxaQ+sNlRSywOiVT0YZinNNLo3ahAcVcn9tX7zyD4QInW1ZAyw00oMzL nH6sRB1B2lXCGiWcyQZhVxCZLvZrj5rsufKNp8clSklS5PFXqNLGXSa/VT5PABgZo9lE k0r18s+KivELQrFHLdHuoUtnB8qnfzeJpjrsMxGQM4yiAl8unCPf19mbDG7jr2yFLYq6 mMSLGV7phaTrbr937OhqKJX9t0ZaoAi+Kqxat5wZiaaQuxSsbtWmr4DppiBSngght3vN ljjQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AR+sD13xaovFIX5t8FdVGKuNymlihZ+LA/CkxcGj5alM7sc//iDmYznF2r1eMMhgLjM f5MoGuQCRQ5F/PMfWWjX6myUrBNPs/sPasy320BWgPa834RUxqXZLYACRxXz//CaKfc9XqLtMR1 uGQXYu0Kr8vzGSudTmprlVZK15b4QkSpW7Ru3KqIjyOxeJWIzU3OkHvLOuASVyGM7Wwx1rzl6P+ lsMm+owfdaqHCLQxZPGfZWGCFX/+tQKGNayxmBCbV6YeBKqDmOAjhokl09mbiOf2kdXMthclVBJ Wt2rOqk+C35Z6zcsAs95OF892z4WWPh/MQ2Aa2bWfHvwcXKEFIUekFeoJFl6Z6DpL7TKhmjoeNE OX8+fmVsXOMo2 X-Received: by 2002:a05:6512:3b9c:b0:5ae:b8fe:88bf with SMTP id 2adb3069b0e04-5b448611d68mr547842e87.20.1786456288638; Tue, 11 Aug 2026 06:51:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Edil_Guimar=C3=A3es_de_Medeiros?= Date: Tue, 11 Aug 2026 10:51:16 -0300 X-Gm-Features: AUfX_mx0BqZ0_pJNXzK5t1vL0o3xfokBlkPCqmEZEY3xrX5iWmKQdaosXMgEcVw Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Stale Tip Relay Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000007dbb2a0658c5c471" X-Original-Sender: jose.edil@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=eETnoZTh; arc=pass (i=1); spf=pass (google.com: domain of jose.edil@gmail.com designates 2a00:1450:4864:20::130 as permitted sender) smtp.mailfrom=jose.edil@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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.4 (/) --0000000000007dbb2a0658c5c471 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =C3=A0s 14:28, Ram 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 implementatio= n. > > 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 =E2= =80=93 > 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 foun= d > 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 an= d > 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= the > losing side become stale, potentially producing several related stale > blocks at once. > - adversarial mining strategies such as selfish mining [3] =E2=80=93 th= ese > can cause honest miners' blocks to become stale. > > The proposal fills this observability gap with an opt-in P2P message call= ed > `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` messag= e > [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 fu= ll > 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 ar= e > 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-a179= 9c72a555n%40googlegroups.com > > . > --=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/= CANJiN3%2BKetUeNjjeRgd7xgCSF%2BvAakDtH7ysPC%2Bh4DqtHJPsLA%40mail.gmail.com. --0000000000007dbb2a0658c5c471 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There's an ongoing effort to document mainnet sta= le blocks:=C2=A0ht= tps://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 s= o sure about how that improves the main purpose of the network. Quite the c= ontrary, seems
to open more DoS and fingerprinting vectors.
=

About the design, it's not clear to me how that cou= ld work in face of more than one competing chain. For
instance, s= uppose 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's not clear to me how the proposal deals wit= h communicating this, which is quite common in signet and=C2=A0
t= he testnets, since each message is designed to relay a single competing bra= nch (e.g. B3-B4 above).

Left more detailed and edi= torial comments in the bip repository PR.

Cheers.<= /div>
Edil

Em qua., 29 de jul. de 2026 =C3=A0s 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 To= wns' initial work, w0xlt and I have
developed the proposal further a= nd built a proof-of-concept implementation.

Draft BIP:
https://github.com/pseudoramdom/bips/blob/staletip-bi= p-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

--
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/d92f1615-368b-4406-b326-a1799c72a555n%40googlegrou= ps.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.co= m/d/msgid/bitcoindev/CANJiN3%2BKetUeNjjeRgd7xgCSF%2BvAakDtH7ysPC%2Bh4DqtHJP= sLA%40mail.gmail.com.
--0000000000007dbb2a0658c5c471--