From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 11 Nov 2026 14:18:31 -0800 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1xRGeE-000Nb8-Si for bitcoindev@gnusha.org; Wed, 11 Nov 2026 14:18:31 -0800 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-45ecb9dd589sf2596101fac.0 for ; Wed, 11 Nov 2026 14:18:30 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1794435504; cv=pass; d=google.com; s=arc-20260327; b=QEtzvKH6f3ecINbXwAY8oGD9ugrDphf+5HtHhGGwA11HgYOtBp8nLOvWlGLxu6LBFA /+y0hWoTrEUP7D1eQDeUQurfNaSt9Y8jP83TGQ0e9kfWZ+fDK0rCeyvZfbpl967+FJxt 3bwMq1Ws4P+05Ul6LQUhwDr7IYtMW9tRHncRCAUmnBPFX10m3/QZdmpfq9NgZ/1HTlPp ZIwD7+CWOAGYXMJXXN2WjYQx06L83FYWxjfaWqs5MB3LLYWE9QKo326EpBJU1qXxQ5he Vdw+iM19LTkuG60Bqvk0h75BS3D9UOVpC5CbS0OWUY5fX1u/SjmTZ7HzRFufeiVgcxHA WExw== 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=kzJdUBy17HEHzguiYFgss6wceACSr67wGYYd6fLd+ts=; fh=KpcrvWglXHfbiBj4/Q2m23CVqyA9Rq1RWGxEJHcK6oM=; b=fnP4qccLWLhYHY9Rns77Bd/MvG8rDl+68An2lmpEH/PrhDAxk7OdeYECfHwwol9CQd irMJGctw4sfgHFgo8YhAq4uLP/tOF4kk1wRVQ3j4Q4MDzlaot2g0RmuE9K+8N/WijKCP +iR0PHZ08cFTEGUYqUgYmYj36QZx6T7oRxVFyywhur6NDsRgJupNS46u9YWlszTFfm9X Ep96EbgvhtqGY1UXDGH3SAL98wg2eyltvV4Zi2d6DixOuf6eRHLgGxvYqW/JJ3UQf7wL AtWrGLAzUrzT78tSTzFjF1O3Xrcktcqh8vbTqoB7qhlGP7Xw/sYa1IM5b0z6DJUVFlgl x1YQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=GxHyLcjk; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.120 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=1794435504; x=1795040304; 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=kzJdUBy17HEHzguiYFgss6wceACSr67wGYYd6fLd+ts=; b=PoaN9TsgZCepJwusLXu4B+Hqx9V/DZTVbUr3keJgsHujqzpSH/Cq+F4FDrEzm229F4 vbOTQ+/1AHotEiIrEp/mP0RNpaqnEQcsJk0cTm4Tw/+KIvcw2nkQCziFRg0LDpTOnI6z 4stwM6vKfXFRB6O+rVQsywqANH79ZpG6mL2LMUcoG5upHNg319VZnrnV2lM85qx2LFvl zb1xY3w57Lj6ebicWn30te4ykcn4FR0eC9wT/4mmBkdxZJGVAYpqt/DUHnFrI+lWtIQI wJgguRDPhvA3MxFFrw8Bf4LpChMJ0tyulCym56zXnzJt0jWvI4tEPvRwaHJwUNX+kyrK m3Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794435504; x=1795040304; 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=kzJdUBy17HEHzguiYFgss6wceACSr67wGYYd6fLd+ts=; b=hDaPbXi033NR/JDSHfx0dA0JeCKYN1R1g0G1iVTvS+GGgO/Y2VRxARgol60J/Rd4DR 6GZgBGNHjJznNSwDgbscjj5vVjPLB5TN1AlszuCAiAoxlfbwrs2piLzkAVow+5Zsgaw6 XnZXvVQEiYjDOgf8lXSGpJ/yNadJcMFWi5HnLCG/tD+2klUX3UlGhuPQKyy50sPuu+Uf YdSpbVu2IcLpLEn38JL4EGEsChML6Yf1pQNN3eU6ygEKwf4lBsW6Bj91xQowvGaWeQSo O+VNRXoOLddfD1+VLEsCPlzPo/0FvGX3ydOy6u3per6BTya+VUEE1mLkpwk+C+TZ8Kki pj0Q== X-Forwarded-Encrypted: i=2; AL+hErEVETJtxDEA9comyBp1MWEXWoUBd8VhQufqoXXtSEC/8JPa12rk8xWudcopaaIeD/g84fSQZYfU7L1I@gnusha.org X-Gm-Message-State: APuU4Z82fcsbv9HUUmrpNBS0o8UhByEivnNex+AX6GTKJTbNIdzRxGxk t0Yn+l31ypyETZ97t8MvMYwH+W+WJydyeeLIJGIxrB12xhpFjSaWU2iK X-Received: by 2002:a05:6870:8997:b0:4ad:9063:875c with SMTP id 586e51a60fabf-4ae4683804emr3580020fac.2.1794435504254; Wed, 11 Nov 2026 14:18:24 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLddbTqV7Z3FOP3ArSAmK4abo94XcruqsBMlPEdMisK1jiw==" Received: by 2002:a05:687c:47:10b0:4a7:579d:70ac with SMTP id 586e51a60fabf-4ae44de14f5ls1060645fac.0.-pod-prod-06-us; Wed, 11 Nov 2026 14:18:15 -0800 (PST) X-Forwarded-Encrypted: i=2; AL+hErHodj/clpePdp2Px7Qt8+r0CvkvfPUJqRyYQHkBHGZp5VgJgRh6Gn6furm6Pfqxcz+DfwOE40LkjgfN@googlegroups.com X-Received: by 2002:a05:6808:c3eb:b0:4e7:c6f2:75a6 with SMTP id 5614622812f47-56b98428ac7mr3526471b6e.68.1794435495583; Wed, 11 Nov 2026 14:18:15 -0800 (PST) Received: by 2002:ab3:6d30:0:b0:31e:691b:f27a with SMTP id a1c4a302cd1d6-320704c0bb7msc7a; Wed, 11 Nov 2026 14:05:03 -0800 (PST) X-Forwarded-Encrypted: i=2; AL+hErFJkcN2pKyxuos0zDzpf8ZCV/p7s81QYc6RW65wIdwGEwknpWka5YxKibzmyeed2OzvCDjJfHbjZyHV@googlegroups.com X-Received: by 2002:a2e:bc29:0:b0:3ae:3df:d235 with SMTP id 38308e7fff4ca-3ae12681a07mr7863381fa.14.1794434701529; Wed, 11 Nov 2026 14:05:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1794434701; cv=none; d=google.com; s=arc-20260327; b=LfsQ+rxjWY28YAJemZ9ERdJBLRKvQyM4OmFrUqGae2LQtV4B98Zpqo2UNiqvf22IX1 gqsmSY6bYllhep3Ut9cb/8gHJmLtnwmXAGJeC0aoR/332GcHj8/Wxkn66VDB4xtR69Iy B1R7jM8Nwf3DJqliYJf0Wt8PqHdmMY5Ym7/czFVqRygjxdyrN+BvftYFVt270kpvtq/m Kj4dW4MrQzG7Rhhn11R47+1UeuPSxkHiFu/4+3XVXrhMIW9p/Cm3XbjKeKI4pkP3DT+T xKbghsB6Ihn6GRhrYZvyraCgbCbfTA3q4cy6N/W6KzHTmf0qiDhqIzcD14Zh7VhObZ/T AEhQ== 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=w9soPtclLvkIcKFPFoG0Q8si4KKMtvKgu0H85UV97Ng=; fh=9vhHvI2usNgjRMqX9eeRUWyp4LhVQw+Z0B/WH0UGKMw=; b=ljLXQSG1D8BIrAI44gVr6xB1gxhEU7ULGsIJ71MUDYb8cB2+OMh3WiPrcwlFq6u+hh ZOJcoaSvZqYCaOZlQZi1GBHeWu9Zq9Q6waGwELwCYvCUgucOqOYPz1cwkzV1LoaLf/bC +6mjw2zploGpMgqLUmZ3pROzZ3S5gRwAohR5vk7uv4IE2JiNcyKBh6hPdK1wh9gUZmKq 90l6Vx2EW0NDHohe1MNwMBn980s6B85cyJaxm84jACGzDVhBCszssDx8rmGSI+k5R7TT uHd9zVXERZ6gA09gicXosoWIJ0y831KcJJoa8dzEP/FJ26HZFubm8Q8MpWmWhpN7gdrZ 29Aw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=GxHyLcjk; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.120 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-106120.protonmail.ch (mail-106120.protonmail.ch. [79.135.106.120]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-3ae09279e24si889231fa.17.2026.11.11.14.05.01 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Nov 2026 14:05:01 -0800 (PST) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 79.135.106.120 as permitted sender) client-ip=79.135.106.120; Date: Wed, 11 Nov 2026 22:04:55 +0000 To: Anthony Towns From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Ram , Bitcoin Development Mailing List Subject: Re: [bitcoindev] [BIP Proposal] Stale Tip Relay Message-ID: In-Reply-To: References: <3rRzUIQUWDcT-ASQXvovARX12jzE0UWy0RQ8fk7M_z3bW_k2LWPPEvRhoD6sEe3GW3fjCdtzLOZN34TCsB2CI6iRcdjer9Y8QiNwUh2QepI=@protonmail.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 3b7f718b767167818faef8412d29a1a064f57a45 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=GxHyLcjk; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.120 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 (-) On Monday, November 9th, 2026 at 11:23 AM, Anthony Towns wrote: > On Thu, Nov 05, 2026 at 11:19:58PM +0000, 'Antoine Poinsot' via Bitcoin D= evelopment Mailing List wrote: > > I'd like to suggest an incremental approach, and to start relaying only= stale > > headers at first. > > The reference implementation [0] offers three modes: no stale relay, > stale header relay only, or stale block relay, and defaults to none: Just one more knob! I think an option for this kind of thing is counterproductive. It needs to be on by default to have an effect anyways, and if we think that it could impose costs substantial enough that a node runner may want to disable it (= i don't) then we should reconsider our approach to data collection. > Are you arguing that the default should not be "blocks", or that "blocks" > should not be a supported option at all, or that even writing up a > specification on how one might relay stale blocks is improper? I argue that the default should be headers. I would also argue, but that's an implementation discussion, that we should= n't support "blocks" unless we intend to turn it on by default. > > This gives you most of the benefits, without having to make an argument= that the > > protocol change does not negatively affect mining incentives. > > I think there are a few simple arguments why this does not meaningfully > affect mining incentives: > > (a) any miner that would benefit from improved stale block relay can > cheaply implement this themselves; this is cheap particularly when > compared to the resources needed to deploy an attack controlling > a significant portion of mainnet hashrate. > > (b) mining incentives are centred on the block with the highest > cumulative proof of work, which is never a stale block; so this > can have at most second order effects: ie, far weaker than the > incentives to avoid mining stale blocks in the first place > > (c) it only changes relay speeds, and relay of a new tip that's based > off previously stale blocks is already quite fast, so any incrementa= l > improvement here only has the potential for a very small impact. I think it's more complicated than that. The current public relay network is an equilibrium that may be costly for each individual miner to deviate from. For instance, a miner may not want to develop infrastructure to relay stale blocks, then go lobby other miners to adopt it, for a slight increase in expected revenue. But that same miner might well tweak their job distribution, if the relay infrastructure is already deployed across the network. I agree the effects are most likely small, i=E2=80=99m just not convinced t= hey are negligible. My point is that it=E2=80=99s not worth working this out rigoro= usly now, when relaying headers alone gets most of the benefits without raising the question. > There are, I think, two main benefits to relaying stale blocks at the sam= e > height as the current tip [1]: > > * it gives awareness to the network as a whole into what exactly is > being mined, removing concerns that an honest miner working on a > stale block might have been engaging in a block-withholding attack > when a reorg later occurs Fair, it would make it possible to observe pools that start implementing some strategic block publications without going all the way to full Selfish mining. > > * it makes it apparent if there is were double-spends, or if a > significant percentage of hashrate is censoring transactions (either > due to a widely accepted soft fork, or due to an attempted 51% attack)= . I don't think transaction censorship detection is a valid argument here: at any non-catastrophic stale rate, this barely gives any more information tha= n the miner's mainchain blocks. > [1] I don't think there's any concern about sharing stale blocks that > have signficantly less cumulative work than the current tip, which > already occurs via the stale-blocks repo at > https://github.com/bitcoin-data/stale-blocks/ Fair to distinguish between relaying near tip vs historical blocks. But this is not about sharing, it's about what should be relayed on the public network in real time, so i don't think the Github repo is relevant here. > I think we can put numbers on this, based on reported numbers from "erin" > during the two-block reorg around block 941880 [2]: We shouldn't read too much into the numbers for a single node in a single instance, but that ~1-2s figure is roughly what i would expect (per hop). (Also, not important to your argument, but there is a typo in your numbers with a lower hashrate: s/3.139/3.137/) > This is effectively https://en.wikipedia.org/wiki/Precautionary_principle > > I don't think it makes sense -- if we're afraid this feature would be > detrimental, then we should be equally worried about it if an attacker > were to implement something similar in secret, and should thus perform > the analysis and, if appropriate, implement countermeasures anyway: I disagree. The current public relay network is the status quo. Changing the default behaviour of the public relay network is not the same as miners coordinating to deviate from it. > I think the opposite logic is also worth considering here: selfish mining > already suggests (via the gamma parameter) there is an advantage for > an attacker if they can relay their blocks more effectively than honest > miners, so, if anything, having the honest network not relay stale blocks > seems likely to be providing an advantage to an attacker who adds their > own relay infrastructure on top of the honest network's. The effect here is in the event of a race, non-selfish miners can reorg faster to a non-selfish miner winning the race. That's true, but the advantage is dwarfed by that of Selfish mining, and i think all bets are off anyways if a miner is actively attacking the network. My point was how this change might incentivize (or not!) a pool operator to tweak their settings slightly, within the framework of not trying to bypass the public relay network / pull off an involved attack like Selfish mining. > > > 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 f= or this, > > and pre-relaying them does not affect the incentive structure in the sa= me way. > > > > Therefore i suggest to specify and implement relay of stale headers, th= en later > > revisit whether the additional information present in the block content= (pool > > attribution from the coinbase, and validity, i suppose?) is worth the w= ork on > > analyzing the effect on the incentive structure. > > As per the above, I don't find this concerning; and perhaps more > generally, I don't find relaying information that's backed by > mainnet-levels of proof of work per byte to be concerning. > > Cheers, > aj > > -- > 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/avHvtxnvoNwbczC8%40erisian.com.au. > --=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/= ktZb1ZnKZJb1qh4uGvGybRoeiMA8nD-BfozO92FtGWs3ELzPPM8QMcwL8qZJVRF9kk0jDdubLPU= lxhj2YHk1Ndu2A5uMVGC8swfHAuE-IrQ%3D%40protonmail.com.