path: root/95/9816f9d80c69e2de76cd74ee967633165e4307

Delivery-date: Sat, 17 May 2025 02:26:50 -0700
Received: from mail-ot1-f57.google.com ([209.85.210.57])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC7YL44NVYFRBTFMUHAQMGQEUAFWMUY@googlegroups.com>)
	id 1uGDoc-0003NQ-7F
	for bitcoindev@gnusha.org; Sat, 17 May 2025 02:26:50 -0700
Received: by mail-ot1-f57.google.com with SMTP id 46e09a7af769-72c40592a9asf2219368a34.2
        for <bitcoindev@gnusha.org>; Sat, 17 May 2025 02:26:46 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1747474000; cv=pass;
        d=google.com; s=arc-20240605;
        b=PjUcVlZlYUROngAmzl+egemeHgOjfqMYd0JqmFPW8acx/Yyc0BWvXNwoGyFe7jzYeA
         p7dmIlgHvxY1Vaa4WEEEL2jQxkF53nR/AeOAAOT96lRiXjPlx073f+DvQjGaY1AxnaU9
         sf9KTKCGzGsccj7j9sS63aWoCqLvuOvOJPMWt4Lfiont2xQHA0MXSzHjbLYYJORL04e+
         CqRAgFnpoG41Jc4FuhBcSv7qQJ6kl/+L9GHVBdlasorPaje0xbjH7QHEjaH0ojkqHk/c
         EeEEigN5lYDQTOripEHo3mDdVxAq/kmyJzriWhg6UmikghxZsaKKBrbnKuCvmUDNjVYG
         ofUA==
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=5SjwpqCd7l8vaXdqDCG3wJBUMBWwN+x/qIJt9pjRZg8=;
        fh=gwtM2vA/CEnTVx2BrZskk3BVQJOxIwIKWzciO9SU76Y=;
        b=VyPZEPQsl7CU1s20TqWD+FBni8GtrWnGrzuR+eIDjmlFYmcKvYmY5I3aazk4hh90eP
         g9waRd6XHOYhRQuYtcoLO1sn9XBzzyOeEXm87nrZx/5Rd99/h3oq2oOyClXVe2RyJO3A
         qyBy8LPa9hQX0HsBxshlzO1GZY7qmteCzwMLI15px6KrQU4+XV2fsncBNdCbDV7wp24k
         6fHnMeOXy1QvKkzWquCHug1x8vwR03wHgT7AC+DWn79Vkx7y1sB0I0z0o5Qh1QjPGzSK
         qqu+6qnatBt2ZCATqsQ0c+qj/3M/NTbY0M8/G7F7VjFRWGd/odxyqmCZz+CVtocYzLXQ
         7bYw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=hKn0Od9S;
       spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::52b as permitted sender) smtp.mailfrom=saintwenhao@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=1747474000; x=1748078800; 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=5SjwpqCd7l8vaXdqDCG3wJBUMBWwN+x/qIJt9pjRZg8=;
        b=NcCNmHGbOjFQJox+SnRhaRK7IMypmhSVUEoGTIwoybONLTenYGjDgoZWrAUkESdoHK
         3HT8rcsxCPNlB8wSxZ087DotuFWTGFtDJFSqFf3T8ZUaVlKwxGbJqDjusfTGIQ3DfkMc
         nL35EIc3j+cRy7WludrWtIkK9a9LeN5+XlNmzMjp8msEuf9xrffSFeRvZgUkeeC6cWk+
         ENBaWU2SVMqwDKYRNAp8lrttf1AuB9rAqb/uubKUqGfXb88mSb7HpoHMmpEVKyJcZY/s
         IXO+5kyjDaBa4tlYcZ0UtXmBAg0pMlXutdFp1f593MvgV2Qgvoa5BRdyP93Fwdpk65pv
         Ebpw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747474000; x=1748078800; 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=5SjwpqCd7l8vaXdqDCG3wJBUMBWwN+x/qIJt9pjRZg8=;
        b=JDFeHgC75HQDOEzcMAYaiv5CBdsGzEn1Vz94PQ6wj9qMii7FAlzQ2JjUpb3LG0B6Fp
         yJ0K83Y4jS7ND3iYFwIKjhR9hz4/DlHN2VL1gi1Ayj7Vr84seUHNw5MxExBTQhsspGN2
         YOKtxTZ9elPszZN7zyovlmBFTzov1BnUf2yTVs78thAGl2JHUtIwPzMKXNNKx+TgfKIg
         bPh+8FunKMxEzIO3AMPpWh+ghsvF5yYRGWgvVG5WMI1YJStTHQ6fLxtbIxPEtYZkPH+Z
         FhQ9WFfvFtnaYfQz7iG/29S1nIOgH2WY1GedJKgxdivtFTcgBvrFcx/drQ+xYpfdF1Ob
         eKOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747474000; x=1748078800;
        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=5SjwpqCd7l8vaXdqDCG3wJBUMBWwN+x/qIJt9pjRZg8=;
        b=Z8IzdoO4qXI5Ro1Qzw383rxs1zr8wvlaMM+CMP5jNlKcmk+g95s8qu9AtsTzv6Lt8q
         I7LT5NLZIAIsOUlQT+1bkoO6cNGS5FXpE+HETJc0ImV2lnwK/XHNxMiaFX70Yt6UBxP0
         uhB/l2GcGXClVCI07t8V1tc+NoR1xoyZ1SeUC6UC+DmWSIU1PeB8RVzdq+ZUAZ6vjtRZ
         8YBEtfF5yqAC5ti5y3/WrzqkGKqiZZCfhsTzT/mXraj2bKacefTJ9biIJ1HKCOTevAG9
         NKuynmno3oAkM4wdc5/lgGhujJU+YFysay4XDmCXqW1JfKRUpB06T2tzijkKnAlKuXbR
         wbOA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVPk4Xm5xAnBlLmXWiApymip1hbGKXyVAuquvs9+/NOjYESiOSVXx8QieU6vPLC1rqHWy1nZObrtJKk@gnusha.org
X-Gm-Message-State: AOJu0YxVUf5PujQ39LkC3OElbrab83oXtzZA/fUshjemCxkvJAQBmybZ
	EAiS1qe+EUDSeT9ABIcuyl2gBAtnJawOLK6Bu1F9LxkcHIlZdMmsJVUO
X-Google-Smtp-Source: AGHT+IG7VpMiQrRxDOABjNro7FuKLf4gT1dq65LpQ0t20IyAc+e/yHGh0Sz7p65Xi0tfn74IfZgm3A==
X-Received: by 2002:a05:6820:1896:b0:603:f903:c85a with SMTP id 006d021491bc7-609f3736881mr3258256eaf.4.1747473999951;
        Sat, 17 May 2025 02:26:39 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBFkI9eNDmXRmGJBbDBY3QsgDjDsUhNsnjkWBRvzxpMk1A==
Received: by 2002:a4a:cb99:0:b0:60a:248:c91 with SMTP id 006d021491bc7-60a02480f3bls13948eaf.0.-pod-prod-02-us;
 Sat, 17 May 2025 02:26:36 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCVaiFteURbewcxuJD7taslR6hEhSz6XXK2N7uIxQH9wXy5kfmPLGOJvorH2kgowl3ef99YaVG2Q/WU3@googlegroups.com
X-Received: by 2002:a05:6808:229f:b0:403:34b3:c987 with SMTP id 5614622812f47-404d87b8b34mr3395878b6e.28.1747473996243;
        Sat, 17 May 2025 02:26:36 -0700 (PDT)
Received: by 2002:a05:600c:c7:b0:442:dc76:9493 with SMTP id 5b1f17b1804b1-442fe658211ms5e9;
        Fri, 16 May 2025 22:11:28 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCVEoPnkVnldvXIR75c21h74RBeI4Fy9wIUm4U0OKdDk20FodsePunX1hBl42OpVrAzFZr4k8DC/+uGO@googlegroups.com
X-Received: by 2002:a05:600c:a014:b0:43d:ac5:11ed with SMTP id 5b1f17b1804b1-442fd66f08emr57623185e9.24.1747458686015;
        Fri, 16 May 2025 22:11:26 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1747458686; cv=none;
        d=google.com; s=arc-20240605;
        b=bwSWYEZjKDaxRcvbOfcIeMvfHf4/xPrDG/Vk89OZ3+DP7OuvMfgECRB7G826KAFS7Z
         KZoGWTMNpTvM2VBzz86wqsLV50BAZr6XCvhzKXT5zDAAZqGKT492f0F/qCKTfa3Gv/6a
         l2Usdn3Ou6R8ij4V0n3T1hgpgMbrvKyc6Fg1jMjBnF7Ld7huxnerCAEKEaDR8scn2yGN
         aTyq44JaK0JBjc4R/4MGJyV7BbHBRNOCBV/Ehll43RwnjKVhU/6QLGZZnl87cQpTF0xv
         CA/4IabkLw4rXK+GnEnQXXUJVln+v4NQYMiuYOpWp+gOtK1wDMtfoOdDUkpZwvimRQtW
         UMTQ==
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=dmXd22XnROtwKwWfKfZBiNHXmihEfyfoHT0Vz7TFtNE=;
        fh=RBLEV1l7SWW92r31hiDtI1Vf5NfZMpV0k3WhV+5yv9w=;
        b=RRvBMsN77xtAjG5INmjir9KGxFp0LX3kWtQptTHQnakQ93pZgvdXJmZtMjyYYrS6+T
         z8T12lo4yaKNHQaQC6wlncSqb6rxSQayQAlJFGSIfK3DFWBIzTi3MkWiNqBzQzLTHr94
         ukYNRh9485JR262IoIVnGV0tDJz4pkQKf/p+vxaqkLVPDwbCTU86ePTJWwXVAKxWFno4
         edfgocc+4cdj7A35uT2IHCsdYJt5A+w/HqSXrVUQrNH8urEgcxx1QGuPOuYsPbRKggMw
         3KVZrDD0gf4/RKUbJwvdgoSsLBqIQcbNtApv7UdABF/YT5sFdhly+GOc634Lk9b4vFjr
         P9rg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=hKn0Od9S;
       spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::52b as permitted sender) smtp.mailfrom=saintwenhao@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com. [2a00:1450:4864:20::52b])
        by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-442eda1c0c5si3516635e9.1.2025.05.16.22.11.25
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 16 May 2025 22:11:25 -0700 (PDT)
Received-SPF: pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::52b as permitted sender) client-ip=2a00:1450:4864:20::52b;
Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-6015f8d4b7dso2231832a12.1
        for <bitcoindev@googlegroups.com>; Fri, 16 May 2025 22:11:25 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCXOgn52KO9uVbIMoYj+2RVgYJvfuoe+WKxIrSVq42yGNJHbnpIzaRxb0SswEEwTsCK8oG4aiWDH9uRJ@googlegroups.com
X-Gm-Gg: ASbGncvl2xY0JLKUMka8336BAgQvJxu0/924uX2GmS07d5yoCPwO4KpPDWl6QoYnPlJ
	q5w40OM+WKXwmKCx6w5bess5pQVA9of+fOlkoHtziNIbP/1iDgfcgZPGeP7mfNPmdYFJMiMSHfd
	xbhTrK22V0v4+E3OoZZHI81Lww2Mxnjtpl
X-Received: by 2002:a05:6402:4309:b0:601:a35e:6dee with SMTP id
 4fb4d7f45d1cf-601a35e715cmr624628a12.33.1747458684900; Fri, 16 May 2025
 22:11:24 -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>
In-Reply-To: <aCGFXI4PRq_eyrEf@erisian.com.au>
From: Saint Wenhao <saintwenhao@gmail.com>
Date: Sat, 17 May 2025 07:11:13 +0200
X-Gm-Features: AX0GCFtiXFRllyk3tzUvHo_iDWtFXnDISZf8JGBLFEc2d9rDGI-R-AHQTGBCr5k
Message-ID: <CACgYNOJN8ZJEutL75HZz-KcbpJfMdDrODm8qDrcNDFOE7U-J9A@mail.gmail.com>
Subject: Re: [bitcoindev] Re: Unbreaking testnet4
To: Anthony Towns <aj@erisian.com.au>
Cc: Garlo Nicon <garlonicon@gmail.com>, Greg Maxwell <gmaxwell@gmail.com>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000002c594d06354deea8"
X-Original-Sender: saintwenhao@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=hKn0Od9S;       spf=pass
 (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::52b
 as permitted sender) smtp.mailfrom=saintwenhao@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 (/)

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

> 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 in
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 chain.
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 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.

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-mined
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 i=
t

Well, the main advantage is that if someone is using some old client, then
that person can be forced to upgrade, if you send the new chain to the old
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 nodes
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 millio=
n
> > > 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 months
> (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 sim=
ilar,
>     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 firs=
t
> > coins. Which means, that difficulty 1 is ridiculously easy to work with=
,
> > 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 t=
o
> have a soft reset of testnet3 or testnet4 you'd need to apply more hashin=
g
> 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 o=
f
> > 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/=
CACgYNOJN8ZJEutL75HZz-KcbpJfMdDrODm8qDrcNDFOE7U-J9A%40mail.gmail.com.

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

<div dir=3D"ltr">&gt; I think mining a more-work chain than testnet4 would =
require about the same amount of hash that it would take to mine ~13 mainne=
t blocks at the current difficulty, so you&#39;d be giving up about $4M USD=
 in mainnet block rewards to do it.<br><br>If you want to have permissionle=
ss mining, then you don&#39;t care that much, when the chain will be reorga=
nized. If testnet5 blocks will be accepted in testnet4, but not vice-versa,=
 then eventually, it would be possible to share testnet5 chain with testnet=
4 nodes.<br><br>So, you don&#39;t have to reorg the whole network by yourse=
lf, 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.<br><br>Which means, that if=
 testnet4 would start with the same Genesis Block as testnet3, then it woul=
d take less than 13 years, to replace existing chain. And it is sufficient:=
 you don&#39;t have to reorg everything from day one.<br><br>&gt; In any ev=
ent, a hard fork is &quot;necessary&quot;, as otherwise whenever it takes 2=
0 minutes or more to find a block, old clients will expect a lower difficul=
ty than new clients do, so the two wouldn&#39;t be compatible with each oth=
er.<br><br>1. CPU-mined blocks can be treated just as &quot;weak blocks&quo=
t;, and always reorged.<br>2. You can always require a stronger block, than=
 &quot;nBits&quot; in block header, and it is still a soft-fork. For exampl=
e: 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 acce=
pted, but reorged, then at least in theory, it is possible to capture a giv=
en 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, then you can do that now: if you count confi=
rmations today, then you can simply accept-but-ignore CPU-mined blocks, and=
 have a network, where you only accept some transaction as &quot;confirmed&=
quot;, if it was ASIC-confirmed. Because any ASIC, at any point in time, ca=
n always smash hundreds of CPU-mined blocks, with just a single ASIC block.=
 The main reason, why they don&#39;t do that today, is that such changes we=
re not implemented in the official version, and many miners are unaware of =
their power, or don&#39;t have technical skills to do that.<br><br>&gt; and=
 if you&#39;re resetting the chain anyway, there&#39;s not much advantage t=
o it<br><br>Well, the main advantage is that if someone is using some old c=
lient, then that person can be forced to upgrade, if you send the new chain=
 to the old nodes. But if it is not worth it, then testnet5 can of course b=
e incompatible (but then, it would be a bit harder to convince some old nod=
es to upgrade; that&#39;s why we promote soft-forks in general, because the=
y are unstoppable).</div><br><div class=3D"gmail_quote gmail_quote_containe=
r"><div dir=3D"ltr" class=3D"gmail_attr">pon., 12 maj 2025 o 07:21=C2=A0Ant=
hony Towns &lt;<a href=3D"mailto:aj@erisian.com.au">aj@erisian.com.au</a>&g=
t; napisa=C5=82(a):<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">&gt; &gt; Hard fork in an ultramassive premine, as large as possible bu=
t 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>

<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/CACgYNOJN8ZJEutL75HZz-KcbpJfMdDrODm8qDrcNDFOE7U-J9A%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CACgYNOJN8ZJEutL75HZz-KcbpJfMdDrODm8qDrcNDFOE7U-J9A%40mail.g=
mail.com</a>.<br />

--0000000000002c594d06354deea8--