From: Saint Wenhao <saintwenhao@gmail•com>
To: Sjors Provoost <sjors@sprovoost•nl>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>,
Jameson Lopp <jameson.lopp@gmail•com>
Subject: Re: [bitcoindev] Unbreaking testnet4
Date: Mon, 28 Apr 2025 20:15:35 +0200 [thread overview]
Message-ID: <CACgYNOL3gH6zhmNyiKLenqoiM9mydsxs3XExxJX1ZSVvOmX2bA@mail.gmail.com> (raw)
In-Reply-To: <8E819BCF-EEAE-4F10-89A1-FA3FDE0F67E3@sprovoost.nl>
[-- Attachment #1: Type: text/plain, Size: 5844 bytes --]
> Which means that in practice, instead of seeing huge or overflowed
amounts in UTXOs, we will probably see a lot of repeated entries in the
UTXO set, holding MAX_MONEY each.
Now I applied "doubling" patch in my local regtest, and I can confirm it.
After 2849 blocks, when trying to mine block number 2850, the UTXO amount
exceeded 21 million coins, and then it failed.
```
2025-04-28T17:45:39Z CreateNewBlock(): block weight: 820 txs: 0 fees: 0
sigops 400
2025-04-28T17:45:39Z Saw new header
hash=16d1899aba71f27e7e527f559db7472cbf18f80c2da7e26acb3c2b8476651c54
height=2847
2025-04-28T17:45:39Z UpdateTip: new
best=16d1899aba71f27e7e527f559db7472cbf18f80c2da7e26acb3c2b8476651c54
height=2847 version=0x20000000 log2_work=12.475733 tx=2848
date='2025-04-28T17:50:11Z' progress=1.000000 cache=0.5MiB(2847txo)
2025-04-28T17:45:39Z CreateNewBlock(): block weight: 820 txs: 0 fees: 0
sigops 400
2025-04-28T17:45:39Z Saw new header
hash=1c639e9656dcea7c2c8c694d27bc9dd82bd327bc8c95c4be1d5ec576c99638fe
height=2848
2025-04-28T17:45:39Z UpdateTip: new
best=1c639e9656dcea7c2c8c694d27bc9dd82bd327bc8c95c4be1d5ec576c99638fe
height=2848 version=0x20000000 log2_work=12.476240 tx=2849
date='2025-04-28T17:50:11Z' progress=1.000000 cache=0.5MiB(2848txo)
2025-04-28T17:45:39Z CreateNewBlock(): block weight: 820 txs: 0 fees: 0
sigops 400
2025-04-28T17:45:39Z Saw new header
hash=1e119d36bcd683d4ff2d10c63b60d33431fd141be5cd20d3b0fd074f036b409a
height=2849
2025-04-28T17:45:39Z UpdateTip: new
best=1e119d36bcd683d4ff2d10c63b60d33431fd141be5cd20d3b0fd074f036b409a
height=2849 version=0x20000000 log2_work=12.476746 tx=2850
date='2025-04-28T17:50:11Z' progress=1.000000 cache=0.5MiB(2849txo)
2025-04-28T17:45:39Z CreateNewBlock(): block weight: 820 txs: 0 fees: 0
sigops 400
2025-04-28T17:45:39Z [error] TestBlockValidity: Consensus::CheckBlock:
bad-txns-vout-toolarge, Transaction check failed (tx hash
5802b7370153f8c415fcf689bda204adebe4483c306110ae33a35a88a593d495)
2025-04-28T17:49:41Z CreateNewBlock(): block weight: 808 txs: 0 fees: 0
sigops 400
2025-04-28T17:49:41Z [error] TestBlockValidity: Consensus::CheckBlock:
bad-txns-vout-toolarge, Transaction check failed (tx hash
f9a54543470144efc33e975d02f44188a7a0d88c16fb997018e33b4e66244f37)
```
And it also failed immediately, after calling "getblocktemplate".
However, after manually crafting a block with 21 million coins, it
succeeded:
$ ./bitcoin-cli -regtest getblock
627434e2e29fb3409aa9bca6b27b261210b3adf274e6e091da889ece9142901b 0
000000209a406b034f07fdb0d320cde51b14fd3134d3603bc6102dffd483d6bc369d111e9d347f2c3a7114151cdc93c9cccc2f6ce64cf7c1b71bb454d005202c9140d413d5bf0f68ffff7f200200000001020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff0402220b00ffffffff020040075af07507000451024e730000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000
2025-04-28T18:06:27Z Saw new header
hash=627434e2e29fb3409aa9bca6b27b261210b3adf274e6e091da889ece9142901b
height=2850
2025-04-28T18:06:27Z UpdateTip: new
best=627434e2e29fb3409aa9bca6b27b261210b3adf274e6e091da889ece9142901b
height=2850 version=0x20000000 log2_work=12.477252 tx=2851
date='2025-04-28T17:50:13Z' progress=1.000000 cache=0.5MiB(2850txo)
Which means, that after reaching 21 million coins, that kind of UTXOs will
be produced forever. And I guess it won't be even possible to send more
coins than that in a single transaction, which means, that we are quite
safe from any kinds of overflows, but we are not safe from flooding the
UTXO set with max coin amounts.
pon., 28 kwi 2025 o 14:47 Sjors Provoost <sjors@sprovoost•nl> napisał(a):
> Jameson Lopp wrote:
>
> > Encoding an "end of life date" into testnets is actually an interesting
> idea worth discussing. As far as I'm aware it's never been done before on
> any network.
>
> Keep in mind that testnet-specific code has to live right next to, even
> inside of, mainnet consensus code. We want the change to be as simple as
> possible, so as to not accidentally break mainnet.
>
> Unless and until coin expiration is something we're seriously considering
> for mainnet, we'd rather not implement it for testnet.
>
> This particular idea probably requires a lot of changes all over the place
> (consensus, mempool, wallet) because it breaks the assumption that coins
> don't expire.
>
>
> Something I've proposed in person a few times, is to double the coins
> every halving. In terms of code, it boils down to changing GetBlockSubsidy:
>
> CAmount nSubsidy = 50 * COIN;
> // Subsidy is cut in half every 210,000 blocks which will occur
> approximately every 4 years.
> If (consensusParams.inflation) {
> // Except on testnet5
> nSubsidy <<= halvings;
> } else {
> nSubsidy >>= halvings;
> }
>
> This will eventually overflow, but that seems fine for a testnet. Along
> with the timewarp fix, the network might even grind to a halt in 2106, long
> before we overflow 64 bit numbers.
>
> Rust Bitcoin [0] currently refuses amounts above 21 million BTC, but they
> would have many years to fix that.
>
>
> Strong inflation has been battle tested by governments around the world
> for millennia as a way to discourage saving.
>
> - Sjors
>
> [0] https://github.com/rust-bitcoin/rust-bitcoin/issues/4273
--
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/CACgYNOL3gH6zhmNyiKLenqoiM9mydsxs3XExxJX1ZSVvOmX2bA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 6698 bytes --]
next prev parent reply other threads:[~2025-04-29 14:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 14:29 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-18 21:34 ` Melvin Carvalho
2025-03-19 7:01 ` [bitcoindev] " Garlo Nicon
2025-03-19 7:56 ` [bitcoindev] " Sjors Provoost
2025-03-19 8:43 ` Garlo Nicon
2025-03-19 8:32 ` Sjors Provoost
2025-03-19 9:11 ` Melvin Carvalho
2025-03-19 17:03 ` bitcoin-dev-ml.void867 via Bitcoin Development Mailing List
2025-03-20 18:58 ` Melvin Carvalho
2025-03-21 21:20 ` Murch
2025-03-24 7:00 ` Garlo Nicon
2025-03-31 7:32 ` Saint Wenhao
2025-03-24 12:25 ` Murch
2025-03-24 13:57 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-27 11:44 ` Saint Wenhao
2025-04-27 22:49 ` Jameson Lopp
2025-04-28 6:11 ` Saint Wenhao
2025-04-28 10:45 ` Jameson Lopp
2025-04-28 11:59 ` 'emsit' via Bitcoin Development Mailing List
2025-04-28 12:47 ` Sjors Provoost
2025-04-28 13:33 ` Saint Wenhao
2025-04-28 18:15 ` Saint Wenhao [this message]
2025-04-28 18:50 ` Sjors Provoost
[not found] ` <20250428110655.D4A1C7C0AE9@smtp.postman.i2p>
2025-04-28 11:48 ` pithosian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACgYNOL3gH6zhmNyiKLenqoiM9mydsxs3XExxJX1ZSVvOmX2bA@mail.gmail.com \
--to=saintwenhao@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=jameson.lopp@gmail$(echo .)com \
--cc=sjors@sprovoost$(echo .)nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox