bitcoin
Add BIP Testnet 4
A written specification for Testnet 4 has been requested in the PR discussion and a BIP seems to be the right place for this.
Given the active discussion in the PR I think it's best if this is kept open until the PR is merged. I will keep it up-to-date and track the current status of the PR.
I'm still open to someone writing a script to produce useful test vectors, and resetting the genesis block to include those earlier.
I am happy to add this but writing that script is the hard part. I am working on something but there are a lot of ideas, contributors welcome!
Let’s call this BIP 94.
Could you please add the number to the PR title, put it into the preamble, and insert a table entry in the README for your BIP?
@maflcko
To prevent a premine - take the bits from a hash of a future mainnet block:
psuedo code ''' if mainnet_blockheight >= 898898 then messageStart = sha256(mainnetblock_hash_898898) ... '''
This method can be reused for all future testnets?
This is both deterministic and verifiable?
@maflcko
To prevent a premine - take the bits from a hash of a future mainnet block:
psuedo code ''' if mainnet_blockheight >= 898898 then messageStart = sha256(mainnetblock_hash_898898) ... '''
This method can be reused for all future testnets?
This is both deterministic and verifiable?
Couldn't the mainnet_blockheight be a parameter - enabling devs to spin up their own testnet4? It may be useful to miners for testing? In fact - every future block can seed its own testnet4. :)
A parameterized testnet4 <mainnet_blockheight> may have the effect of allowing inscribers to use a testnet4 at mainnet_blockheight <int> for their own purposes - mitigating the incentives to pollute mainnet as well as the global testnet4 at blockheight <tbd>
Note: I was - in jest - calling this "blobnet" :)
https://x.com/randymcmillan/status/1620117331010543624?s=46
A parameterized testnet4 <mainnet_blockheight> may have the effect of allowing inscribers to use a testnet4 at mainnet_blockheight
for their own purposes - mitigating the incentives to pollute mainnet as well as the global testnet4 at blockheight
Part of what makes Testnet still interesting is that there are lots of others using it. So I think this is a different feature that is out of scope for this BIP, requiring seperate conceptual review etc..
What’s the plan regarding the Genesis Block? I seem to recall that we might reset another time before rolling it out for good.
I will bring this up in the Bitcoin Core IRC meeting tomorrow. It may not be the perfect venue but I am not sure what could be a better one and I would like to know what we do before v28 feature freeze. Opinions mentioned to me have been split throughout the last months but I think there is more upside to not resetting. I don’t see an issue with the “pre-mine” of 40k blocks since many of these coins seem to be available through free faucets right now which makes it easier for anyone to get some right from the start. There currently is some distribution of these coins among several miners and it’s not clear to me that a more public re-launch next week gives us a fairer result. Maybe someone invests some real hashrate in order to get all of those first 40k blocks. And not resetting allows us to also set a min chain work as @Sjors mentioned on the PR. So I see more upside on not resetting personally but happy to discuss it.
If we had gotten the task done of embedding scripts then we could have done the reset with that but I don't think I will be able to finish that work by next week and nobody else seems to have stepped up either. I am still going to try to add these scripts in the later parts of the chain and make the tooling available for an eventual Testnet 5.
Okay, then let’s reconvene after Bitcoin Core meeting and consider whether we should merge. Thanks for the quick turnaround on my review.
Should we have picked another bech32 prefix for testnet3? As is, it isn't possbile to distinguish an address meant for testnet3 vs testnet4.
