From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 07 Sep 2026 08:45:39 -0700 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1x3bXO-00059p-JR for bitcoindev@gnusha.org; Mon, 07 Sep 2026 08:45:39 -0700 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-46617932071sf1731314fac.0 for ; Mon, 07 Sep 2026 08:45:38 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1788795932; cv=pass; d=google.com; s=arc-20260327; b=diW7i5G4R8HbtVvfsOUZMXvOmOvsIyu+YQo/nP8VPP9Rb59Tu6gDp03XYGj3tJ4TKW 3/2FYtZHt5wo8IQioIzUFLzOvKaIejFOZO0KJ7NuImsqy62SiZsY0qdP+UTK+E11CY+i 3y/f8uTmtQdeR5g59s6c88FAi58h9XqvsfTXmImQNLh3VIWNU6zdEm7dcknChX45uMxr JSjH2Aqi2icTocxs+zBZNwqyise29X8qdwQ2JJA1ndAZXRpU/JiPhVdkCaXO+jNYH5I3 Q0atB3ckpaaExgo698fva0oGxytu45joqejCr0V+kUWWpDcrSOd3/dqFK4lMxhVPBADs TEDA== 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:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=4zcAvkIpCowtbCvyK5+chI+tIjfk2SQDhgPsA5hSSlU=; fh=36IzddiOvc+IxW3ut3qTGTOicruG5wCbXKxpzHiLH4c=; b=QtR1ec7v+EoLM2zn2gHKkGnz3VKxnvWdDM+sYsoH9vGpnk/T3mIImQfn/dMMgYNLlB 2L6rsje5u7iu3UFcOQLBzUMYH7nfLEeWlpg0KXg9ni8MXyZf+dY61YRtOpn0+JaNAADw T5Pdq0l4q3kaO0Q4LcVLIutQnYnjnqzTOcHu0W27w8lElc8wVmpU6LySNMKIACLXKbvH RRNYSjK68xPygrsWS3YgtcGUohAJsgvUtMqnHLJx/5B19Z5plmytNIQSTg0ZL387Kjy4 qbWFgVeKwvUkOfNkycnCr6i3E1q+XUy/fs/np4cI+mcu2zJAF/gj82oEOg3VdjGO0Mfq JUgQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b="EesIt/BY"; arc=pass (i=1); spf=pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::635 as permitted sender) smtp.mailfrom=melvincarvalho@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=1788795932; x=1789400732; 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:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=4zcAvkIpCowtbCvyK5+chI+tIjfk2SQDhgPsA5hSSlU=; b=qJvthddoBbSQ1S04s+37cK8V/9a3qXWfSRkL8rBWVmasxyPsWkpCT3bexIsfFLM8sx JgPVAECVaS/LOGAjrN3QRB8MJHoJGdGJScjyoFuhSeikgqbvt2EA/b4VqyMipgaGK5at msNkYqyIIljm6VCuTMPsTDjD+NhIvrbUhbqgXnSgfKVSy6qcqJ9K4c22betHVfo7b1xx VLvSr/Chl177hmXmaw17Wdpoaf9nYckMRN12C/H8AwrJRrMaWIlHEmcz3hmO3mtVub4J tm2XrsSt4ujagbDiMNoAwOTfEVdFoVu1wUvrNVK6I01MiwBKoe+ob5lfQdpIjJ9es24n gkIw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788795932; x=1789400732; 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:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to:content-type; bh=4zcAvkIpCowtbCvyK5+chI+tIjfk2SQDhgPsA5hSSlU=; b=glIqVQb70D+WyZIrIJkvoaH+8wKMAgnTRIPwklNCcl+zHWH/1xUBv9m3FyCA4XHLXC 3ALqZynlSWx15YBfkHP4IWfR05lrlWHa0MHOxQaSG4+aMnvMLHqB95U7LhdgDVv4o7nR cGfxQaoT2Kl1nlkux7F05Npd0AVAo0bK3eEW+lI+Ym9JU3Sr9x2tjS7nXN7LAEPd8v/N V5wwE1ZoesyY4zniC5Ck/q6LGp6LlMQAaqrwmttJIhVMip946L8nE0y9Hs2dtVh3hx9v KPDjshxO5XEHAxdIxBbpoTUetoiguvS7GxPJu7iHnEZBBWtuC3xJP0hjg6bFyiuVqTTB REQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788795932; x=1789400732; 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:to: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=4zcAvkIpCowtbCvyK5+chI+tIjfk2SQDhgPsA5hSSlU=; b=IDtLt6bTDwh1a7wgELyAwltJXp3zYpktbDuj0cRjyX8xVrAj0GAPmOLmGINZNNROMz 4fT68tkB5veNHvDQUfsdoLElObFFSbfiqRDWgVWaUGjJp6Ake7E7HO+od9StxFZvIQGn U+LmGs0zUi+ZZw0xIQOQgc6lDu4g7sdCf/sPL1CYy7bOGKW1ImwOj2TcmCWAaZ5EryH3 wkVLarDOfNxvkpyG5YXNRB+UhfnEtO6v3CfOu+DSCbHIKDSvZfYvFc6XEpG0tmZZhgNE SAf1fiO9AZ07UB1z51MGjegT2zA4yBzpfG31UptdqPtzekSwWfhVFzXkwx3nvMxvfUQz iUuw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AKwUvBzNCqBhW0qxHRSlkJh+6ErI4nIL03D6MedmACVS6zGNoUS7/TtS7i/aWYkw4HO8UOruO4BmeM7qgjXE@gnusha.org X-Gm-Message-State: AFuF++ksq6stwlARjHSi+SuBFhJty7cvz53vIEoiZc85+AvcFv/L5pfD WKWYUbMlYcorzfHPQ/DMwJiRpmZPjfWJyLAL1LNYXJPIeuMUecKRJych X-Received: by 2002:a05:6870:b2cd:b0:475:a112:126b with SMTP id 586e51a60fabf-475a11249fbmr13585083fac.24.1788795931955; Mon, 07 Sep 2026 08:45:31 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdezphdnSHbZpRwS+6Ih5fFmwNfcp5UmR7/GitrS3wVvsQ==" Received: by 2002:a05:6871:e856:10b0:456:6f58:d522 with SMTP id 586e51a60fabf-47538dadcedls2262732fac.1.-pod-prod-04-us; Mon, 07 Sep 2026 08:45:26 -0700 (PDT) X-Received: by 2002:a05:6808:318c:b0:48f:c907:7a40 with SMTP id 5614622812f47-4b966ace384mr13068340b6e.11.1788795926247; Mon, 07 Sep 2026 08:45:26 -0700 (PDT) Received: by 2002:a05:6809:93:10b0:4b2:5fe6:230c with SMTP id 5614622812f47-4bbefe7b677msb6e; Mon, 7 Sep 2026 07:44:32 -0700 (PDT) X-Received: by 2002:a05:6820:179b:b0:6b0:589e:42f4 with SMTP id 006d021491bc7-6b6fcac5a26mr13649231eaf.20.1788792271360; Mon, 07 Sep 2026 07:44:31 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1788792271; cv=pass; d=google.com; s=arc-20260327; b=Cd+R8UVAg/vY7Bi1egSoNgb1aqcj2F34JEKBSjLRofNRgSm/thjByrvw8p68LuYeKo KdF8uEGXjAi1Cj8wtZfHshKNu6q9x4lbLw4suXFKO8wVqjsemYS/9D6Mgor8xuGV5yA6 5uV1nTnPPyom4Y20Kb5+f5qzYWvJlru4G7NelRJ9sIrb7QaHw//LnxTZfW73krE0JScT 01o0Zmm/MhGOn3gcZVPwQH2kzIdbQabi72T+05udsTLkU2x7BLw0BcGAXgHkxANJA1wp T5E2oz6TDTBOWyyIGWAfcqWBn2L6VpoN1QMlSnULGosTerZewQf7KT38rhbgZ5h+8Wjj LxIg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=TGizDAiihhCHBwlVHVL5LF6s0EATiNbFpmYdmxr5mas=; fh=m2IwlnuMmP6ceRgqI8U7RCh8Dkd3VeWlWEfxse0Wcvc=; b=Yrmnhfvrz4V/u2jz/HqiWIVJECr/wcTr5bXe/Vj56eJPYUk3mYB8MLkD8M3ZVW1NNm thhMbOe7ezl6ePvoDKLJEGqIPU04WjfL7IeoA5K7WLXKFIbblkdoGx5pIJzhx+ZqkgC+ 3S1tf2ZJyHwYxe+OOWARFZrvxYE4WVS+mbtwXgeR8poMpMBjjVQ2/G/4DfiFEjTxcRPG yiR01tIo/d+RCOIP0LAOdqs1Pv0L8ZCtHTI2jFC/DkeuxDDocm0YkjivIIToBWMpxXPo IFjA+wLHZNXDbluppoiu65JlRJyja2wiute0Ve/GZ2JMlRpgKxsNvLY8c+SKsZtadNM8 Tk7w==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b="EesIt/BY"; arc=pass (i=1); spf=pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::635 as permitted sender) smtp.mailfrom=melvincarvalho@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com. [2607:f8b0:4864:20::635]) by gmr-mx.google.com with ESMTPS id 006d021491bc7-6b97b66d2b5si154562eaf.1.2026.09.07.07.44.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2026 07:44:31 -0700 (PDT) Received-SPF: pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::635 as permitted sender) client-ip=2607:f8b0:4864:20::635; Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-2cc891373e0so37735655ad.2 for ; Mon, 07 Sep 2026 07:44:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1788792270; cv=none; d=google.com; s=arc-20260327; b=rTFbANZlVL1RiNloJvmHz3cz2XoJlW2LNov2UWFJzbooM+ZODW1+dh5pyGy3UD23ca y5FN3yIhgRpak+pDwsUq0KsBV+tT6iy2zvM9Jwlio4bLOZJbI5deQ5tqxLd6vcPYSH17 LaxQt7rY2RvM863NOMP4qM+6PwkxqB2yzaxtC1PzkoNCbIBi+7V2nX5Fr0BXXadeGmIW 5xxcDlcZyljpY4Vymz/yPO7P0QjOJWESoUWQivX2zlSdbw5CcipK5ZnmT7SPwzray/Sz N5CjkMEA0hopWErfzcqusfTBpdErK4pAwaGL6CeXtz91AwX6hcC8fURDBUFs0mKN0px2 UB0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=TGizDAiihhCHBwlVHVL5LF6s0EATiNbFpmYdmxr5mas=; fh=m2IwlnuMmP6ceRgqI8U7RCh8Dkd3VeWlWEfxse0Wcvc=; b=AOwWpIX7A6NHPPqKuLRwczvXtuT337tgjJ1unvZcv3UUUl8iisAV/3rLIkvrk3pmC+ 7a4UJ+nTJswYyhRVgGyIucA4YEY+Qldn7xbIz2fOFcL4GSpob+iUkTQOElW8MrKTYe/N E0wf07/Lab5ZPc+SfszNnhGJdhsNkHlEZwzpBhcjzHlVgvb9KaY3QjkwvXoIPpArE72b nguSbkqBNa2CDcWKzwKtkK2qCba1fMqbY9fWSuKtyze6KMmwQXeEdFnWGWZ7ctOHEqlG SkV4EzDEwW6+gFAAuBIT5uiiUDO7TYLQo9e5p0kbTRcF0N6yovMWHO9zG8oBx2BAlUrA 7YKA==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AYBFou1Tn37Ki0Hhx+JoSBiWRZXa2JO+XqFTdpDm8xr4c4q4IQnXUgarToC+q+sXiGl rgDl5uwT4kuWsKYQPiCQoEU5iNDWgWMXdWtjUMiXxIdx0Ui1omzzacZ2STKPN/m22r3zkfdNwzX 482N1zpWa+U+wQNKox4km0omt42O1vm5hkJr776V8eq3A0n/awR6MW9s9Iuhtj66KKw7F6Ag/hd Id+fmRWpbW4Ys65UcMnDPy4Bh8NBUdfEudTSm2eXBDqw12L62Syw3TnMXqa/vIODhga9XycG+sx h/Ioq0BK004NfqPh3+JiTJLlAa0EZnGELgnnprGmu+qWT8iUlKIKZ+RgNBLDPnqSWKIpWlFM2QM /HHRFmSwE24CmVXFLo+iz6Amrprae/6LKgpGKoe7KOJM= X-Received: by 2002:a17:902:f68e:b0:2d6:3c2f:6a4 with SMTP id d9443c01a7336-2db5d2d9449mr67043755ad.13.1788792270345; Mon, 07 Sep 2026 07:44:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Melvin Carvalho Date: Mon, 7 Sep 2026 16:44:19 +0200 X-Gm-Features: AcwNN1WwueqfY559Dkvww2_uyIC4Xc0kXKnUDrP_nk7jaFR1r0psNbYHEDVHbIU Message-ID: Subject: Re: [bitcoindev] Unbreaking testnet4 To: Antoine Poinsot Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000d9d8ff065ae5a785" X-Original-Sender: melvincarvalho@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b="EesIt/BY"; arc=pass (i=1); spf=pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::635 as permitted sender) smtp.mailfrom=melvincarvalho@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.5 (/) --000000000000d9d8ff065ae5a785 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 18, 2025 at 10:24=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Deve= lopment Mailing List wrote: > Hi, > > Testnet4 was rolled out a year ago to address the shortcomings of > testnet3. One of those shortcomings was the difficulty reset creating > havoc. [0] In spite of this a similar rule was adopted for testnet4. [1] = As > a result, testnet4 is similarly creating havoc. [2] > > The goal of testnet is to mimic the Bitcoin mainnet. This is why it is > useful to have in addition to a more control testing environment such as > Signet. > > The given rationale for a difficulty reset was to let developers > occasionally mine blocks on their laptop. But you cannot have your cake a= nd > eat it too: either the network is permissionless (PoW) or you assign > identities and privileges to some (Signet). By trying to do both at the > same time testnet4 created a loophole for abuse. As a result it failed on > both count: it neither mimics mainnet nor allows developers to mine activ= e > blocks on their laptop. > > I propose to fix this by removing the difficulty reset rule from testnet4 > through a flag day hard fork on 2026-01-01. I picked a date well in the > future to minimize disruption. This leaves enough time for a patch to be > reviewed, merged, included in the next major Bitcoin Core release, > backported to previous releases and adopted by the infrastructure running > on testnet4. That should be enough for a test network. > > Let me know what you think, > Antoine > Coming back to this thread because there is a small, targeted fix within testnet4 itself, and I think the mechanism is worth stating plainly. Testnet4 has two interacting time windows: a) the difficulty exception, relative to the parent: a min-difficulty block is allowed once its timestamp is more than 20 minutes past the parent's (pow.cpp, nPowTargetSpacing * 2); b) the future limit, relative to the clock: a header is rejected if its timestamp is more than 2 hours ahead of the node's time (chain.h, MAX_FUTURE_BLOCK_TIME, global to every chain). (a) was added for testnet. (b) was inherited from mainnet, where there is no (a). The second allows the first to be chained: a miner stamps the parent plus 20 minutes, then that plus 20 minutes, and so on until the clock limit stops them. With the parent near wall time, two hours over twenty minutes is why the spoofed blocks Sjors described arrive in bursts of five or six and then stop until real time catches up. So the minimal fix is to reduce the wall-clock allowance to one exception interval. There are two obvious ways to align the scales: * Raise the exception to 2 hours: one min-difficulty block per two hours of silence. That is close to no exception at all, and throws away the one thing the exception is for. * Lower the future limit to 20 minutes on testnet4: when the parent is near wall time, a min-difficulty block can be at most one window ahead of the clock, and the current five-or-six-block bursts collapse to one block ahead= . The second is the one to pick. Its exact scope: the room for a burst is (now + future_limit - parent_time) / 20 min so after a long period without blocks a burst is still possible, because the exception is parent-relative rather than clock-relative. What the change removes is the steady-state case, several blocks ahead from a parent near wall time, which is the behaviour this thread is about. It does not prevent competing one-block forks at minimum difficulty, and a miner can still produce a min-difficulty block every 20 minutes of real time. It keeps CPU-mineable blocks. Mechanically it means making MAX_FUTURE_BLOCK_TIME a chain parameter and setting it to 20 minutes for testnet4; mainnet and signet keep two hours. It tightens acceptance in the soft-fork direction: at any given node time, an upgraded node accepts a subset of the headers an old node accepts. Unlike an ordinary consensus soft fork the rule is wall-clock-dependent: a header rejected as too far in the future becomes acceptable as time catches up. The failure mode is an un-upgraded miner stamping more than 20 minutes ahead and producing headers upgraded nodes do not yet accept. Such a branch carries negligible chainwork and should be reorganised away once hash rate on the compatible branch passes it, but pools should upgrade together. A 20-minute clock tolerance is ample for a testnet; the two-hour figure dates from early Bitcoin and mainnet has no reason to touch it. In one line: testnet4's 20-minute parent-relative exception can currently be chained through a two-hour wall-clock allowance. Reducing that allowance to one interval removes the five-or-six-block steady-state bursts while preserving the exception itself. Melvin > > [0] > https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NS= NPH-3fDCUfw@mail.gmail.com > [1] > https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki#rule-speci= fication > [2] https://fork.observer - pick the network on the top right corner > > -- > 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/hU75DurC5XToqizyA-vOKmVtmzd3= uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimR= bMqU%3D%40protonmail.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/= CAKaEYh%2Bd3vpzZ85YVrasPt4QunGeNpd8nequ-DRd8d5m2ShTJg%40mail.gmail.com. --000000000000d9d8ff065ae5a785 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Mar 18,= 2025 at 10:24=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Development= Mailing List <bitcoindev= @googlegroups.com> wrote:
Hi,
Testnet4 was rolled out a year ago to address the shortcomings of testnet3. One of those shortcomings was the difficulty reset creating havoc. [0] In=20 spite of this a similar rule was adopted for testnet4. [1] As a result,=20 testnet4 is similarly creating havoc. [2]

The goal of testnet is=20 to mimic the Bitcoin mainnet. This is why it is useful to have in=20 addition to a more control testing environment such as Signet.

The given rationale for a difficulty reset was to let developers=20 occasionally mine blocks on their laptop. But you cannot have your cake=20 and eat it too: either the network is permissionless (PoW) or you assign identities and privileges to some (Signet). By trying to do both at the same time testnet4 created a loophole for abuse. As a result it failed=20 on both count: it neither mimics mainnet nor allows developers to mine=20 active blocks on their laptop.

I propose to fix this by removing=20 the difficulty reset rule from testnet4 through a flag day hard fork on=20 2026-01-01. I picked a date well in the future to minimize disruption.=20 This leaves enough time for a patch to be reviewed, merged, included in=20 the next major Bitcoin Core release, backported to previous releases and adopted by the infrastructure running on testnet4. That should be=20 enough for a test network.

Let me know what you think,Antoine

Coming back = to this thread because there is a small, targeted fix within testnet4 itsel= f, and I think the mechanism is worth stating plainly.

Testnet4 has = two interacting time windows:

a) the difficulty exception, relative = to the parent: a min-difficulty block is allowed once its timestamp is more= than 20 minutes past the parent's (pow.cpp, nPowTargetSpacing * 2);
b) the future limit, relative to the clock: a header is rejected if it= s timestamp is more than 2 hours ahead of the node's time (chain.h, MAX= _FUTURE_BLOCK_TIME, global to every chain).

(a) was added for testne= t. (b) was inherited from mainnet, where there is no (a). The second allows= the first to be chained: a miner stamps the parent plus 20 minutes, then t= hat plus 20 minutes, and so on until the clock limit stops them. With the p= arent near wall time, two hours over twenty minutes is why the spoofed bloc= ks Sjors described arrive in bursts of five or six and then stop until real= time catches up.

So the minimal fix is to reduce the wall-clock all= owance to one exception interval. There are two obvious ways to align the s= cales:

* Raise the exception to 2 hours: one min-difficulty block pe= r two hours of silence. That is close to no exception at all, and throws aw= ay the one thing the exception is for.

* Lower the future limit to 2= 0 minutes on testnet4: when the parent is near wall time, a min-difficulty = block can be at most one window ahead of the clock, and the current five-or= -six-block bursts collapse to one block ahead.

The second is the one= to pick. Its exact scope: the room for a burst is

(now + future_lim= it - parent_time) / 20 min

so after a long period without blocks a b= urst is still possible, because the exception is parent-relative rather tha= n clock-relative. What the change removes is the steady-state case, several= blocks ahead from a parent near wall time, which is the behaviour this thr= ead is about. It does not prevent competing one-block forks at minimum diff= iculty, and a miner can still produce a min-difficulty block every 20 minut= es of real time. It keeps CPU-mineable blocks.

Mechanically it means= making MAX_FUTURE_BLOCK_TIME a chain parameter and setting it to 20 minute= s for testnet4; mainnet and signet keep two hours. It tightens acceptance i= n the soft-fork direction: at any given node time, an upgraded node accepts= a subset of the headers an old node accepts. Unlike an ordinary consensus = soft fork the rule is wall-clock-dependent: a header rejected as too far in= the future becomes acceptable as time catches up.

The failure mode = is an un-upgraded miner stamping more than 20 minutes ahead and producing h= eaders upgraded nodes do not yet accept. Such a branch carries negligible c= hainwork and should be reorganised away once hash rate on the compatible br= anch passes it, but pools should upgrade together. A 20-minute clock tolera= nce is ample for a testnet; the two-hour figure dates from early Bitcoin an= d mainnet has no reason to touch it.

In one line: testnet4's 20-= minute parent-relative exception can currently be chained through a two-hou= r wall-clock allowance. Reducing that allowance to one interval removes the= five-or-six-block steady-state bursts while preserving the exception itsel= f.

Melvin
=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.google.c= om/d/msgid/bitcoindev/hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX_= _S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU%3D%40protonmail.com<= /a>.

--
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/bitcoindev/CAKaEYh%2Bd3vpzZ85YVrasPt4QunGeNpd8nequ-DRd8d5m2ShTJg%40ma= il.gmail.com.
--000000000000d9d8ff065ae5a785--