path: root/38/1fbf493f3a8c76c32797172de514e3586e69b4

Delivery-date: Wed, 14 May 2025 02:36:52 -0700
Received: from mail-qt1-f186.google.com ([209.85.160.186])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC7YL44NVYFRBKOISHAQMGQEWNMRP6Y@googlegroups.com>)
	id 1uF8Xj-0004cW-44
	for bitcoindev@gnusha.org; Wed, 14 May 2025 02:36:52 -0700
Received: by mail-qt1-f186.google.com with SMTP id d75a77b69052e-47693206d3bsf159955291cf.1
        for <bitcoindev@gnusha.org>; Wed, 14 May 2025 02:36:50 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1747215405; cv=pass;
        d=google.com; s=arc-20240605;
        b=fYCdQlvqj6iH5ITJgCzK6KIQeoX2HWDa7KbRbg6Ql9I2rDOEpD1yyFkvXEwH3dRx3l
         qqf7uJNO2Vj1yzTf8/hptctZT/UujZsweo3kYF3dQyp/FE8+CqEgOTOpJu8htw7tGZFj
         +L1Xi6GtHwhInRl4+a5aRh8cU6sTdPiYrs61+ZWbYkRMSwgyGP3+t56Jn+T1GFTajWOT
         TzJOZhRWz6KBBSelXHTIKSqnwFM6cSAca91B0Fi9eg0oo8YFB1lqBIIsXzVG35JuuoDR
         Qxj26mq0BKKMiN4zydSN2Dl1r4sMqQ+ysqnFao+NFi3/1QUU7w4zT94QUEJT7xZK6Qrr
         btuA==
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=htuAg0iCYXtSJa4fkVfiK/2ayYuhFVnv4IyyWOflKvw=;
        fh=qXUX31fX+LScKtNzX4wdGhAc9DGtZ49FraVtc8FYFoM=;
        b=NbzKG2pZYoYzbCyhywr3j0fIXAOw2VE/NGUsvfaB1t+KDtA7yljEIUHgjwWNE8tiLe
         4b2d+unu1kpVWHH/qN6ZsWgKrxzkk3vi/BbCtHptHgjYB5vXOYweufOh9EBpmskmQvmV
         OHL3yoaB14EytTVc0E8SD8cmQwf70/kpOdkdI10/ymq8bLT5niCr/DbcQvCkzFUY42t/
         3jfCoeECgNKRTsj+egP/0akJhXOcpF9EX0jCk0j816aGUUGzUNf0BZ7hI8inGKGXRtat
         D6yZls1JQDAmTqIyUTH16Xi9XOVkNSq5Zb6wC1DUyDmtXO+r/Rwbcm1zlgo+GyQLIuwB
         ok/A==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=BRzfzkeh;
       spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::52d 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=1747215405; x=1747820205; 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=htuAg0iCYXtSJa4fkVfiK/2ayYuhFVnv4IyyWOflKvw=;
        b=gF6wRZvQ4Uvczimc2Ma31Y5WARS7jF8YIk5PQ1vfEQDf+COVEQuwA9FIjFFGbkmMwm
         pYD2ccIOWBUuUqqmc5Vx3XJQdHOlteyjrorfRYcsUtZJaJba+scMlSczKuyBsEMH0Y5g
         tKXTkUZRFMnGUTb1QfcKUjWXuUFzHlGZB2b6/eTZ+SClMNswCJljuZMTATM/3AvdP8mj
         WqKjrtidDq7FZDPaz7eqQ1ElmIYnvIxL7gzpCPT2ltB2TxAG0pwdf1BikkL5kOAgFuDZ
         tOdDlwbQw787+de8cgc0+u8GpBkgZPXjMJTnH19D65oUJAOW6czNDUd/hO29bBfDHIO2
         D8OA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747215405; x=1747820205; 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=htuAg0iCYXtSJa4fkVfiK/2ayYuhFVnv4IyyWOflKvw=;
        b=Ad62a18QhfDhe4TIhdkZyoUAu3aWmiPm7M4ZBApoRBLFNOZv/TaqceiAfG+RjREPIZ
         q2q9gvIvdHxb3YdfcIZLmGavLmbTTURkkiatw2wG7oHUxFkcqi7ftYNpegpWqMpnQskB
         HnJzfbRR1HXJy7/d0AvMkNyz/bbYNzGHRylxX6gXcA8PZTqTG39Q03bHYwffoQB1r97Z
         ZkGv9kG9P9p5ghNVymwhIZkJHbpsY6R0MhiI+nhodMtn2ej9t4CnWXY0Snb5h/Gqmkbm
         RUhquXNc7fN/190+zKSEnF++WRWDgJutM1/Z0AjsskEriYnkomsobm5cLkVmag866bkg
         0X5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747215405; x=1747820205;
        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=htuAg0iCYXtSJa4fkVfiK/2ayYuhFVnv4IyyWOflKvw=;
        b=tD4zAwex9qHnahhKRv2UjrVIK+i6mcgbsva97WD2Vqh/YH8jtTV7tRsLlTZaCCADi9
         8FRb+wyIc907lD58nALBr3vRybCm1jDaZmWvPemnAJXC3NdYLCf88bWQ9pPjYUXL3wuS
         +1U7U+WedFBOAxqGPAkmiKbJqNLLyLR2lOzxl+g7ngi9uEVdyd9xFjKxL99x/almEuh0
         7hwag+cswVDRXsfrWOmv8bTjKm6mdV9OUduUKLVKqISzparhjoz03pMdSmMnj4Tikhde
         6FuC0h3tN+w/FTh05tJifqxHD+8f6XskJN85L7uZdL400MelPy8JuX0xUo55JGDma2+z
         oA5Q==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVFu8+9awYqG4LiVfflZ7IEUtG9L1TM8uG1kDPIMArYPFji/BOP3l4HTHDr4moo4tRhlLAy4cD99ybK@gnusha.org
X-Gm-Message-State: AOJu0YwB0CTBsOwqKAFBjF4LPUcTD/k+afePKkrLYdURmsHI89WeTR8j
	8Cc7pJATZc7YAuPak/4p2p5uf3FVBrFSuivrwg82FPhH+JjK2VAg
X-Google-Smtp-Source: AGHT+IFXL7pDXmCuc3dbpICheJmQIgTvVhOt0MDNGVeY3FK7lM/lsfQSlnYD2LNZ+2BAaETFKHWnAA==
X-Received: by 2002:a05:622a:424f:b0:48a:2a08:cbee with SMTP id d75a77b69052e-49495d1c63fmr46337641cf.47.1747215404931;
        Wed, 14 May 2025 02:36:44 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBFAkER30tJCsp9tkrvi+5WB9ZpgtfXlOvfPCmTxk9lUYA==
Received: by 2002:a05:622a:8030:b0:494:7b0d:ba8c with SMTP id
 d75a77b69052e-4947b0dbaa4ls51601531cf.1.-pod-prod-06-us; Wed, 14 May 2025
 02:36:41 -0700 (PDT)
X-Received: by 2002:a05:620a:28c7:b0:7c5:a423:f5b0 with SMTP id af79cd13be357-7cd287f8f3dmr388111285a.7.1747215401083;
        Wed, 14 May 2025 02:36:41 -0700 (PDT)
Received: by 2002:a05:600c:1d96:b0:442:dc76:9493 with SMTP id 5b1f17b1804b1-442dc769537ms5e9;
        Mon, 12 May 2025 11:18:01 -0700 (PDT)
X-Received: by 2002:a05:600c:8284:b0:43c:fa52:7d2d with SMTP id 5b1f17b1804b1-442d6dd2478mr102760115e9.20.1747073879153;
        Mon, 12 May 2025 11:17:59 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1747073879; cv=none;
        d=google.com; s=arc-20240605;
        b=flEGANFE1zVdbryKCrp3SMF56QXD/HtZrOWczYtcHmu0MQzGoslHGhzQKGWIv8f8uh
         kw1KTNhtE7Bid3PyYWzbipsHJqo5V08rbg6+mb0rcc8IjcTNJwF1JZhK7rrtx6vDBZFc
         h0hW5ItEGp5MZ8dPlHEhEgE1+OKr4vueZK6LiHE8c4B17VscHN54KvKunZ5EcLvc1/4p
         UmW4RPLmwQKqSAB2/WuQUcy8Mw8d9Gd6Tmn1QhaWeKACmGfC8m0U5gVjR5UAZ1yZNbId
         HGlTcbizIxtgIIUH6FJM0HeH0SdQXzPXhUxPDhknx58teKZSNsFom1eKJfOZJANEDxme
         z0QQ==
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=iUg7zKFR9+aPAn4y80YIiugmhoQOMdzIdKsIQbQSqBc=;
        fh=CsEUNJ5L4/CRHemyOmorbj1EDejUhRw9KbwQMGJ2wEQ=;
        b=BF0RXKO3+VF9P1n5BCAD4u5WMJxIJsYgKlszBWpuHgQIN0O4cslCSwACJtMw4X2iua
         fP9mrqdDThBvFgbVIXrH91H5pOov3zo/mmX77Uru4F4zB7i6gL2YxEOS3g907RjQB7Em
         LnLCwLkD32DpUCLcIsKHXdXfGa1xTP6HV2+pdv8bxByYCbXDOI+ZeWRMfw37biYV6MIs
         i6qSV5o62jF1Igf0u3MFGy5qVtly0LsbRVjLp/FnStn1MXaoTqUGWlnT5os1pOQD8UK7
         EGR3vDT7qIkubmUIOwFlAh52PUqzBBTjs7aaZaq/1JgfsB3wnyZeHumSFxa+RAyIp0/m
         FmiA==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=BRzfzkeh;
       spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::52d 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-x52d.google.com (mail-ed1-x52d.google.com. [2a00:1450:4864:20::52d])
        by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-442d76b86d6si3612465e9.0.2025.05.12.11.17.59
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Mon, 12 May 2025 11:17:59 -0700 (PDT)
Received-SPF: pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::52d as permitted sender) client-ip=2a00:1450:4864:20::52d;
Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-5fcab0243b5so5494077a12.1
        for <bitcoindev@googlegroups.com>; Mon, 12 May 2025 11:17:59 -0700 (PDT)
X-Gm-Gg: ASbGncu28DcFJNHtNTugGcWlLQ2rL2DlqJDq+iuh2iew4NoJzP9bIHi9smYMDIk1BHj
	QKC/4cS+IGSGPpuqxfuOrdi/3VVObCW49jg5neSRQbt3BIh+isfVAXKMbudpjS/o9ODVeKi0+F6
	m+FiXMT7S1NSQo42PK/o8RwyRZZh5nZzbi
X-Received: by 2002:a05:6402:5194:b0:5f8:cf9b:d896 with SMTP id
 4fb4d7f45d1cf-5fca076064bmr11933278a12.12.1747073878286; Mon, 12 May 2025
 11:17:58 -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>
 <20250512110323.B14F27C0B49@smtp.postman.i2p> <20250512120531.1AC1F7C0557@smtp.postman.i2p>
In-Reply-To: <20250512120531.1AC1F7C0557@smtp.postman.i2p>
From: Saint Wenhao <saintwenhao@gmail.com>
Date: Mon, 12 May 2025 20:17:47 +0200
X-Gm-Features: AX0GCFth3Za9vXakkyUy9irnh7Mx2k24Vxtw6qumyUQEpln6FMRRPkIUnp4C3fs
Message-ID: <CACgYNO+kKOenBUykQr3foEqW9vdkMsPTdrBFfCgy4SjDKbc74A@mail.gmail.com>
Subject: Re: [bitcoindev] Re: Unbreaking testnet4
To: pithosian <pithosian@i2pmail.org>
Cc: bitcoindev@googlegroups.com
Content-Type: multipart/alternative; boundary="000000000000e965cb0634f45541"
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=BRzfzkeh;       spf=pass
 (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::52d
 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 (/)

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

> Updating the entire UTXO set all at once would be pretty expensive,

Not only that. It may also invalidate timelocked signatures, which would be
made around "halving". So, if you would sign something, when block height
will be set to 209,990, and timelock it into 20 blocks, then at block
height 210,010, it would be invalid, because of incorrect amount.

Which means, that stored UTXO amounts should be probably left untouched,
but rather spendability of the coins should be affected. So: if someone
received 50 tBTC, then that person should be able to freely move 25 tBTC
anywhere, but 25 tBTC can be enforced to go directly into transaction fees
(and so on, and so forth, so later it would be splitted into 12.5 spendable
tBTC, and 37.5 tBTC fees).

And then, that kind of fees can be claimed directly by miners, or can be
simply burned, by just not claiming it, if you want to permanently throw it
away from the UTXO set, without leaving any trace.

pon., 12 maj 2025 o 15:50 pithosian <pithosian@i2pmail.org> napisa=C5=82(a)=
:

> Another option is to invert the halving logic on testnet (to what some
> newbies occasionally think the halving is on mainnet); don't halve the
> subsidy, half the existing supply.
>
> Fix the subsidy:
> validation.cpp
>   CAmount GetBlockSubsidy(int nHeight, const Consensus::Params&
>   consensusParams) { if (consensusParams.fixedSubsidy !=3D 0) {
>       return consensusParams.fixedSubsidy;
>     }
>
> Then as the last step of processing a block, after its txs have been
> applied to chainstate, check if it's a halving block and, if it is
> (and some consensus flag is set), halve the value of all existing UTXOs.
>
> The result is:
> 1. We'd never exceed a 21m coins.
> 2. We'd disincentivise hoarding.
> 3. We'd ensure permanent liquidity on testnet.
>
> Updating the entire UTXO set all at once would be pretty expensive,
> though, and over enough halvings you'd have a bunch of zero value UTXOs
> we may or may not be able to clean up.
>
> On Mon, 12 May 2025 11:03:23 +0000 (UTC)
> Anthony Towns <aj@erisian.com.au> wrote:
>
> > > > Hard fork in an ultramassive premine, as large as possible but
> > > > what stays with existing value overflow logic. (so maybe an
> > > > additional 21 million 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
> > similar, 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 first 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 to have a soft reset of testnet3 or testnet4 you'd need to apply
> > more hashing 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
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/20250512120531.1AC1F7C0557%4=
0smtp.postman.i2p
> .
>

--=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/=
CACgYNO%2BkKOenBUykQr3foEqW9vdkMsPTdrBFfCgy4SjDKbc74A%40mail.gmail.com.

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

<div dir=3D"ltr">&gt; Updating the entire UTXO set all at once would be pre=
tty expensive,<br><br>Not only that. It may also invalidate timelocked sign=
atures, which would be made around &quot;halving&quot;. So, if you would si=
gn something, when block height will be set to 209,990, and timelock it int=
o 20 blocks, then at block height 210,010, it would be invalid, because of =
incorrect amount.<br><br>Which means, that stored UTXO amounts should be pr=
obably left untouched, but rather spendability of the coins should be affec=
ted. So: if someone received 50 tBTC, then that person should be able to fr=
eely move 25 tBTC anywhere, but 25 tBTC can be enforced to go directly into=
 transaction fees (and so on, and so forth, so later it would be splitted i=
nto 12.5 spendable tBTC, and 37.5 tBTC fees).<br><br>And then, that kind of=
 fees can be claimed directly by miners, or can be simply burned, by just n=
ot claiming it, if you want to permanently throw it away from the UTXO set,=
 without leaving any trace.</div><br><div class=3D"gmail_quote gmail_quote_=
container"><div dir=3D"ltr" class=3D"gmail_attr">pon., 12 maj 2025 o 15:50=
=C2=A0pithosian &lt;<a href=3D"mailto:pithosian@i2pmail.org">pithosian@i2pm=
ail.org</a>&gt; napisa=C5=82(a):<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">Another option is to invert the halving logic on testnet (=
to what some<br>
newbies occasionally think the halving is on mainnet); don&#39;t halve the<=
br>
subsidy, half the existing supply.<br>
<br>
Fix the subsidy:<br>
validation.cpp<br>
=C2=A0 CAmount GetBlockSubsidy(int nHeight, const Consensus::Params&amp;<br=
>
=C2=A0 consensusParams) { if (consensusParams.fixedSubsidy !=3D 0) {<br>
=C2=A0 =C2=A0 =C2=A0 return consensusParams.fixedSubsidy;<br>
=C2=A0 =C2=A0 }<br>
<br>
Then as the last step of processing a block, after its txs have been<br>
applied to chainstate, check if it&#39;s a halving block and, if it is<br>
(and some consensus flag is set), halve the value of all existing UTXOs.<br=
>
<br>
The result is:<br>
1. We&#39;d never exceed a 21m coins.<br>
2. We&#39;d disincentivise hoarding.<br>
3. We&#39;d ensure permanent liquidity on testnet.<br>
<br>
Updating the entire UTXO set all at once would be pretty expensive,<br>
though, and over enough halvings you&#39;d have a bunch of zero value UTXOs=
<br>
we may or may not be able to clean up.<br>
<br>
On Mon, 12 May 2025 11:03:23 +0000 (UTC)<br>
Anthony Towns &lt;<a href=3D"mailto:aj@erisian.com.au" target=3D"_blank">aj=
@erisian.com.au</a>&gt; wrote:<br>
<br>
&gt; &gt; &gt; Hard fork in an ultramassive premine, as large as possible b=
ut<br>
&gt; &gt; &gt; what stays with existing value overflow logic. (so maybe an<=
br>
&gt; &gt; &gt; additional 21 million testnet btc?).=C2=A0 <br>
&gt; <br>
&gt; The existing logic gives errors if:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0* a single input of a tx (ie a coin in the utxo set), or t=
he sum of<br>
&gt; inputs to a txn, is outside the range 0-21M<br>
&gt; (bad-txns-inputvalues-outofrange)<br>
&gt; <br>
&gt;=C2=A0 =C2=A0* a single output of a tx is outside the range 0-21M<br>
&gt;=C2=A0 =C2=A0 =C2=A0(bad-txns-vout-negative or bad-txns-vout-toolarge)<=
br>
&gt; <br>
&gt;=C2=A0 =C2=A0* the sum of the outputs of a single tx is outside the ran=
ge 0-21M<br>
&gt;=C2=A0 =C2=A0 =C2=A0(bad-txns-txouttotal-toolarge)<br>
&gt; <br>
&gt;=C2=A0 =C2=A0* the fee paid by a single tx is outside the range 0-21M<b=
r>
&gt;=C2=A0 =C2=A0 =C2=A0(bad-txns-fee-outofrange)<br>
&gt; <br>
&gt;=C2=A0 =C2=A0* a block&#39;s fees go outside the range 0-21M<br>
&gt;=C2=A0 =C2=A0 =C2=A0(bad-txns-accumulated-fee-outofrange)<br>
&gt; <br>
&gt; Keeping the total supply under 21M seems nicer than having txs that<br=
>
&gt; spend real utxos be able to hit these errors (eg, by combining<br>
&gt; the premine utxo at 21M with a coinbase reward of 50 and hitting<br>
&gt; bad-txns-inputvalues-outofrange).<br>
&gt; <br>
&gt; That&#39;s pretty easy to achieve: just have the initial premine be ha=
lf<br>
&gt; the supply (eg), and also cut the halvening time in half (so 10.5M<br>
&gt; premine, 105,000 blocks in a halving). Or you could have halvenings<br=
>
&gt; every 6 months (26250 blocks), and have an 18.375M premine, or<br>
&gt; whatever.<br>
&gt; <br>
&gt; You could also consider premining (almost) the entire supply, and have=
<br>
&gt; the block reward be entirely fees (almost) immediately after that,<br>
&gt; but I think there&#39;s value in making it possible to obtain coins fo=
r<br>
&gt; testing in a permissionless, anonymous and relatively low-latency<br>
&gt; manner, for which PoW is great. Might also be annoying for empty<br>
&gt; blocks to pay a reward of exactly 0, so if miners included their<br>
&gt; address in the coinbase tx like normal, they&#39;d be creating a 0 val=
ued<br>
&gt; utxo, and probably never spend it.<br>
&gt; <br>
&gt; I had a quick poke at what code to allow for chains with premines<br>
&gt; might look like here:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0<a href=3D"https://github.com/ajtowns/bitcoin/commits/2025=
05-premine/" rel=3D"noreferrer" target=3D"_blank">https://github.com/ajtown=
s/bitcoin/commits/202505-premine/</a><br>
&gt; <br>
&gt; About 11 lines of code to implement the logic.<br>
&gt; <br>
&gt; If this approach made the testnet difficulty reset logic obsolete<br>
&gt; (ie, a testnet with just PoW and a premine turns out to work fine),<br=
>
&gt; that would drop 14 lines of code for the fPowAllowMinDifficultyBlocks<=
br>
&gt; and enforce_BIP94 logic. Presumably a PoW-only testnet could also have=
<br>
&gt; its min-difficulty bumped from 1 to 65536 or more, since it seems like=
<br>
&gt; a single Bitaxe can still maintain the chain at that difficulty.<br>
&gt; <br>
&gt; The idea of this approach is that when establishing a premined<br>
&gt; testnet, you would:<br>
&gt; <br>
&gt;=C2=A0 a) first define the chain, with a new genesis, etc; then set<br>
&gt;=C2=A0 =C2=A0 =C2=A0nSubsidyHalvingInterval=3D105000 and premine=3D10&#=
39;500&#39;000*COIN or<br>
&gt; similar, but leave premine_block_hash=3D0<br>
&gt; <br>
&gt;=C2=A0 b) build the node software, and mine block 1 to the premine addr=
ess.<br>
&gt; <br>
&gt;=C2=A0 c) set premine_block_hash to block 1&#39;s hash. publish the cod=
e with<br>
&gt; the genesis block and block 1 hash, so that the public can mine as of<=
br>
&gt;=C2=A0 =C2=A0 =C2=A0block 2.<br>
&gt; <br>
&gt;=C2=A0 d) once 100 blocks have been mined, split the premine up amongst=
<br>
&gt;=C2=A0 =C2=A0 =C2=A0devs, faucets, wallet maintainers, user groups, a m=
anaged<br>
&gt; endowment for future testers, whatever.<br>
&gt; <br>
&gt; On Fri, May 09, 2025 at 03:07:48PM +0200, Garlo Nicon wrote:<br>
&gt; &gt; Why hard-forking anything? The starting difficulty is set to 1, a=
nd<br>
&gt; &gt; it raises to 4 almost instantly, when testnet creators are mining=
<br>
&gt; &gt; the first coins. Which means, that difficulty 1 is ridiculously<b=
r>
&gt; &gt; easy to work with, when you have any ASICs. If you combine it wit=
h<br>
&gt; &gt; the idea of fake timestamps,=C2=A0 <br>
&gt; <br>
&gt; It&#39;s not the number of blocks, but the cumulative work that matter=
s,<br>
&gt; so to have a soft reset of testnet3 or testnet4 you&#39;d need to appl=
y<br>
&gt; more hashing for the new chain than the existing chains have already<b=
r>
&gt; received. That&#39;s a fair amount of &quot;wasted&quot; hash: I think=
 mining a<br>
&gt; more-work chain than testnet4 would require about the same amount of<b=
r>
&gt; hash that it would take to mine ~13 mainnet blocks at the current<br>
&gt; difficulty, so you&#39;d be giving up about $4M USD in mainnet block<b=
r>
&gt; rewards to do it.<br>
&gt; <br>
&gt; In any event, a hard fork is &quot;necessary&quot;, as otherwise whene=
ver it<br>
&gt; takes 20 minutes or more to find a block, old clients will expect a<br=
>
&gt; lower difficulty than new clients do, so the two wouldn&#39;t be<br>
&gt; compatible with each other. You could do various things to work<br>
&gt; around that, but that&#39;s a lot of coding time that could be better<=
br>
&gt; spent on improving things relevant to mainnet, and if you&#39;re<br>
&gt; resetting the chain anyway, there&#39;s not much advantage to it.<br>
&gt; <br>
&gt; &gt; then you can produce a really long initial chain, which will<br>
&gt; &gt; start in 2009, and up to 2025, it will produce almost the same<br=
>
&gt; &gt; amount of blocks as mainnet.=C2=A0 <br>
&gt; <br>
&gt; A soft fork of testnet3 would start 3rd Feb 2011 (leading to about<br>
&gt; 750k blocks vs mainnet&#39;s ~900k), and a soft fork of testnet4 would=
<br>
&gt; start at 4th May 2024 (leading to about 54k blocks). (These are the<br=
>
&gt; timestamps of the respective genesis blocks)<br>
&gt; <br>
&gt; A disadvantage of doing a premine that way is that users of the chain<=
br>
&gt; need to download and validate thousands of blocks and deal with an<br>
&gt; equal number of utxos just to establish the premine; doing that in a<b=
r>
&gt; single block with a single utxo (or one utxo for each recipient of<br>
&gt; the premine) is quite a bit more efficient.<br>
&gt; <br>
&gt; &gt; Which means, that instead of &quot;premine&quot;, you can use &qu=
ot;ninja-mine&quot;,<br>
&gt; &gt; and achieve pretty much the same end result.=C2=A0 <br>
&gt; <br>
&gt; I think in general usage &quot;premine&quot; covers both those approac=
hes -- any<br>
&gt; time the creator(s) of a chain gets the opportunity to<br>
&gt; claim/distribute coins prior to the general public being able to mint<=
br>
&gt; new coins by mining blocks, that&#39;s a premine.<br>
&gt; <br>
&gt; Cheers,<br>
&gt; aj<br>
&gt; <br>
<br>
-- <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%2Bunsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/20250512120531.1AC1F7C0557%40smtp.postman.i2p" rel=3D"noreferrer=
" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/2025051212=
0531.1AC1F7C0557%40smtp.postman.i2p</a>.<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/CACgYNO%2BkKOenBUykQr3foEqW9vdkMsPTdrBFfCgy4SjDKbc74A%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CACgYNO%2BkKOenBUykQr3foEqW9vdkMsPTdrBFfCgy4SjDKbc74A%40ma=
il.gmail.com</a>.<br />

--000000000000e965cb0634f45541--