path: root/ff/5a9848a11c77d86e38c64581cf3dd20307f166

Delivery-date: Fri, 04 Jul 2025 23:54:27 -0700
Received: from mail-oo1-f61.google.com ([209.85.161.61])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCY3VBMZVAMRBF4YUPBQMGQERIIQLYI@googlegroups.com>)
	id 1uXwn4-0007xj-CE
	for bitcoindev@gnusha.org; Fri, 04 Jul 2025 23:54:27 -0700
Received: by mail-oo1-f61.google.com with SMTP id 006d021491bc7-60beffc65e2sf1606164eaf.1
        for <bitcoindev@gnusha.org>; Fri, 04 Jul 2025 23:54:25 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1751698460; cv=pass;
        d=google.com; s=arc-20240605;
        b=CETRs0abC2b9AR3/gLW3bc/1QWBIcIB7mHaX+vDKbbQ9JLZaKkn+tneVuJZO2TZGqP
         UG8A8DNpXWGjCdHQo8J8iANZIfm+EUDR5EIai5NIWiitv77T1Hqp45MVpp6IOzIy36Va
         o49Gc9TW7viqAMTuiXdHm3msphJsxmQFzCOo/ZCOSmZDGAD1oBeFLYNnFq7aVE96penj
         +jlJFwGQHA/vFbx3TMJYqZ3ZUDHFHl9OUcCqKSz9ENDJtS2tGIrge4kqhns4DTqPtXDF
         xiomWT6iYeLtsPJHLEIcWcSBuA2JLjBqGRmIGbrZuz/FmqUyWVKuKGXAATfPcMGH6rnQ
         M33g==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        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=khwBt7RUYGhFF7aJmW6JoXkR0NOVfcInyt0XDsvUy0c=;
        fh=Q0u61qgNi4rxnJ4G4IBJfLZIF1pX9JLxSHMdnsxTvj4=;
        b=N9MPjXYnG8SMqDDxYNpPokBQ52H7pIoTYVqXUNmRIo6r81Y23RccNsOdCjVOouocfU
         0bWH5RIIEI8kpumu6dic7ZWnaEbPdUMsSHPEWSWx90/Xf5t6vDPKJE27AQYwwez2keWW
         VWTT6BHRCiFS7ngN4rcZlTIbt8RjowAZP1YgOU/WNY1dFM0vW29Z6qlpRqTS0blfef5Y
         1F9c/eZvqdMlARdjIyXZUYCxCSFYxPjZPKAPwJC9RWkGIrWX8O9p9SYrZDortQ4lc6Ov
         UOKKOtW0xxz7IQ/7mD3jJ0gvM0yQGc0pgFsbIhgJeGnByFJWT+GJ3LQ9t1T7lHj1ucZI
         Pc1w==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=VEkmAH3O;
       spf=pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=garlonicon@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=20230601; t=1751698460; x=1752303260; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=khwBt7RUYGhFF7aJmW6JoXkR0NOVfcInyt0XDsvUy0c=;
        b=AgpgIgjfAMoBTOR0QXNMiGPQOulLgn5WV8B9KDsNcC3K2BGSL8zk3f/s800DUW5B3c
         0bZ1zxSQ5SSsyNWezINE22gVYft1yuyx4ia6E9NQ1ZfOcXAv0ohyoEZ6QOxr54VVSn/h
         bZSUFtYplun2AaJUbdHsMVOzwNtaBSAyygqXA6GhkCVnYaKgaiQ4jK18C1pc4vy6Md5t
         9Acmetin1VpVtW3HZdckJyaE2odunHqKzcqIFO8Ohbv29f0YQaokGi42JWFw2wqRjNgP
         x/zfHhPmDDt9qwJvRF/uzvaUGWiWy4LSXcCGOQLeO5gHdrqQ0ZwgjcjdVcy616DCV0jE
         +v8w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1751698460; x=1752303260; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=khwBt7RUYGhFF7aJmW6JoXkR0NOVfcInyt0XDsvUy0c=;
        b=jPq3m8+A2oLkzChJkynHHsN2Q1TqinBUR/vu+/tVBKlEzFj6VFGpPZPhMYeUvVAYlB
         qibi14pf2PgYswyBmbj0mE1pqeH0jsFnZCzjvFsSqn5ISlL0vfoN4yqJBSlSCTJBfYjX
         TN9Py/PM305fNuZ1Fqfi+Jpzm3YLxulu55z1kcebyXVul99FBXnWXecrrSU6AlYJK3U6
         DPR9v6nG2HY8gzJqpkcdbFdGCrrF7UzUeyq+9IWIIQ7XAMlqstHYA37VYlSZYwSCC4kB
         4KIkwFFSO4Kl3SLWjq+fi8TS6QMR6eVrKo2HOunR8Rhr9jRH+LNb+PY1GFQt6woQYLOH
         aBbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1751698460; x=1752303260;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=khwBt7RUYGhFF7aJmW6JoXkR0NOVfcInyt0XDsvUy0c=;
        b=vUkhxIj5wsv4G+wxaJHVEHixt0TynQZSADmNiZFxa3PLcjrSQor6rJMmcAdtJ4TSxW
         kBbNPCSiqq5hvo8crYAPqkXxRtjFLpe7nAolKoG6xWW2LVD9KqHtq5MvCDuJxOXiMR1i
         TXZrZxCiPIEHu02CgNZA3YIxLXebcwo0Md1LkB49YeudbuVL7Glltg5btpaIslJ9S9A8
         /mXZrJbqQ/QQBerFG5ar5OD3NaHxYS/r9q+GfIy4FCvzgeg4cJyac7ld2lFNFIfb4MQ8
         vXBEnDFkH2ncVTYT+dVDIsb/XnxQwxgkGIJZ8f54qkON8Ez7W0TIVEL7FD1YbpPxd/4P
         fG3w==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXxz+DTyrqeZ88sbZGTFB5buSCmoEGsUQQp/p9YcoWW94MJxqA0aOJMXUdYu0e6vN2RNAtquyvWlEGB@gnusha.org
X-Gm-Message-State: AOJu0YycjAfsffmAo7lbArOsoN21AaS29riG4AIqQHSjFkFo9aEYES6J
	FZc5je/Ziuk5Hl7j0xGR+SGO05XGInU2Cs8nxqS9IqwzbDryyUJXWyUx
X-Google-Smtp-Source: AGHT+IEx9QbGviMxjI/0+IOMGtBKUPav/Ut4f/Mcz2KbwxAGelm1pEZKBL1bX3wetNVFLHpmtoGc2w==
X-Received: by 2002:a05:6870:c14e:b0:2e9:8f40:9ea2 with SMTP id 586e51a60fabf-2f79024e3b6mr4393859fac.7.1751698459710;
        Fri, 04 Jul 2025 23:54:19 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeTzJ4Y4rnF7gpWQcMNNHQFa39XBtvF//3SNX7erl7liA==
Received: by 2002:a05:6870:5486:b0:2e8:f5c9:64cb with SMTP id
 586e51a60fabf-2f79b14beb4ls509267fac.0.-pod-prod-00-us; Fri, 04 Jul 2025
 23:54:15 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCXWPbMofXURqxO4W7i2Pbvz4DP8WYlhamq3zAPRvE/m7mqpUvsz97ppn0aKD1AkiVqybc3TA0HXe9OC@googlegroups.com
X-Received: by 2002:a05:6808:6716:b0:404:dbf3:5b0d with SMTP id 5614622812f47-40d03950575mr3950657b6e.3.1751698455072;
        Fri, 04 Jul 2025 23:54:15 -0700 (PDT)
Received: by 2002:a05:6504:980f:b0:2b1:9db7:3101 with SMTP id a1c4a302cd1d6-2b5fb5d660fmsc7a;
        Fri, 4 Jul 2025 21:31:33 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCV05c5trFjhdguwt+bDzvOpgUx9OWZKJjt1cuHUVwVpXXZ15e3vJU39u/Ni4wz9xAxT8RsM4/ppCmJG@googlegroups.com
X-Received: by 2002:a05:6512:4007:b0:553:2785:b2e1 with SMTP id 2adb3069b0e04-55643937015mr1766415e87.21.1751689891050;
        Fri, 04 Jul 2025 21:31:31 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1751689891; cv=none;
        d=google.com; s=arc-20240605;
        b=jGBUqmKyFBV/0FTeWs2uHroJynbG2IYZT8YtgBhI7OuqVsDQ6qR5/f195jwqyn4Epj
         iryG30WqWY/1FsXHKS+3QIKei6sIffrhGKV5B9yWiMQe392KLmpF+eIbTUPwd0UNaO1Z
         +YrbTLygTnAeVvFInFBP0pMp96qERVaVfGuszpla7aunDmufNQw2bF7RQSMzlsDpFbZN
         Wgw4N9k8/QD+Yn2lsyCKyWXQgiPaBZOBMM1Ou+e6rphC8q2b9bcgG7LFMBMUHfLFg/Dy
         kLiFyuBPEk5F/qnG4sdVsFafozXpdM25FBybcjeRD2A6SdA29az8QF5H30eaoMyQ5oco
         JP/g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=bBpUK0zSMRpYImkAyn9XgvlPiUgJzL+FLCvvpAJQRYM=;
        fh=Ss39RodoYGuIQ9H3rw1gK2QqOhFWkn0LpDJVH0PGTv4=;
        b=POXNqXHdnNKO2CCA5K4oiY5qzMM9yD5OWZY74GIqmPZENnAcFSkdLeMVMI1He6P6yt
         2/4q+FrzsOPhwHyVTvSSOaQSSkoCA+wLTnjaAAmzYORC6sDsN3ixofnb9Mtekk4B4qP6
         ZXoj9S8qpw2bDR06qOXjJqNAMFbXaSUIxMrBWtUDzikr6tiDjoCzpZB4+Z2BGL0bHa5J
         BeAvBX0CrGizFiHpHBhyBPgT2vcC5SaN+bEEYXazPX8mZTLhDzNeOMxIcxLTny9MWP9+
         sLBJqEfEAAczfQjJu5+Zp4GO6VLkhibPw/MHalPTQcj2v2QWuOozOVnQrEkJu9LdjrKy
         zMxg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=VEkmAH3O;
       spf=pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=garlonicon@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com. [2a00:1450:4864:20::632])
        by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-5563844fff3si120064e87.8.2025.07.04.21.31.31
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 04 Jul 2025 21:31:31 -0700 (PDT)
Received-SPF: pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) client-ip=2a00:1450:4864:20::632;
Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-ae0a0cd709bso537136166b.0
        for <bitcoindev@googlegroups.com>; Fri, 04 Jul 2025 21:31:31 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCVD9+8KggQtllPii4jB/WiiHLoBeTu86jrmkV+WPVypfhjCXfuW/pl0DO+LY5mVK0iHmODZZhSSTcdk@googlegroups.com
X-Gm-Gg: ASbGncviOrgZAaXG6aNoh9QQXQezG8aMkwcIWjpIXyHZUCXJHjADQBvtQA10i5MhSz1
	YZ8vWmOsyq3WrWKroZdL2deY7Wuk7zmobMNUVMXLnCO/rE6KoWw6TB152jUgQF91G9nS2poNyZ3
	e/jpCrzhj8hVhooD7OsAVyLMDNCxpLTjHCcdAd4BDDIaSOMgmKk8OkZw==
X-Received: by 2002:a17:907:d01:b0:ae3:cec8:1c7e with SMTP id
 a640c23a62f3a-ae3f8309a4cmr506168566b.20.1751689889754; Fri, 04 Jul 2025
 21:31:29 -0700 (PDT)
MIME-Version: 1.0
References: <hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU=@protonmail.com>
 <afb749b2-bdb8-4b2a-84ec-b703a64ad765n@googlegroups.com> <CACgYNO+fsUtx=F=ZLZVq=FJfrgHv8NnKsjmoVS8LLVU78zjKDw@mail.gmail.com>
 <CAN7kyNiWimDXDV5xT8MCZTvKzrunjfMDDOtTYcmKdQNN1z7Lsg@mail.gmail.com>
 <aCGFXI4PRq_eyrEf@erisian.com.au> <CACgYNOJN8ZJEutL75HZz-KcbpJfMdDrODm8qDrcNDFOE7U-J9A@mail.gmail.com>
In-Reply-To: <CACgYNOJN8ZJEutL75HZz-KcbpJfMdDrODm8qDrcNDFOE7U-J9A@mail.gmail.com>
From: Garlo Nicon <garlonicon@gmail.com>
Date: Sat, 5 Jul 2025 06:31:18 +0200
X-Gm-Features: Ac12FXz0EcuDpARzBqQxKSbYcJw-YBwtef23oAjq9Jv6T7gFRkR3l86l6KJffME
Message-ID: <CAN7kyNgNowuB0Cr=cvC91QOgmUVXiawFzRgrPDENg0i2UUD+XQ@mail.gmail.com>
Subject: Re: [bitcoindev] Re: Unbreaking testnet4
To: Saint Wenhao <saintwenhao@gmail.com>
Cc: Anthony Towns <aj@erisian.com.au>, Greg Maxwell <gmaxwell@gmail.com>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000a2b3390639271564"
X-Original-Sender: garlonicon@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=VEkmAH3O;       spf=pass
 (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::632
 as permitted sender) smtp.mailfrom=garlonicon@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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

--000000000000a2b3390639271564
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> Unfortunately it's a hard-fork.

What about increasing the time of the block from 10 minutes to 20 minutes
instead? A simple rule, like "any block time greater than 20 minutes is
invalid (except difficulty adjustment, where it has ASIC difficulty)" would
force the difficulty to drop to its real value. Currently mined CPU blocks
can be accepted by existing nodes, and can be rejected by soft-forked ones,
and if the hashrate majority will keep reorging everything, what CPU miners
produced, then it would work.

Because in general, if the difficulty can never raise or drop by more than
four times, then maybe block times should also not differ by more than 20
minutes? Maybe using 40 minutes instead would be more aligned with this
rule, but then, CPU-mined blocks would still be enforced, so that's the
reason behind picking 20 minutes. And also, during difficulty adjustment,
the real time can be put in block headers, so clocks can be properly
synchronized every two weeks.

Another thing is, if someone doesn't want to be flooded by CPU-mined
blocks, then that node operator can observe only ASIC blocks today, and
count confirmations only in them. Everything, what CPU miners produce, can
be considered unconfirmed in practice, because a single ASIC block can
reorg millions of CPU-mined blocks anyway.

sob., 17 maj 2025 o 07:11 Saint Wenhao <saintwenhao@gmail.com> napisa=C5=82=
(a):

> > I think mining a more-work chain than testnet4 would require about the
> same amount of hash that it would take to mine ~13 mainnet blocks at the
> current difficulty, so you'd be giving up about $4M USD in mainnet block
> rewards to do it.
>
> If you want to have permissionless mining, then you don't care that much,
> when the chain will be reorganized. If testnet5 blocks will be accepted i=
n
> testnet4, but not vice-versa, then eventually, it would be possible to
> share testnet5 chain with testnet4 nodes.
>
> So, you don't have to reorg the whole network by yourself, by mining
> everything alone. It can be some kind of coordinated effort, where the
> network will start as a weaker one, and gradually replace the old version=
,
> by making a stronger chain over time.
>
> Which means, that if testnet4 would start with the same Genesis Block as
> testnet3, then it would take less than 13 years, to replace existing chai=
n.
> And it is sufficient: you don't have to reorg everything from day one.
>
> > In any event, a hard fork is "necessary", as otherwise whenever it take=
s
> 20 minutes or more to find a block, old clients will expect a lower
> difficulty than new clients do, so the two wouldn't be compatible with ea=
ch
> other.
>
> 1. CPU-mined blocks can be treated just as "weak blocks", and always
> reorged.
> 2. You can always require a stronger block, than "nBits" in block header,
> and it is still a soft-fork. For example: mainnet Genesis Block has more
> than 40 leading zero bits, even though 32 would be sufficient.
>
> Also note, that when CPU-mined blocks are accepted, but reorged, then at
> least in theory, it is possible to capture a given CPU-mined block from
> someone, and include non-standard transactions from such block. However, =
if
> the real difficulty will always be enforced, then there will be just more
> silence, when no ASIC will be there.
>
> And if you want to have more silence, then you can do that now: if you
> count confirmations today, then you can simply accept-but-ignore CPU-mine=
d
> blocks, and have a network, where you only accept some transaction as
> "confirmed", if it was ASIC-confirmed. Because any ASIC, at any point in
> time, can always smash hundreds of CPU-mined blocks, with just a single
> ASIC block. The main reason, why they don't do that today, is that such
> changes were not implemented in the official version, and many miners are
> unaware of their power, or don't have technical skills to do that.
>
> > and if you're resetting the chain anyway, there's not much advantage to
> it
>
> Well, the main advantage is that if someone is using some old client, the=
n
> that person can be forced to upgrade, if you send the new chain to the ol=
d
> nodes. But if it is not worth it, then testnet5 can of course be
> incompatible (but then, it would be a bit harder to convince some old nod=
es
> to upgrade; that's why we promote soft-forks in general, because they are
> unstoppable).
>
> pon., 12 maj 2025 o 07:21 Anthony Towns <aj@erisian.com.au> napisa=C5=82(=
a):
>
>> > > Hard fork in an ultramassive premine, as large as possible but what
>> stays
>> > > with existing value overflow logic. (so maybe an additional 21 milli=
on
>> > > testnet btc?).
>>
>> The existing logic gives errors if:
>>
>>   * a single input of a tx (ie a coin in the utxo set), or the sum of
>> inputs to
>>     a txn, is outside the range 0-21M (bad-txns-inputvalues-outofrange)
>>
>>   * a single output of a tx is outside the range 0-21M
>>     (bad-txns-vout-negative or bad-txns-vout-toolarge)
>>
>>   * the sum of the outputs of a single tx is outside the range 0-21M
>>     (bad-txns-txouttotal-toolarge)
>>
>>   * the fee paid by a single tx is outside the range 0-21M
>>     (bad-txns-fee-outofrange)
>>
>>   * a block's fees go outside the range 0-21M
>>     (bad-txns-accumulated-fee-outofrange)
>>
>> Keeping the total supply under 21M seems nicer than having txs that
>> spend real utxos be able to hit these errors (eg, by combining
>> the premine utxo at 21M with a coinbase reward of 50 and hitting
>> bad-txns-inputvalues-outofrange).
>>
>> That's pretty easy to achieve: just have the initial premine be half the
>> supply (eg), and also cut the halvening time in half (so 10.5M premine,
>> 105,000 blocks in a halving). Or you could have halvenings every 6 month=
s
>> (26250 blocks), and have an 18.375M premine, or whatever.
>>
>> You could also consider premining (almost) the entire supply, and have
>> the block reward be entirely fees (almost) immediately after that, but I
>> think there's value in making it possible to obtain coins for testing in
>> a permissionless, anonymous and relatively low-latency manner, for which
>> PoW is great. Might also be annoying for empty blocks to pay a reward of
>> exactly 0, so if miners included their address in the coinbase tx like
>> normal, they'd be creating a 0 valued utxo, and probably never spend it.
>>
>> I had a quick poke at what code to allow for chains with premines might
>> look like here:
>>
>>   https://github.com/ajtowns/bitcoin/commits/202505-premine/
>>
>> About 11 lines of code to implement the logic.
>>
>> If this approach made the testnet difficulty reset logic obsolete
>> (ie, a testnet with just PoW and a premine turns out to work fine),
>> that would drop 14 lines of code for the fPowAllowMinDifficultyBlocks
>> and enforce_BIP94 logic. Presumably a PoW-only testnet could also have
>> its min-difficulty bumped from 1 to 65536 or more, since it seems like
>> a single Bitaxe can still maintain the chain at that difficulty.
>>
>> The idea of this approach is that when establishing a premined testnet,
>> you would:
>>
>>  a) first define the chain, with a new genesis, etc; then set
>>     nSubsidyHalvingInterval=3D105000 and premine=3D10'500'000*COIN or si=
milar,
>>     but leave premine_block_hash=3D0
>>
>>  b) build the node software, and mine block 1 to the premine address.
>>
>>  c) set premine_block_hash to block 1's hash. publish the code with the
>>     genesis block and block 1 hash, so that the public can mine as of
>>     block 2.
>>
>>  d) once 100 blocks have been mined, split the premine up amongst
>>     devs, faucets, wallet maintainers, user groups, a managed endowment
>>     for future testers, whatever.
>>
>> On Fri, May 09, 2025 at 03:07:48PM +0200, Garlo Nicon wrote:
>> > Why hard-forking anything? The starting difficulty is set to 1, and it
>> > raises to 4 almost instantly, when testnet creators are mining the fir=
st
>> > coins. Which means, that difficulty 1 is ridiculously easy to work wit=
h,
>> > when you have any ASICs. If you combine it with the idea of fake
>> > timestamps,
>>
>> It's not the number of blocks, but the cumulative work that matters, so =
to
>> have a soft reset of testnet3 or testnet4 you'd need to apply more hashi=
ng
>> for the new chain than the existing chains have already received. That's
>> a fair amount of "wasted" hash: I think mining a more-work chain than
>> testnet4 would require about the same amount of hash that it would take
>> to mine ~13 mainnet blocks at the current difficulty, so you'd be giving
>> up about $4M USD in mainnet block rewards to do it.
>>
>> In any event, a hard fork is "necessary", as otherwise whenever it
>> takes 20 minutes or more to find a block, old clients will expect a
>> lower difficulty than new clients do, so the two wouldn't be compatible
>> with each other. You could do various things to work around that, but
>> that's a lot of coding time that could be better spent on improving
>> things relevant to mainnet, and if you're resetting the chain anyway,
>> there's not much advantage to it.
>>
>> > then you can produce a really long initial chain, which will
>> > start in 2009, and up to 2025, it will produce almost the same amount =
of
>> > blocks as mainnet.
>>
>> A soft fork of testnet3 would start 3rd Feb 2011 (leading to about 750k
>> blocks vs mainnet's ~900k), and a soft fork of testnet4 would start at
>> 4th May 2024 (leading to about 54k blocks). (These are the timestamps
>> of the respective genesis blocks)
>>
>> A disadvantage of doing a premine that way is that users of the chain
>> need to download and validate thousands of blocks and deal with an equal
>> number of utxos just to establish the premine; doing that in a single
>> block with a single utxo (or one utxo for each recipient of the premine)
>> is quite a bit more efficient.
>>
>> > Which means, that instead of "premine", you can use "ninja-mine", and
>> > achieve pretty much the same end result.
>>
>> I think in general usage "premine" covers both those approaches -- any
>> time the creator(s) of a chain gets the opportunity to claim/distribute
>> coins prior to the general public being able to mint new coins by mining
>> blocks, that's a premine.
>>
>> Cheers,
>> aj
>>
>

--=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/=
CAN7kyNgNowuB0Cr%3DcvC91QOgmUVXiawFzRgrPDENg0i2UUD%2BXQ%40mail.gmail.com.

--000000000000a2b3390639271564
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; Unfortunately it&#39;s a hard-fork.<br><br>What about=
 increasing the time of the block from 10 minutes to 20 minutes instead? A =
simple rule, like &quot;any block time greater than 20 minutes is invalid (=
except difficulty adjustment, where it has ASIC difficulty)&quot; would for=
ce the difficulty to drop to its real value. Currently mined CPU blocks can=
 be accepted by existing nodes, and can be rejected by soft-forked ones, an=
d if the hashrate majority will keep reorging everything, what CPU miners p=
roduced, then it would work.<br><br><div>Because in general, if the difficu=
lty can never raise or drop by more than four times, then maybe block times=
 should also not differ by more than 20 minutes? Maybe using 40 minutes ins=
tead would be more aligned with this rule, but then, CPU-mined blocks would=
 still be enforced, so that&#39;s the reason behind picking 20 minutes. And=
 also, during difficulty adjustment, the real time can be put in block head=
ers, so clocks can be properly synchronized every two weeks.</div><div><br>=
</div><div>Another thing is, if someone doesn&#39;t want to be flooded by C=
PU-mined blocks, then that node operator can observe only ASIC blocks today=
, and count confirmations only in them. Everything, what CPU miners produce=
, can be considered unconfirmed in practice, because a single ASIC block ca=
n reorg millions of CPU-mined blocks anyway.</div></div><br><div class=3D"g=
mail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">sob=
., 17 maj 2025 o 07:11=C2=A0Saint Wenhao &lt;<a href=3D"mailto:saintwenhao@=
gmail.com">saintwenhao@gmail.com</a>&gt; napisa=C5=82(a):<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">&gt; I think min=
ing a more-work chain than testnet4 would require about the same amount of =
hash that it would take to mine ~13 mainnet blocks at the current difficult=
y, so you&#39;d be giving up about $4M USD in mainnet block rewards to do i=
t.<br><br>If you want to have permissionless mining, then you don&#39;t car=
e that much, when the chain will be reorganized. If testnet5 blocks will be=
 accepted in testnet4, but not vice-versa, then eventually, it would be pos=
sible to share testnet5 chain with testnet4 nodes.<br><br>So, you don&#39;t=
 have to reorg the whole network by yourself, by mining everything alone. I=
t can be some kind of coordinated effort, where the network will start as a=
 weaker one, and gradually replace the old version, by making a stronger ch=
ain over time.<br><br>Which means, that if testnet4 would start with the sa=
me Genesis Block as testnet3, then it would take less than 13 years, to rep=
lace existing chain. And it is sufficient: you don&#39;t have to reorg ever=
ything from day one.<br><br>&gt; In any event, a hard fork is &quot;necessa=
ry&quot;, as otherwise whenever it takes 20 minutes or more to find a block=
, old clients will expect a lower difficulty than new clients do, so the tw=
o wouldn&#39;t be compatible with each other.<br><br>1. CPU-mined blocks ca=
n be treated just as &quot;weak blocks&quot;, and always reorged.<br>2. You=
 can always require a stronger block, than &quot;nBits&quot; in block heade=
r, and it is still a soft-fork. For example: mainnet Genesis Block has more=
 than 40 leading zero bits, even though 32 would be sufficient.<br><br>Also=
 note, that when CPU-mined blocks are accepted, but reorged, then at least =
in theory, it is possible to capture a given CPU-mined block from someone, =
and include non-standard transactions from such block. However, if the real=
 difficulty will always be enforced, then there will be just more silence, =
when no ASIC will be there.<br><br>And if you want to have more silence, th=
en you can do that now: if you count confirmations today, then you can simp=
ly accept-but-ignore CPU-mined blocks, and have a network, where you only a=
ccept some transaction as &quot;confirmed&quot;, if it was ASIC-confirmed. =
Because any ASIC, at any point in time, can always smash hundreds of CPU-mi=
ned blocks, with just a single ASIC block. The main reason, why they don&#3=
9;t do that today, is that such changes were not implemented in the officia=
l version, and many miners are unaware of their power, or don&#39;t have te=
chnical skills to do that.<br><br>&gt; and if you&#39;re resetting the chai=
n anyway, there&#39;s not much advantage to it<br><br>Well, the main advant=
age is that if someone is using some old client, then that person can be fo=
rced to upgrade, if you send the new chain to the old nodes. But if it is n=
ot worth it, then testnet5 can of course be incompatible (but then, it woul=
d be a bit harder to convince some old nodes to upgrade; that&#39;s why we =
promote soft-forks in general, because they are unstoppable).</div><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">pon., 12 maj 2=
025 o 07:21=C2=A0Anthony Towns &lt;<a href=3D"mailto:aj@erisian.com.au" tar=
get=3D"_blank">aj@erisian.com.au</a>&gt; napisa=C5=82(a):<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">&gt; &gt; Hard fork in an ultrama=
ssive premine, as large as possible but what stays<br>
&gt; &gt; with existing value overflow logic. (so maybe an additional 21 mi=
llion<br>
&gt; &gt; testnet btc?).<br>
<br>
The existing logic gives errors if:<br>
<br>
=C2=A0 * a single input of a tx (ie a coin in the utxo set), or the sum of =
inputs to<br>
=C2=A0 =C2=A0 a txn, is outside the range 0-21M (bad-txns-inputvalues-outof=
range)<br>
<br>
=C2=A0 * a single output of a tx is outside the range 0-21M<br>
=C2=A0 =C2=A0 (bad-txns-vout-negative or bad-txns-vout-toolarge)<br>
<br>
=C2=A0 * the sum of the outputs of a single tx is outside the range 0-21M<b=
r>
=C2=A0 =C2=A0 (bad-txns-txouttotal-toolarge)<br>
<br>
=C2=A0 * the fee paid by a single tx is outside the range 0-21M<br>
=C2=A0 =C2=A0 (bad-txns-fee-outofrange)<br>
<br>
=C2=A0 * a block&#39;s fees go outside the range 0-21M<br>
=C2=A0 =C2=A0 (bad-txns-accumulated-fee-outofrange)<br>
<br>
Keeping the total supply under 21M seems nicer than having txs that<br>
spend real utxos be able to hit these errors (eg, by combining<br>
the premine utxo at 21M with a coinbase reward of 50 and hitting<br>
bad-txns-inputvalues-outofrange).<br>
<br>
That&#39;s pretty easy to achieve: just have the initial premine be half th=
e<br>
supply (eg), and also cut the halvening time in half (so 10.5M premine,<br>
105,000 blocks in a halving). Or you could have halvenings every 6 months<b=
r>
(26250 blocks), and have an 18.375M premine, or whatever.<br>
<br>
You could also consider premining (almost) the entire supply, and have<br>
the block reward be entirely fees (almost) immediately after that, but I<br=
>
think there&#39;s value in making it possible to obtain coins for testing i=
n<br>
a permissionless, anonymous and relatively low-latency manner, for which<br=
>
PoW is great. Might also be annoying for empty blocks to pay a reward of<br=
>
exactly 0, so if miners included their address in the coinbase tx like<br>
normal, they&#39;d be creating a 0 valued utxo, and probably never spend it=
.<br>
<br>
I had a quick poke at what code to allow for chains with premines might<br>
look like here:<br>
<br>
=C2=A0 <a href=3D"https://github.com/ajtowns/bitcoin/commits/202505-premine=
/" rel=3D"noreferrer" target=3D"_blank">https://github.com/ajtowns/bitcoin/=
commits/202505-premine/</a><br>
<br>
About 11 lines of code to implement the logic.<br>
<br>
If this approach made the testnet difficulty reset logic obsolete<br>
(ie, a testnet with just PoW and a premine turns out to work fine),<br>
that would drop 14 lines of code for the fPowAllowMinDifficultyBlocks<br>
and enforce_BIP94 logic. Presumably a PoW-only testnet could also have<br>
its min-difficulty bumped from 1 to 65536 or more, since it seems like<br>
a single Bitaxe can still maintain the chain at that difficulty.<br>
<br>
The idea of this approach is that when establishing a premined testnet,<br>
you would:<br>
<br>
=C2=A0a) first define the chain, with a new genesis, etc; then set<br>
=C2=A0 =C2=A0 nSubsidyHalvingInterval=3D105000 and premine=3D10&#39;500&#39=
;000*COIN or similar,<br>
=C2=A0 =C2=A0 but leave premine_block_hash=3D0<br>
<br>
=C2=A0b) build the node software, and mine block 1 to the premine address.<=
br>
<br>
=C2=A0c) set premine_block_hash to block 1&#39;s hash. publish the code wit=
h the<br>
=C2=A0 =C2=A0 genesis block and block 1 hash, so that the public can mine a=
s of<br>
=C2=A0 =C2=A0 block 2.<br>
<br>
=C2=A0d) once 100 blocks have been mined, split the premine up amongst<br>
=C2=A0 =C2=A0 devs, faucets, wallet maintainers, user groups, a managed end=
owment<br>
=C2=A0 =C2=A0 for future testers, whatever.<br>
<br>
On Fri, May 09, 2025 at 03:07:48PM +0200, Garlo Nicon wrote:<br>
&gt; Why hard-forking anything? The starting difficulty is set to 1, and it=
<br>
&gt; raises to 4 almost instantly, when testnet creators are mining the fir=
st<br>
&gt; coins. Which means, that difficulty 1 is ridiculously easy to work wit=
h,<br>
&gt; when you have any ASICs. If you combine it with the idea of fake<br>
&gt; timestamps,<br>
<br>
It&#39;s not the number of blocks, but the cumulative work that matters, so=
 to<br>
have a soft reset of testnet3 or testnet4 you&#39;d need to apply more hash=
ing<br>
for the new chain than the existing chains have already received. That&#39;=
s<br>
a fair amount of &quot;wasted&quot; hash: I think mining a more-work chain =
than<br>
testnet4 would require about the same amount of hash that it would take<br>
to mine ~13 mainnet blocks at the current difficulty, so you&#39;d be givin=
g<br>
up about $4M USD in mainnet block rewards to do it.<br>
<br>
In any event, a hard fork is &quot;necessary&quot;, as otherwise whenever i=
t<br>
takes 20 minutes or more to find a block, old clients will expect a<br>
lower difficulty than new clients do, so the two wouldn&#39;t be compatible=
<br>
with each other. You could do various things to work around that, but<br>
that&#39;s a lot of coding time that could be better spent on improving<br>
things relevant to mainnet, and if you&#39;re resetting the chain anyway,<b=
r>
there&#39;s not much advantage to it.<br>
<br>
&gt; then you can produce a really long initial chain, which will<br>
&gt; start in 2009, and up to 2025, it will produce almost the same amount =
of<br>
&gt; blocks as mainnet.<br>
<br>
A soft fork of testnet3 would start 3rd Feb 2011 (leading to about 750k<br>
blocks vs mainnet&#39;s ~900k), and a soft fork of testnet4 would start at<=
br>
4th May 2024 (leading to about 54k blocks). (These are the timestamps<br>
of the respective genesis blocks)<br>
<br>
A disadvantage of doing a premine that way is that users of the chain<br>
need to download and validate thousands of blocks and deal with an equal<br=
>
number of utxos just to establish the premine; doing that in a single<br>
block with a single utxo (or one utxo for each recipient of the premine)<br=
>
is quite a bit more efficient.<br>
<br>
&gt; Which means, that instead of &quot;premine&quot;, you can use &quot;ni=
nja-mine&quot;, and<br>
&gt; achieve pretty much the same end result.<br>
<br>
I think in general usage &quot;premine&quot; covers both those approaches -=
- any<br>
time the creator(s) of a chain gets the opportunity to claim/distribute<br>
coins prior to the general public being able to mint new coins by mining<br=
>
blocks, that&#39;s a premine.<br>
<br>
Cheers,<br>
aj<br>
</blockquote></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAN7kyNgNowuB0Cr%3DcvC91QOgmUVXiawFzRgrPDENg0i2UUD%2BXQ%40mail.g=
mail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
d/msgid/bitcoindev/CAN7kyNgNowuB0Cr%3DcvC91QOgmUVXiawFzRgrPDENg0i2UUD%2BXQ%=
40mail.gmail.com</a>.<br />

--000000000000a2b3390639271564--