From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 ; 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: In-Reply-To: From: Garlo Nicon Date: Sat, 5 Jul 2025 06:31:18 +0200 X-Gm-Features: Ac12FXz0EcuDpARzBqQxKSbYcJw-YBwtef23oAjq9Jv6T7gFRkR3l86l6KJffME Message-ID: Subject: Re: [bitcoindev] Re: Unbreaking testnet4 To: Saint Wenhao Cc: Anthony Towns , Greg Maxwell , Bitcoin Development Mailing List 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 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 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
> 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 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.

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'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.

=
Another thing is, if someone doesn'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.

sob= ., 17 maj 2025 o 07:11=C2=A0Saint Wenhao <saintwenhao@gmail.com> napisa=C5=82(a):
> 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'd be giving up about $4M USD in mainnet block rewards to do i= t.

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

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

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

> In any event, a hard fork is "necessa= ry", 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't be compatible with each other.

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

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, 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 "confirmed", 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= 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't have te= chnical skills to do that.

> and if you're resetting the chai= n anyway, there's not much advantage to it

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

pon., 12 maj 2= 025 o 07:21=C2=A0Anthony Towns <aj@erisian.com.au> napisa=C5=82(a):
> > Hard fork in an ultrama= ssive premine, as large as possible but 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/msgid/bitcoindev/CAN7kyNgNowuB0Cr%3DcvC91QOgmUVXiawFzRgrPDENg0i2UUD%2BXQ%= 40mail.gmail.com.
--000000000000a2b3390639271564--