From: Saint Wenhao <saintwenhao@gmail•com>
To: Sjors Provoost <sjors@sprovoost•nl>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>,
Jameson Lopp <jameson.lopp@gmail•com>
Subject: Re: [bitcoindev] Unbreaking testnet4
Date: Mon, 28 Apr 2025 15:33:53 +0200 [thread overview]
Message-ID: <CACgYNOJuWPDH7n2UMwYOhOZ=uxD6_taagyi23iTKEw_2seGyiw@mail.gmail.com> (raw)
In-Reply-To: <8E819BCF-EEAE-4F10-89A1-FA3FDE0F67E3@sprovoost.nl>
[-- Attachment #1: Type: text/plain, Size: 3846 bytes --]
> because it breaks the assumption that coins don't expire
Technically, they can expire, if the client can see some chain
reorganization. And it is something to think about: if the consensus will
force miners to go back to some previous block height, and produce a
stronger, alternative chain, then such testnet would automatically perform
full chain reorganization, wired into its consensus rules. And then, coins
would expire in a backward-compatible way, while also battle testing full
chain reorganization (which may need testing anyway, for other reasons,
like checkpoints).
> This will eventually overflow, but that seems fine for a testnet.
As far as I remember, there were some additional limits, introduced after
Value Overflow Incident, for example that a single UTXO cannot hold more
than 21 million coins:
https://github.com/bitcoin/bitcoin/blob/master/src/consensus/tx_check.cpp#L29
```
// Check for negative or overflow output values (see CVE-2010-5139)
CAmount nValueOut = 0;
for (const auto& txout : tx.vout)
{
if (txout.nValue < 0)
return state.Invalid(TxValidationResult::TX_CONSENSUS,
"bad-txns-vout-negative");
if (txout.nValue > MAX_MONEY)
return state.Invalid(TxValidationResult::TX_CONSENSUS,
"bad-txns-vout-toolarge");
nValueOut += txout.nValue;
if (!MoneyRange(nValueOut))
return state.Invalid(TxValidationResult::TX_CONSENSUS,
"bad-txns-txouttotal-toolarge");
}
```
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.
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/CACgYNOJuWPDH7n2UMwYOhOZ%3DuxD6_taagyi23iTKEw_2seGyiw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4822 bytes --]
next prev parent reply other threads:[~2025-04-29 14:15 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 [this message]
2025-04-28 18:15 ` Saint Wenhao
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='CACgYNOJuWPDH7n2UMwYOhOZ=uxD6_taagyi23iTKEw_2seGyiw@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