path: root/8a/cfe34acc520292406a2b9bd14554313e964e19

Delivery-date: Wed, 14 May 2025 02:36:52 -0700
Received: from mail-qt1-f192.google.com ([209.85.160.192])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBAABBKOISHAQMGQES4ZBKNA@googlegroups.com>)
	id 1uF8Xj-0004cV-3E
	for bitcoindev@gnusha.org; Wed, 14 May 2025 02:36:52 -0700
Received: by mail-qt1-f192.google.com with SMTP id d75a77b69052e-4853364ad97sf82731331cf.0
        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=GwAOoe0bZMwQIlorWXexb4e6FexWxOdgGpL/nyRKi+EHijBfA5x9iJ+YAgj4Rutncj
         AwLODXceNBrw6GuCGOKZGGJUS7HZf3/ebhXHt5JPvk8qnd2rNK9pHp6hfKD/QPNoUXUJ
         rUjbEir0v9v5JDShj3d6zvWZ1ey1xkoTaH/wRrLjTM/ub7BM4H871m79w7WJQRQetxED
         IOKm3j6j500ZJ/cBB71u1lDox3I80OcuXMGpkTE2CAahZKbx0aVHU4gNM0q1MjJ+4kyS
         RoDXdI20TSbswSstQwg8kkOTpcq7ip07b/MoDNeTmlQQtJMWAQumarcEOg4l1taQFYf+
         bFfw==
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:date:message-id
         :content-transfer-encoding:mime-version:references:in-reply-to
         :subject:cc:to:from:sender:dkim-signature;
        bh=8QbO6FwpELK95aBVxmZ0B13w9MOLafSoldLLdUriJxE=;
        fh=hBnkvS6qMRvabEnwOtKP6g19CuMi2E3rr6w2CPaznaI=;
        b=eoXb8VhyTvrYzr09ZHOpkRzc+9ylzGVrgYyHGvjL3deDJzyTTE51c8KZ73vTFj+v7u
         maTMTB3KZNt/x2YH11NSz3hcUoUXMhcgEa9p7Mfwk4emCapOo6nF0Mou7VPwYS/anrQK
         uCQpoeA6n2CZXsqNNbmgWp5e0A0PnGO9wP5Y6VJ+kb3NavOz+IFbRkKIjba1ZFUbt6uG
         CE0MikVJcLMOq8cWPp7LcCLf2i1kYJRgBQegduhbQWUMqAEfZ0egHWX5pVVxH7K+yZcB
         D+tPeBFyV08U5x2DwSOPiWgZasUxJkIg7JDOFSUzqeM1lkZnikKiNTVrclj9pMWhXQMY
         FQpQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       spf=pass (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as permitted sender) smtp.mailfrom=pithosian@i2pmail.org
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:date:message-id:content-transfer-encoding
         :mime-version:references:in-reply-to:subject:cc:to:from:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=8QbO6FwpELK95aBVxmZ0B13w9MOLafSoldLLdUriJxE=;
        b=xWAK3VD5wm0e9KqS/9FCr7C62NLbcbsAgwRZ32nAj3Fho/ZRCHLa2ywMIm6yOTdKo/
         7WNHNQzhctZYgZ+PWJKYkkEJzW36XRRRuoqxl+haHuA/z4bz64VKevi1LX3OOOM5Yaxt
         KbQ1g3FmgkvuhYC3JRWTFklGBR9kfsHSTBQHhDnJT3e+QqCxGZq24abRHtgvbmHEa/6C
         PEGRnukhKWXkjwTzRWI96D9CZlsETg925+NfTH5Sxs8kqk3qLKvGYZqhNIL/DP9IZSbF
         9JlgG0sMEOhxWlzNGREl+yI3mU/MAX7mFPan6QHRMjaWVvRChJo/C2G78adKY1Ojk7Ba
         UFMg==
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:date:message-id:content-transfer-encoding
         :mime-version:references:in-reply-to:subject:cc:to:from:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=8QbO6FwpELK95aBVxmZ0B13w9MOLafSoldLLdUriJxE=;
        b=fFs7oQ0ka/f9VYFm+ZwbZBnxgPfyPZ5Oxvjtrz/ajyHcHvd7cnDMYDJlqUx1DaQ7hB
         hPu7IjkBVz83aS2uFJ7FjgddGjIJ7J8q2Y38FrahPpgaxBDkvaE7+G32Prk02T+IbGf7
         Xb0s0LKiXNacFU9r0zibOjSCdRYYvV6DCf9IE/rO0jBLj7YDkXt522+h8/ig51gG6qjS
         Zhhl8JntqYXoHbIRmIieI36ejvPrRK40WHePJWxpzgmaOs2anmVBgkV1auFpfhi6UBC0
         yt8bON8l9iNah5uk2Sv0aVyLaD/+gphzWQ7yeHoH03QGgSclcGz/ZvHVjDNYbK8NnrtJ
         4vfw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCUGcf37OXAkKc1DrBnxOOMAAQwHo0lPpACMFAL1rpgh7mh0vvdnbeM1Uk27o5NZEBn1K8phkV8otKDD@gnusha.org
X-Gm-Message-State: AOJu0YyMZb+k8y71YJgxeZhjT/sWo5FXCHGpCBbg5/Ei+a9qu2EX9vDb
	Ev+fVbROrd+oKdouE4UGYUweUfTwUtYc9ZUbe2WguPQ5qZbObm/D
X-Google-Smtp-Source: AGHT+IGzY/SH+v6DVGPocE/RiBq9lzybTWoDYB9awxJHja4noX4gP5cluwE5uyyj9OF36rw9dCgYHA==
X-Received: by 2002:a05:622a:5c05:b0:48a:ca7b:372d with SMTP id d75a77b69052e-49495c56c7fmr36890891cf.10.1747215404632;
        Wed, 14 May 2025 02:36:44 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBECTZwxkP/4UiLZLpU9e16Sm3QCyPu1Zb+bXcv1X4RlBA==
Received: by 2002:ac8:60c4:0:b0:47f:81f1:5da0 with SMTP id d75a77b69052e-49449483a9fls5199531cf.1.-pod-prod-08-us;
 Wed, 14 May 2025 02:36:41 -0700 (PDT)
X-Received: by 2002:a05:620a:4693:b0:7c5:9b12:f53c with SMTP id af79cd13be357-7cd287f9126mr378588785a.5.1747215401050;
        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 21:25:16 -0700 (PDT)
X-Received: by 2002:a5d:5f96:0:b0:39f:b62:8cb2 with SMTP id ffacd0b85a97d-3a1f64d43b7mr13542789f8f.38.1747110314577;
        Mon, 12 May 2025 21:25:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1747110314; cv=none;
        d=google.com; s=arc-20240605;
        b=NANLY/7TjGJYfu8BndoN+TvlJyvb71+WhxD1F3JPH3J3u67f0bQDJ47HYqKAnGt0w3
         5RDkVwFUcpsfUB2kBTq9RBPf/L0uaPLoJG9ejhsv/91hIQGLMdcQYaWyJWJiy3eNm//9
         j04BFY5L3CzAjuezFEgCEx/oF56S0XFAjB5jyH5gmXofDaAXBAKCM+Sc4qBNVdrafjyK
         jwPmWRgbM86m8LVnd/Ql/kRWa4KF8x0uHZjmcCJzTaeokoR/ZkUoL6vGUjc4bQQxqX4Y
         Evzl+w8oMMMn/9phVEbvwy7bUecoiuKvKbYaZtKUkUBGO6OBZmNdFdM1i7FAZyVfnV7N
         LLhg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=date:message-id:content-transfer-encoding:mime-version:references
         :in-reply-to:subject:cc:to:from;
        bh=9dBnGzTwJaXldyPnYwzn3WcPyhCn57DwHYWtWDzU9/k=;
        fh=4lrVmGu0H95n1wZpwO+wVZGexrNOPea3C8gsrHj2mio=;
        b=bjL8Ob8x+db0ufqULDA0CeJpCFWAfbOfg0ahzY8FcOEt3OFX2wDq9CZtI/YbOAsu1w
         KfVBbhA70o0CkL7kYnCP3K1nG/O/S7oKcdJ0TkMW7Ao5m2mymWPexknDf91RdKK3U24Q
         E1WiFB83o4PYeURCkC7jEaXQIIXbtkQTwrg/XZxtTspNGoY6eauNslihglDgRmYG39N0
         YZql+hKg/Q9lD8k/sbgrtBwn/qNuPKYzWIhTxJtOPL9S6iAGgM00EioAak/7fsQRdnPR
         71y6Q3v4VjTzVy2AqPIaGqHDGwN+6GdakSCfH/4uviRIh2zUIYCUBxz/8ZGaap6p84Qx
         puhQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       spf=pass (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as permitted sender) smtp.mailfrom=pithosian@i2pmail.org
Received: from mail.i2pproject.net (mail.i2pproject.net. [91.143.83.7])
        by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-442ebd3ad76si229355e9.1.2025.05.12.21.25.14
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 12 May 2025 21:25:14 -0700 (PDT)
Received-SPF: pass (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as permitted sender) client-ip=91.143.83.7;
Received: from i2prouter.i2p.net ([81.7.8.99] helo=smtp.postman.i2p)
	by mail.i2pproject.net with esmtp (Exim 4.96)
	(envelope-from <pithosian@i2pmail.org>)
	id 1uEhCU-005pA6-1L;
	Tue, 13 May 2025 06:25:09 +0200
X-Mailer: smtp.postman.i2p - Official I2P Mailer
From: pithosian <pithosian@i2pmail.org>
To: Saint Wenhao <saintwenhao@gmail.com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Re: Unbreaking testnet4
In-Reply-To: <20250512181809.5705B7C114F@smtp.postman.i2p>
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>
	<20250512181809.5705B7C114F@smtp.postman.i2p>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.103.X on milter.postman.i2p
Message-Id: <20250512201916.3818A7C1190@smtp.postman.i2p>
Date: Mon, 12 May 2025 20:19:16 +0000 (UTC)
X-Spam-Score: -3.0 (---)
X-Original-Sender: pithosian@i2pmail.org
X-Original-Authentication-Results: gmr-mx.google.com;       spf=pass
 (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as
 permitted sender) smtp.mailfrom=pithosian@i2pmail.org
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.9 (/)

> Not only that. It may also invalidate timelocked signatures, which
> would be made around "halving".

Good point. I was thinking about just hacking at the UTXO set as it
conceptually seemed to make the change very localized, but timelocks
probably(?) rule the whole approach out.

The freely-spendable amount would be:

amount/2^(targetHeight/halvingBlocks-utxoHeight/halvingBlocks)

Or the bitshift equivalent, where targetHeight is the current height,
or in the case of timelocks, the locked height, but longer
timestamp-based timelocks can't be reasoned about very well with any
'degrading coin' behaviour, and even your presigned, height locked
transaction might not get be confirmed before the next epoch if the
timelock approaches it.

Doesn't modifying spendability have the same problem? When presigning
your timelocked transaction, you need to be aware of the amount you can
actually spend come expiry of the timelock up-front, however the coin
degrades.

It also breaks lightning channels, I think.

On Mon, 12 May 2025 18:18:09 +0000 (UTC)
Saint Wenhao <saintwenhao@gmail.com> wrote:

> > Updating the entire UTXO set all at once would be pretty expensive,
>=20
> 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.
>=20
> 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).
>=20
> 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.
>=20
> pon., 12 maj 2025 o 15:50 pithosian <pithosian@i2pmail.org>
> napisa=C5=82(a):
>=20
> > 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=
%40smtp.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/=
20250512201916.3818A7C1190%40smtp.postman.i2p.