From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 09 Nov 2026 08:17:39 -0800 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 1xQS3v-000I1q-5b for bitcoindev@gnusha.org; Mon, 09 Nov 2026 08:17:39 -0800 Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-7170f8d912asf1091870eaf.3 for ; Mon, 09 Nov 2026 08:17:38 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1794241053; cv=pass; d=google.com; s=arc-20260327; b=PqBls5FHsjz4fcL2FZViH6lHLxLkRZdXYGUTTEAdK029hu8C3SKaLyCuI/MFW1Uzfj f2oCPI3/rZ1LEnwL3g5x/aGroyJ+s1yLz1k2C7yCPK7QR+mHxgnVFPD3Fzx+H3keJeYz WcQAFpFn825eN0qjv5s0luJ2VSkkblEOCWKLB13sOs47ASQ9XN+sPkJP4Up9yxY5KBUs izLW32z/xQaP26EnNOXy34KzUwUUHP3+wFqKXasxYiSavZekLWXpx59rFFY3Fie+E+B1 GWHjrqeDt7O3UcY0lO1SGaGZape61DVyEQPAQ85IGg46MwP+EG7qJN+HcycDvxynNuRw LkPQ== 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:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :dkim-signature; bh=Oy8DAZ7YA49AUewVHlF5vDh2tB8RmZ8fv80A33/taz4=; fh=5dCa1zI4HNmoqgQjheL+IW47iI08/kbVGhMzgiD6NPo=; b=fBcnJ/2amqhv7Bg8JxYBUGZS105Ha12uKLmf6ggpC+g/3xXZ9j38xQymw9eOrV0uMU JF5SEHXhD0w+A1FVLiF6WAAnBbuGFBa3ag6BskhBVDVK+tHJeHnuv27TZCfwic7PLvQ1 HMVy1RT2Y4Zygq5qvrrvJiyxfzrJyWUdX5RPeAARI+YS7AnC3FRnEhkFxNkPyMWYLUbH JJh9GMHPCwmFNRYlhKBgX53hd4ZLCaLhI99aSbyWDCGnT45MC0oPYnmsqvZIXNksgJd9 yZBVe62n03H3GenVarpICJjKLNjrrFHOaAhxsEtdTMfZhd7Ckib61zeaRSeEw3HcIsdv Gf+g==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20260707; t=1794241053; x=1794845853; 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:in-reply-to:content-disposition:content-type :mime-version:references:message-id:subject:cc:to:from:date:sender :from:to:cc:subject:date:message-id:reply-to:content-type; bh=Oy8DAZ7YA49AUewVHlF5vDh2tB8RmZ8fv80A33/taz4=; b=hdfoE96s6II7GYSHJW7Ax/cRJllREE7YUgGBrH2kEk7NVoBHlFmVRoKgt2Adv0ajqv wMq39JiNBuHZiS6+Y7pAM5SBb6xPAkBkY0G4Q3aagHHyndGOqbcdiAPrWP9VTcmPEVWz qAw864dEtLFH4VF6GG1xkhTmp5urNqJ6GCzbu2oH/yNLkQIXaI+LBmTZaFNDFCPuYr+i ssgtH0UhNkr8qwTd8CNyTRCzWsaCrV7WnOuIFl63tOb5F7zC11wUHxzQ3y8ORg685hxI 4V98r6Uoard2vue/q01jy2pAaKvQBk70e3ciHobiB9tQOREeO6uD1d0ta6jGrPhH5J0P 1p9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794241053; x=1794845853; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:content-disposition:content-type :mime-version:references:message-id:subject:cc:to:from:date :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Oy8DAZ7YA49AUewVHlF5vDh2tB8RmZ8fv80A33/taz4=; b=fwNaTs1cMTiSCRPOls/l82GaWpaU6iVyG43si5KGiFEHpLZpFhzYeRri+clr2Ex1Ag rLFwZtyUKD0LGRGtWL5VufwUK3YkSOXvnytLXfVssm8/6rz68VDfoEtCXSAX0mQvmaBj U9EQXihf8JWp/drzK0gbvs0/IBPa5q3+87Qp4sF7MuBMZJNZznwyooodkiEesKDxV8hS qDHvFNTcPbOPvTgva7WDTxox7VoAaqsE1cADQRZs6uWh4DqAn3J+JqZ25QIZOwEeTfbL YFipl0AOz4m+Tf4ojyfPyfmsiMPwk3AFXMxsJF/Hs8WUFDhIaFvhFNPzE3cQHtGN+zyl nerA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AL+hErHokm4R0SVO7TV37kNc4dHKuFD2MhcWnMxlJQPk0lODDdJuIei4i9UnOfukLZUHyaPgYeqcTZs0ZIo/@gnusha.org X-Gm-Message-State: APuU4Z8Icy0stgQiGmxqHzXvWGjDHfyW8JsA6cpv5+64smmkDXsOAC/S XsGwoFVQHGeu8iaiB/qOT/O9k59lV5H+C+g8SDOcOBqa3aFDgmb/jYAH X-Received: by 2002:a05:6820:160b:b0:716:b5a3:9683 with SMTP id 006d021491bc7-7170f29fe59mr2194480eaf.45.1794241052935; Mon, 09 Nov 2026 08:17:32 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdfaRB9nJT/xzosJE9zU6Pvh5nJFF0W5zSuaSJriC5U5zg==" Received: by 2002:a05:6871:d40e:b0:492:46f8:3965 with SMTP id 586e51a60fabf-4ade4730e55ls1232702fac.0.-pod-prod-09-us; Mon, 09 Nov 2026 08:17:25 -0800 (PST) X-Forwarded-Encrypted: i=2; AL+hErF31eUk5s8a5OyLlfJUfwj9jc+H2xUdB7ShZLXT3SUiLigCZgGp59bhKeCTMKZFPVXFLXgB3OxwlPyu@googlegroups.com X-Received: by 2002:a05:6808:3097:b0:4ea:14ab:142d with SMTP id 5614622812f47-5683cd19f98mr65140b6e.40.1794241044995; Mon, 09 Nov 2026 08:17:24 -0800 (PST) Received: by 2002:a05:6808:ab6:b0:4f2:82e8:c758 with SMTP id 5614622812f47-567fca8ea5cmsb6e; Mon, 9 Nov 2026 08:07:28 -0800 (PST) X-Forwarded-Encrypted: i=2; AL+hErEgznwXcfJSzatKV9rXH8m0vWRzcTNj7/dr8nz9/yzsa56dcz4XK2atrZ9R7uqrf+G048Nfmn1krZ74@googlegroups.com X-Received: by 2002:aa7:9315:0:b0:8b5:94e0:91a2 with SMTP id d2e1a72fcca58-8ba860da577mr84428b3a.10.1794240447165; Mon, 09 Nov 2026 08:07:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1794240447; cv=none; d=google.com; s=arc-20260327; b=OgAu5Airu9CBpen6EI52H81+8ycVnXwDrcH2z5Xv63Z90Z8FbddBBmn/0Duw9fB9ZK by5osRrtMrnK+QowTkrM4Sp0P/9Ylo3r51LUNktASxSm2TSmpo+7t367s7kQTcGEKhGr GxHAMvO2M6t6eG/+4jcLA36g/gZHAqIMbucWUZ1YjieELXn5sc/KMj6e1+rkZeAAyzIW Dgeh5pirXsdiPZAYPr8D8DJtIII1ft7js6nRbIHJa+cf3my7+aXqj8OTabY4j5ZNwCgc IE32t0pK5EaAy1fPR0f5VqI+ErhoWdCLJeRhCEKPva/LknsKsXBu8g0NWrrZWt9+e63M QM2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date; bh=3eNUI+UmLjA+YZVaBH3kaMb3s/maUHTw1QSRxgNFufg=; fh=cJCgUem3GMcKaogliyFUSp95QFfVVp/Wwq+nVSN+xY8=; b=mioC7aQO75qroUygsg1QfX6KmjD0PkEV7cSV+5Lly9sZy0J1oU+kIkKZbdjm6c0NrZ BuGTConx4QEONj7Dbb9xkVcQakVt574m+HAR2GEhrd26u7SWYHS5nJ5snw4wRlkV0Coa NFE80zXxCb/Wifhha9nbukQVgICYIvgz7F5E456R3Zlk29ZyYIwMnnSpPaSZwSmBLsEt 3Urv3fk8/8ZVyu8YQ3Ro3p4mENcAapz3a21EIxECbKfJvUYJM+qqEY0/xXnrYLfpRwRf ZpyyuX4MTRltmyufgHZjCHO7RJ5aqoJmzpdW6u8e+yf7ddB5ht9E6S44zCf/vJLENGvq fu7Q==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au Received: from cerulean.erisian.com.au (azure.erisian.com.au. [172.104.61.193]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-8b64a1e2dc5si100160b3a.18.2026.11.09.08.07.26 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Nov 2026 08:07:27 -0800 (PST) Received-SPF: pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) client-ip=172.104.61.193; Received: from aj@azure.erisian.com.au by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xQRty-0000000037f-2vl6; Tue, 10 Nov 2026 02:07:24 +1000 Received: by email (sSMTP sendmail emulation); Tue, 10 Nov 2026 02:07:19 +1000 Date: Tue, 10 Nov 2026 02:07:19 +1000 From: Anthony Towns To: Antoine Poinsot Cc: Ram , Bitcoin Development Mailing List Subject: Re: [bitcoindev] [BIP Proposal] Stale Tip Relay Message-ID: References: <3rRzUIQUWDcT-ASQXvovARX12jzE0UWy0RQ8fk7M_z3bW_k2LWPPEvRhoD6sEe3GW3fjCdtzLOZN34TCsB2CI6iRcdjer9Y8QiNwUh2QepI=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <3rRzUIQUWDcT-ASQXvovARX12jzE0UWy0RQ8fk7M_z3bW_k2LWPPEvRhoD6sEe3GW3fjCdtzLOZN34TCsB2CI6iRcdjer9Y8QiNwUh2QepI=@protonmail.com> X-Spam_score: 0.0 X-Spam_bar: / X-Original-Sender: aj@erisian.com.au X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au 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.8 (/) On Thu, Nov 05, 2026 at 11:19:58PM +0000, 'Antoine Poinsot' via Bitcoin Development 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: ``` Argsman.AddArg("-staletips=", "Track recent stale tips for later relay. Options are 'none', 'headers', or 'blocks' (default: none)", ArgsManager::ALLOW_ANY, OptionsCategory::NODE_RELAY); ``` [0] https://github.com/w0xlt/bitcoin/tree/staletip-v4 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? > 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 incremental improvement here only has the potential for a very small impact. There are, I think, two main benefits to relaying stale blocks at the same 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 * 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). (That you can reorg faster if the stale tip is extended and becomes part of the most work chain, rather than the one you had picked is a benefit, but the only case I can think of that making a meaningful difference is you had an attacker mining a chain of slow-to-validate attack blocks, with an alternative chain being built that excluded those, and furthermore if many nodes also supported parallel validation of stale tips, so that nodes could easily follow/reorg to the fast-to-validate chain, even if it frequently had less work) [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/ > 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. I think we can put numbers on this, based on reported numbers from "erin" during the two-block reorg around block 941880 [2]: * it takes about 1.2s to download three blocks for a 2-block reorg * it takes about 1.2s to disconnect a couple of blocks * it takes about 1.25s to validate/connect the alternative pair of blocks * it takes about 0.7s to connect the new tip [2] https://bnoc.xyz/t/two-block-reorg-at-height-941880/97/23 If Foundry had mined block 941883 on top of Antpool's 941882 instead of its own stale block, the comparison would have been something like: * Reward: 3.14 BTC for one block versus 9.4 BTC for three blocks * Validation time: 0.7s versus 4.3s; so 0.12% versus 0.7% chance of a block being found during validation Assuming Foundry had 20% hashrate, those numbers look like: * 3.14 * (99.9% * 80% + 20%) = 3.137 BTC expected, if you find a block * 9.4 * (99.3% * 80% + 20%) = 9.347 BTC expected, if you find a block Those numbers don't change much if you have less hashrate -- a one-block-a-week miner who had somehow hit two stale blocks in a row would get the same logic: * 3.14 * (99.9% * 99.9% + 0.1%) = 3.139 BTC expected, if you find a block * 9.4 * (99.3% * 99.9% + 0.1%) = 9.334 BTC expected, if you find a block You can dive deeper into selfish-mining attack scenarios there, but the only difference is the 1s or 2s to relay the ancestor blocks for a new most-work-tip, which you can set your own infrastructure up to optimise for, if it turns out to matter. I think that two-block reorg is also a good example where knowing in advance both that the stale blocks existed and what their contents were would have been helpful. You can see examples of people jumping to the conclusion that this was an attack at: * https://bnoc.xyz/t/two-block-reorg-at-height-941880/97/32 * https://x.com/wk057/status/2036674054971703361 * https://stacker.news/items/1460047 Had the stale blocks that were found 1s/1.2s after the AntPool/ViaBTC blocks been quickly propagated via stale block relay, that would have refuted concerns about selfish mining -- both the block timestamp and transactions in the block would demonstrate the block was published in a timely fashion. With nTime rolling, the headers alone might not provide good evidence that there wasn't a selfish mining attack occurring (though in this case the timestamps appear to have been accurate based on the stratum job data in the bnoc thread), while the transactions making up the block likely would, and would also address any concerns about potential censorship or double-spends shoudl a reorg eventually occur. > 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. 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 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. > 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 this, > and pre-relaying them does not affect the incentive structure in the same way. > > Therefore i suggest to specify and implement relay of stale headers, then later > revisit whether the additional information present in the block content (pool > attribution from the coinbase, and validity, i suppose?) is worth the work 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/bitcoindev/avHvtxnvoNwbczC8%40erisian.com.au.