From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 05 Nov 2026 15:20:54 -0800 Received: from mail-ot1-f56.google.com ([209.85.210.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1xP6lK-000AMf-9e for bitcoindev@gnusha.org; Thu, 05 Nov 2026 15:20:54 -0800 Received: by mail-ot1-f56.google.com with SMTP id 46e09a7af769-84cac522117sf16478a34.3 for ; Thu, 05 Nov 2026 15:20:53 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1793920848; cv=pass; d=google.com; s=arc-20260327; b=ZREK8T4zBMU5J5Uc1/qhN3+q16pqI6CYRep/QYKEM2rWR6nj760O6YP2ow0qR5Pv70 pzKKMbmDrVykZEoBMkIGt2AF1VWejpmLSdnTnukmzNs3u0EgT7syl/5yIod3Vn9CA5wT eJKXvMBKFcHtUy7EoHqyoSisqTBIaqLSO53i51zLdRmL6/WhtRgVpAJpMmZLaTxXKj+B 7T76H/Gb0sIkrAkL1pPoVQUYBblQSg8ezVkMMS0n9LmBbyafaNWZr0St7faOgsBdzuwK po+OMwqcaimQ/Eik3Om1gRYGdyTWADa9QzcGyHcDQUd+tJBoZftGE16OEn/al/NIfCBh ZzdA== ARC-Message-Signature: i=2; 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:reply-to:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=CR+Eo0e+gss9XefX0MY8nGaTKh0mYdXsFAl/X7DSPCI=; fh=iD8rE6LlcM4X16WRoLsght/euQ/nxCq6SohCewKbSrs=; b=rwDDhCp0BvKNi9yi+KGrmB1S++3ExLWV6xObwSzlZk/UF7wJiHiVv2TOMJUQJHZRxX IC7eAcyjQz0Fd4t8tfvnFeKJFs1GUXbIFMlf1IL/jLTKfeCJmV3AzgQZqPCoXwN8zNOd Dl7mbB9ELdg9YHUQbzU3LTPYIj8SXwElDz3M9lwAeUh6t/hJwnhXI7y9bVSnUFscXNMj RgCWzGAUn8642wOAyieIbl7Pr2t7XLEJqxmJX+FnecBKJ6jn/p9L+Z6dqz5es9oTwhki aK1ZTUGD9RmX3wTQCwdq+4hR0lgtLtOZlYMhT3V6h827eiTsQZqDXPs41RErglLC+IGh fuOg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=qUGI2vN8; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20260707; t=1793920848; x=1794525648; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:content-type:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date:from:to :cc:subject:date:message-id:reply-to:content-type; bh=CR+Eo0e+gss9XefX0MY8nGaTKh0mYdXsFAl/X7DSPCI=; b=N+xnLvMOsdjUQTJyQ/tkNA0MbW/GSkVE/W9uRaiChrpktYQKF7JIeqoBIX/tCebmlz q5eFnIQ4Egz7jwiuQIf4//FkX9j51FAN8RWJWEgqub8n9np+JydW3mSep9BqFsKkxKO1 kdddw0MCxOReaxpNtjnKVqeZ3HQx1/LKBjsiNkx+UD5LOQCnfnDVVj9vJM4j7zLrJ2Kp /yP5rCfqIlDdsAibveSCwrlfei7mDrEA2WN9FZsHTOx+RTIsUNVs0ex+bYMgx22qL9Y+ 0fzIHAmxeT+tL0h3K4ioO6Zqevl4PxPSY1I/mCh5tr5IZOBjLY+pd1AuPQofeGO0xDHh vbxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793920848; x=1794525648; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:content-type:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=CR+Eo0e+gss9XefX0MY8nGaTKh0mYdXsFAl/X7DSPCI=; b=CsjnduE68IxEZDqUMx9evrvz1yiXRpf9LwordYKC24+aBKbkj7OpyAzTdaZkPDFEOO Fn9Ujl1tUm9IHlNrtyROaPCn3fXQr0gKXLbf2psdK/Q1QTISP/Af/59G8SuOGx0v9Tsu JlRng6/qiIS6ZCscoHW2MCEgQJQaFyWuQ7On2ZjvQDNLKabSrP5WUKtNWTd4Vkw6DBR9 pGH+q3nt/cRSkCCmnR3Io+3avh9Qgxz7V/vdybtqpLKKK4Yh+/wVoXHljVEKtHVxoVTM HkXk/blNAvh76QU9QYuuJpzP/T2nsu+o89EGfj3VPEcbYoS0ioK3Guxw2WldN42dM8EO l75g== X-Forwarded-Encrypted: i=2; AKwUvBxHBW+yf/k/g0pSfWLTNfR6/MfD8UGJANSQTZVQhqQpSNFbd9+xIM99tIsLkG8yEKbuMlipr21Vr7HV@gnusha.org X-Gm-Message-State: APuU4Z91QQXtEZu8psah4agZw5Js8dF3VEqTxpcPtPCq0mEF0GUkkQck oxmVwE4h0CaYO+aVQmCmPvfo215fUxqxy/n9aF2dreliY1buBb3n6D3M X-Received: by 2002:a05:6808:10c6:b0:540:5827:6d87 with SMTP id 5614622812f47-567e09fe2bfmr870615b6e.1.1793920847775; Thu, 05 Nov 2026 15:20:47 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdf1nPdVBnHpUcqEQ2Fz3PV0BrXMmAkZb1zGCJWxLhJ8fQ==" Received: by 2002:a05:6871:9d11:b0:49b:a249:21f2 with SMTP id 586e51a60fabf-4ad971181f0ls144710fac.2.-pod-prod-00-us; Thu, 05 Nov 2026 15:20:40 -0800 (PST) X-Received: by 2002:a05:6808:1798:b0:521:561a:8e8c with SMTP id 5614622812f47-567be64fc98mr2435830b6e.33.1793920839881; Thu, 05 Nov 2026 15:20:39 -0800 (PST) Received: by 2002:a05:6402:a504:10b0:6b5:6249:de62 with SMTP id 4fb4d7f45d1cf-6b5977f00fcmsa12; Thu, 5 Nov 2026 15:20:05 -0800 (PST) X-Received: by 2002:a05:6402:2111:b0:6b4:95cf:24f with SMTP id 4fb4d7f45d1cf-6b5977ed8f8mr482289a12.19.1793920802982; Thu, 05 Nov 2026 15:20:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1793920802; cv=none; d=google.com; s=arc-20260327; b=WZ14+Wpa1H8vnw1OCZZZu19DO0WUOWMQ9MN20JQ14hWDtemAVA6/CJeyFbPX6d6J9A GQgRCxrpp9LgIBapRjTNoNlkrZwRHmEox5p0GLT0rDz94m89aslTD/xGR3mr4lo5MaJU R3OZou6n4165g9x8QS8iyrz9Yqbh9LSN13+l9lB0z9BtnWWT2tOZJi13B+jz52wynIBC jjgSxqXFnytJS25aLcnHqCEJIuYy/TTIADrHOKGNU+P7ktfv/rY2/kbxyL3NmvJhb0na Zems4i2MFmj4Fl2tqMziHZqZwwPKPP4lTCLX1ZnFbXGExLvTLq2thmNaqsWJ8WMG89Nz Mxyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=bhmasKozU3qjLERTMT0rubnGXwDY8Z4WhuduhvmED4k=; fh=zuRtqlq3YtFK2+o8ynvXuRRoIkZ7v6tcS/XiGdqLfjY=; b=HW82E5wraF0IRAKL9AFBsdP2fvqJlc56wlrY2H+mB4Ezny2D0UKBc38GNN4CTiL7XG xwHsHcaIj+kp+V1Feywv3BjC4610TlPw2i33LEwOSl7n9KS6IT0vMWVHCaA3ox8H1omK /QGyRefidPdhGP59GQi92WFJGfzmPXTXtp9cNhUWWxlDLbRnKR3+U4YcpGxyVAQpTHbv 7U0B3kJ0RhtE24q6bU0DchV3Rv/ySBtpdm585gPId3/eBVYY3Ixg8LQrEX94D0cy89S3 9IR1SRUAREiqeBM2ylfMg99hZaZLyxxSW8e0vnY2j45M8KcEDfVgmxl0bjLIpuYggrrX mDqA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=qUGI2vN8; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-106118.protonmail.ch (mail-106118.protonmail.ch. [79.135.106.118]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-6b664b135a2si110a12.10.2026.11.05.15.20.02 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Nov 2026 15:20:02 -0800 (PST) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 as permitted sender) client-ip=79.135.106.118; Date: Thu, 05 Nov 2026 23:19:58 +0000 To: Ram From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] [BIP Proposal] Stale Tip Relay Message-ID: <3rRzUIQUWDcT-ASQXvovARX12jzE0UWy0RQ8fk7M_z3bW_k2LWPPEvRhoD6sEe3GW3fjCdtzLOZN34TCsB2CI6iRcdjer9Y8QiNwUh2QepI=@protonmail.com> In-Reply-To: References: Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 8ad70501e0e371799f4285cb98f47c4215ad987a MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=qUGI2vN8; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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: -1.0 (-) Hi, This is useful, good to see progress on this. I'd like to suggest an incremental approach, and to start relaying only sta= le headers at first. This gives you most of the benefits, without having to make an argument tha= t the protocol change does not negatively affect mining incentives. As you note yourself: > 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. This increases the expected revenue of (temporarily) mining on top of your = block in the event you lose a race. On the other hand, this accelerates convergence slightly as honest miners o= n the losing side switch to the winning chain faster. So clearly such a change affects the incentive structure, and would require analyzing whether it's a greater force for convergence or divergence, or at= all meaningful. 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 t= his, and pre-relaying them does not affect the incentive structure in the same w= ay. Therefore i suggest to specify and implement relay of stale headers, then l= ater revisit whether the additional information present in the block content (po= ol attribution from the coinbase, and validity, i suppose?) is worth the work = on analyzing the effect on the incentive structure. Best, Antoine On Wednesday, July 29th, 2026 at 1:28 PM, Ram wro= te: > Hello list, > > This proposal introduces `staletip`, an opt-in P2P message for relaying r= ecent > 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 s= tale > 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 re= lated > to block propagation delay. The longer it takes miners to learn about a n= ewly > 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 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 call= ed > `staletip`, allowing nodes to proactively announce recent stale tips to p= eers. > > 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. E= ach > announcement contains the fork point, a sequence of compressed headers, a= nd 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 ti= p, > 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 unde= r > 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 ar= e > welcome. > > Cheers, > Ram (pseudoramdom)& > w0xlt > [0] https://github.com/bitcoin-data/stale-blocks > [1] https://delvingbitcoin.org/t/propagation-delay-and-mining-centralizat= ion-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/bitcoinde= v/d92f1615-368b-4406-b326-a1799c72a555n%40googlegroups.com. --=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/= 3rRzUIQUWDcT-ASQXvovARX12jzE0UWy0RQ8fk7M_z3bW_k2LWPPEvRhoD6sEe3GW3fjCdtzLOZ= N34TCsB2CI6iRcdjer9Y8QiNwUh2QepI%3D%40protonmail.com.