From: Garlo Nicon <garlonicon@gmail•com>
To: Saint Wenhao <saintwenhao@gmail•com>
Cc: Anthony Towns <aj@erisian•com.au>,
Greg Maxwell <gmaxwell@gmail•com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Unbreaking testnet4
Date: Sat, 5 Jul 2025 06:31:18 +0200 [thread overview]
Message-ID: <CAN7kyNgNowuB0Cr=cvC91QOgmUVXiawFzRgrPDENg0i2UUD+XQ@mail.gmail.com> (raw)
In-Reply-To: <CACgYNOJN8ZJEutL75HZz-KcbpJfMdDrODm8qDrcNDFOE7U-J9A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 10813 bytes --]
> 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 <saintwenhao@gmail•com> napisał(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 in
> 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 chain.
> 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 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.
>
> 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-mined
> 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, then
> that person can be forced to upgrade, if you send the new chain to the old
> 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 nodes
> to upgrade; that's why we promote soft-forks in general, because they are
> unstoppable).
>
> pon., 12 maj 2025 o 07:21 Anthony Towns <aj@erisian•com.au> napisał(a):
>
>> > > 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=105000 and premine=10'500'000*COIN or similar,
>> but leave premine_block_hash=0
>>
>> 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/CAN7kyNgNowuB0Cr%3DcvC91QOgmUVXiawFzRgrPDENg0i2UUD%2BXQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 12150 bytes --]
next prev parent reply other threads:[~2025-07-05 6:54 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 14:29 [bitcoindev] " '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
2025-04-28 18:50 ` Sjors Provoost
[not found] ` <20250428110655.D4A1C7C0AE9@smtp.postman.i2p>
2025-04-28 11:48 ` pithosian
2025-05-05 22:25 ` [bitcoindev] " Greg Maxwell
2025-05-06 11:48 ` Saint Wenhao
2025-05-09 13:07 ` Garlo Nicon
2025-05-12 5:21 ` Anthony Towns
2025-05-17 5:11 ` Saint Wenhao
2025-07-05 4:31 ` Garlo Nicon [this message]
[not found] ` <20250512110323.B14F27C0B49@smtp.postman.i2p>
2025-05-12 12:05 ` pithosian
2025-05-12 18:17 ` Saint Wenhao
[not found] ` <20250512181809.5705B7C114F@smtp.postman.i2p>
2025-05-12 20:19 ` 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='CAN7kyNgNowuB0Cr=cvC91QOgmUVXiawFzRgrPDENg0i2UUD+XQ@mail.gmail.com' \
--to=garlonicon@gmail$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoindev@googlegroups.com \
--cc=gmaxwell@gmail$(echo .)com \
--cc=saintwenhao@gmail$(echo .)com \
/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