From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 ; 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: In-Reply-To: From: Saint Wenhao Date: Sat, 17 May 2025 07:11:13 +0200 X-Gm-Features: AX0GCFtiXFRllyk3tzUvHo_iDWtFXnDISZf8JGBLFEc2d9rDGI-R-AHQTGBCr5k Message-ID: Subject: Re: [bitcoindev] Re: Unbreaking testnet4 To: Anthony Towns Cc: Garlo Nicon , Greg Maxwell , Bitcoin Development Mailing List 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 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
> 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'd be giving up about $4M USD= in mainnet block rewards to do it.

If you want to have permissionle= ss mining, then you don'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.

So, you don'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.

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't have to reorg everything from day one.

> In any ev= ent, a hard fork is "necessary", 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't be compatible with each oth= er.

1. CPU-mined blocks can be treated just as "weak blocks&quo= t;, and always reorged.
2. You can always require a stronger block, than= "nBits" 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.

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.

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 "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'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't have technical skills to do that.

> and= if you're resetting the chain anyway, there's not much advantage t= o it

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's why we promote soft-forks in general, because the= y are unstoppable).

pon., 12 maj 2025 o 07:21=C2=A0Ant= hony Towns <aj@erisian.com.au&g= t; napisa=C5=82(a):
> > Hard fork in an ultramassive premine, as large as possible bu= t what stays
> > with existing value overflow logic. (so maybe an additional 21 mi= llion
> > testnet btc?).

The existing logic gives errors if:

=C2=A0 * a single input of a tx (ie a coin in the utxo set), or the sum of = inputs to
=C2=A0 =C2=A0 a txn, is outside the range 0-21M (bad-txns-inputvalues-outof= range)

=C2=A0 * a single output of a tx is outside the range 0-21M
=C2=A0 =C2=A0 (bad-txns-vout-negative or bad-txns-vout-toolarge)

=C2=A0 * the sum of the outputs of a single tx is outside the range 0-21M =C2=A0 =C2=A0 (bad-txns-txouttotal-toolarge)

=C2=A0 * the fee paid by a single tx is outside the range 0-21M
=C2=A0 =C2=A0 (bad-txns-fee-outofrange)

=C2=A0 * a block's fees go outside the range 0-21M
=C2=A0 =C2=A0 (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 th= e
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 i= n
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:

=C2=A0 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:

=C2=A0a) first define the chain, with a new genesis, etc; then set
=C2=A0 =C2=A0 nSubsidyHalvingInterval=3D105000 and premine=3D10'500'= ;000*COIN or similar,
=C2=A0 =C2=A0 but leave premine_block_hash=3D0

=C2=A0b) build the node software, and mine block 1 to the premine address.<= br>
=C2=A0c) set premine_block_hash to block 1's hash. publish the code wit= h the
=C2=A0 =C2=A0 genesis block and block 1 hash, so that the public can mine a= s of
=C2=A0 =C2=A0 block 2.

=C2=A0d) once 100 blocks have been mined, split the premine up amongst
=C2=A0 =C2=A0 devs, faucets, wallet maintainers, user groups, a managed end= owment
=C2=A0 =C2=A0 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 hash= ing
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 givin= g
up about $4M USD in mainnet block rewards to do it.

In any event, a hard fork is "necessary", as otherwise whenever i= t
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<= br> 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 "ni= nja-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

--
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/ms= gid/bitcoindev/CACgYNOJN8ZJEutL75HZz-KcbpJfMdDrODm8qDrcNDFOE7U-J9A%40mail.g= mail.com.
--0000000000002c594d06354deea8--