Making testnets completely useless

I think I figured out how to really devalue testnets. One key point is to know ahead of time when the network is gonna reset. Another part is to automatically switch to the new testnet in a synchronized manner. In the current testnet4, the Genesis Block links to the mainnet block here: https://mempool.space/testnet4/tx/7aa0a7ae1e223414cb807e40cd57e667b718e42aaf9306db9102fe28912b7b4e. If you check it out, there’s a fake public key with all zeroes and a coinbase message we can decode. The message contains the timestamp and the hash of mainnet block 842000: https://mempool.space/block/000000000000000000001ebd58c244970b3aa9d783bb001011fbe8ea8e98e00e. But the mainnet block doesn’t carry any info about the testnet; it’s just a timestamp. In theory, if we reset the testnets every time a new mainnet block is created, they would become totally worthless. Like 10 minutes after testnet842000, we’d have testnet842001, and who’s gonna buy coins that are just gonna vanish in 10 minutes? Some folks think that resetting the testnet so often would kill any chance of “long-term testing.” So I was wondering, why not use Merged Mining to create the testnet chain? This way, we could reset the testnet every time a block is mined that’s valid for both testnet and mainnet. It would timestamp the new testnet while also getting rid of the old one. Most of the time, testnet miners would end up creating weaker blocks, and they could just share "shares" as valid testnet blocks.

I think the idea to reset the TestNet chain is a good one but it shouldn't take place every block because that would make it a nightmare to use. You need a working chain to form and grow. Not to mention that the coinbase rewards need to mature for 100 blocks before they can be spent. But I don't think there is any easy way to implement it so that it happens automatically and without human intervention. Lets say we decide to reset the chain every 4032 blocks (2 difficulty adjustment period that should take 4 weeks assuming normal hashrate). The problem is the genesis block. How should be build that? We certainly can't predict the future hash of a mainnet block to be used in it and by that time this future block may not have been mined yet. I don't think those who redirect their ASICs to testnet care about money or securing the main-chain.

In testnet4, it contains the hash of the mainnet block. So, all that is needed, is just requiring a given format, and accepting any block, which would meet it. Because when the next block will be mined, then everyone will switch to the next testnet anyway. And I think it could literally be the mainnet block. So, for example: when you have block 00000000da84f2bafbbc53dee25a72ae507ff4914b867c565be350b0da8bf043 in testnet4, you could replace that hash with 000000000000000000001ebd58c244970b3aa9d783bb001011fbe8ea8e98e00e from mainnet, and literally include the mainnet block as your starting point. And that's why testnet resetting should depend on things like chainwork. If you make a rule, such as "reset the chain every 4032 blocks", then people would know exactly, when it will be resetted. But if you use a rule, such as "when this mainnet block will be produced, then the chain will be resetted", or even "when this amount of chainwork will be produced, then it will reset", then it is known upfront, what is needed to reset things, but nobody knows, when exactly it will happen. Also, "4032 blocks" won't work if you start from the minimal difficulty. One adjustment bumps it only 4 times, so reaching difficulty 16 is trivial, if you have just a single ASIC. I think when Satoshi picked 0x1d00ffff, then it reflected the effort, needed to mine a block at that time, because people used only CPUs for mining. And the Genesis Block actually meets something like 0x1c00ffff, so it has one more grinded byte, than it needs (which is also reflected in early versions, where mainnet difficulty is set to 40 bits, and prenet is set to 20 bits). So, I think people should collectively work on the Genesis Block, and it should meet the mainnet difficulty, or a predefined fraction of it (it is easier to meet the mainnet difficulty, because then, a real mainnet block starts the new testnet, and ends the previous version at the same time). In general, I think people stopped using Merged Mining, because of how some altcoins like NameCoin did it. But it can be improved. And I think there is a value in starting new altcoins in a way, where all block headers from the mainnet are traced, because then, a given altcoin can know the real double SHA-256 difficulty, instead of artificially starting from 0x1d00ffff, and letting it self-adjust. Also, if some people could really get 3.125 BTC plus fees, then why lose that chance? But even if someone doesn't care about money, then I think there is yet another reason, to trace mainnet headers: to accept external proofs, and execute contracts, based on them. By knowing the hash of some mainnet block, it is possible to require revealing the content of the header. By knowing that header, it is possible to travel through the merkle tree. And by doing that, it is possible to go deeper, and require a given chunks of transaction data. Which means, that testnet could start with zero coins, but allow teleporting real transactions from mainnet, and testing a lot of "what if" scenarios. And I think there is a value in things like that, because then, you can teleport some mainnet transaction there, and check, if it is really spendable or not. Also, all amounts, and network conditions are then more similar to the mainnet, so you don't have to start over from 50 tBTC per block, where the mainnet is after four halvings, and it can produce 3.125 BTC per block in practice. Because if testnets would really want to start with 50 tBTCs, then they should also start with 0.01 tBTC transaction fee, and the lowest unit should be a million satoshis for a while. So, it is better to stop pretending, that we had 1 sat/vB with 50 BTC, and better trace the mainnet conditions, which are used in practice.

"Auto-reset by coinbase/message" is a consensus footgun. You'll create partitions the first time a miner accidentally (or maliciously) trips the trigger. If you want clean slates without drama, I would advise to use tools we already have. Signet for predictable, restartable public nets. Rotating the -signetchallenge is a reset with zero PoW guessing and no ambiguity. Ship a couple public signets (stable, fast) and rotate on a schedule. If you really want a new PoW testnet, do a straight Testnet4: new genesis, magic bytes, seeds, and nMinimumChainWork. Don't make resets automatic; flip via new releases. Keep mainnet-like params (10-min target, 2016-block retarget). Consider dropping the "special min difficulty" rule -- that's what made testnet3 weird. For local throwaway work, regtest/signet-with-own-key beats any auto-reset logic.

excessive resets defeat the point,  if you don't want to test interop with third parties use regtest.

Well, instead of making "reset", based on "throwing away the history", another change can be made: "demurrage". Which means locking coins on Scripts like that: Then, it will make things easier for pruned nodes, because after a given amount of time, coins can be moved by anyone, unconditionally (which means "swept by miners" in practice). And instead of OP_CHECKLOCKTIMEVERIFY, it is possible to also use OP_CHECKSEQUENCEVERIFY. It is just about the way of defining the timestamp. If there will be a consensus rule, that "all scripts should be considered as OP_TRUE, after some calculated timestamp", then it can happen automatically. As shown above, it is possible to make a Script, which will enforce it on top of existing networks. So, all that is needed, is just changing the code, used to execute all Scripts, to always wrap everything in that kind of "demurrage envelope" before executing, and then, it should work automatically. So, that kind of scripts can explicitly appear in "scriptPubKey", or consensus rules could be changed, to mimic that behaviour, on top of any "scriptPubKey", even if it would be "OP_FALSE" or "OP_RETURN" (only some restricted opcodes, like OP_VERIF will burn the coins in that case, and only if used as a raw scripts, because behind P2SH, or other hashed addresses, there could be some hash function collisions). Edit: P2SH will also expire in that case. The only burned coins would use OP_VERIF or similar opcodes as raw scripts, or when miners would claim less coins in the coinbase transaction (which is what Proof of Burn enthusiasts should use anyway, to not spam the UTXO set).

I recently joined a beta test for a new exchange. The owner mixed up testnet3 and testnet4, which makes me think frequent resets are only going to be more confusing. Both testnets are currently shitty: v3 barely has any testcoins available, and v4 has many blocks that don't include transactions. At this point, wouldn't it be better to just remove the difficulty adjustment from testnet? It was implemented to keep the chain going if a large ASIC miner quits after pushing up the difficulty, but abusing the difficulty adjustment to mine empty blocks kinda defeats the purpose. And it would bring testnet closer to the real thing again.

That's the plan: https://groups.google.com/g/bitcoindev/c/iVLHJ1HWhoU Also, the next thing, which should discourage trading, is to make a premine of 10,5M coins: https://bitcointalk.org/index.php?topic=5543921 But in case of a premine, then if it will be sold, then it will just change hands, and the chain will continue being normally traded, and used since then. So, I think it won't solve all problems, and other things like "demurrage" are needed. Also, if next testnets wouldn't have any reset rules wired into consensus, then Core developers will just became altcoin makers, if they keep making next testnets, and if all of them will be traded.

Here's another brainfart: what if every user can create their own testnet? I have no idea how easy or difficult that would be to implement, but I imagine starting Bitcoin Core like this: Anyone can run their own node, add this genesis block, and connect to your node by adding the IP address: Would that work? I'll call mine Testnet LV (Loyce Vision) If you want to sell it: sell it! If you want to reset it: you can't! But you can abandon it and create a new one. So if you're beta testing your new exchange, anyone who joins the test will have to connect to your own temporary testnet version. And while typing all this, I realize this is only going to be more work for testers who now have to create their own test network instead of just getting some coins to start testing... Like I said: my brainfart....

Anyone can already make its own testnet, which is called "signet". The problem is, how to make a testnet, where mining would be decentralized, and where anyone could mine new coins? Part of the solution is to send coins to Proof of Work puzzles, or similar scripts, like it is done in the current signet: https://delvingbitcoin.org/t/proof-of-work-based-signet-faucet/937 And then, you have a lot of testnets, where users are splitted between many different networks. Which means, that if you want to test something, then you have some users here, some users there, and other users somewhere else, and it is harder to coordinate some things. Because for example, if each user has its own testnet, then you no longer can "hide in a crowd", because there is no "crowd", if you are the only user. Also, tests are then connected to a specific chain, so the same transactions are migrated over and over again, between different networks, so if one person tested "OP_CHECKSIG", then you cannot link to some block explorer, but you have to repeat all tests yet again. Exactly. The problem is not about making any chain (because it is quite trivial, and that's how a lot of altcoins were made; also, regtest can be used, if some local network is needed), but to make something, which will be used by the community, to send worthless coins back and forth, and where anyone could mine something, make some transactions, and leave (without worrying about the future of such testnet, and resource consumption, if it could self-reset, and clean up that mess automatically, on a regular basis; while also allowing to keep some history for those, who will want to do that, and refer to past transactions or blocks).

You'd be way better off looking for ways to make Bitcoin better rather than making Bitcoin Testnet worse.   Also, to think that I'm going to allow premined coins to trade on my platform with the intent of enriching select developers while purposely hurting users is kinda crazy. I've already given a private demo to GMaxwell of the tools we possess.  I'm totally willing to use them, but I would strongly rather not.  I enjoy seeing Bitcoin developers processing Bitcoin withdrawals from us.  It is a tool that bothers me to use, especially against fellas I appreciate.  I see no path of legal recourse against our tools that wouldn't firmly establish value for Testnet in a very formal setting... which, we would be happy to lose that case and potentially focus on our countersuit (not a want or a goal of mine, but we will defend ourselves). Hostile Dev vs Hostile Exchange isn't going to be a good time. Your idea of resets and the premined is actually reallllllly old from Greg 14 years ago: The truth of the matter is that Testnet is mostly used by corporations these days, which is a surprising observation for me and is surely linked to the evolution of Bitcoin through the years.  Russia has been showing its latest Bitcoin mining interest in Testnet for months, so perhaps it goes from Individuals -> Companies -> Nation-states (?) Furthermore, Testnet3 was attacked and reset for a private corporation (Citrea).  Jameson Lopp (Citrea Investor and Bitcoin Core contributor) purposely dried out the block reward so miners could no longer easily mine Testnet and then used this as force to launch Testnet4... which Citrea is actively using for public participation, but you need 10 whole Testnet coins!!!! (insane, no faucet could ever meet this requirement) Monitoring Testnet allows users to have a glimpse of what is coming to Bitcoin.  In the Citrea case, it was "You are going to do this, or we are going to do this to you."  These actions and mindset went from Testnet to now Bitcoin. (Cause they really did attack Testnet to get their way, I have no doubt they would do the same to Bitcoin mainnet if they didn't get their way.). Another example is Greg spotting Autoboost mining by Bitmain and them admitting to using it on Testnet way back in the day before anyone else. The unintended result from drying up the block reward is that now... My little exchange really does have a monopoly on Testnet3! lol!   "Testnet3 is out of coins for free distribution!"   Check out this transaction I saw this morning while auditing:  https://mempool.space/testnet/tx/0363590be9239476e142d1e412c773f9ee81e820727781b3cc6e3cf0c96b15e6 That user has earned over 2.4 BTC distributing Testnet to users that need them... Kind of amazing tbh.  It's a level of friction distributing Testnet coins to good homes that no faucet to date could ever match. Our business plan works.  The faucet is full & self-sustaining even with the block reward being zero. Find a more productive hobby or go join the BSV team... BSV loves controlling transactions, telling people how they "should use" their coins, and intimidating people with their various threats/suits and "developer wizardry" (or lack thereof!). I think that's part of his problem... he's played farrrr too much in his own no competition world and thinks that his imagination should apply to third parties also testing their own stuff, and the fact that this third/forth/etc party is rekting his stuff, now he wants to nuke it. If you get pwned in Testnet, then you need to go back to the drawing board because Bitcoin would absolutely rekt you, your code, and your funds. It's super easy to mix them up, especially with the Bitcoin client using v3 as default, still, even with the v4 rollout.  It's wayyyyy harder to just drop a version and start a new one than anticipated.  Even Blockstream's explorer is confusing.  (it's v3 still) Both actually work just fine exchange-wise.  See the transaction above for "barely any coins" idea to get bucked in your head.  There are *plenty* of v3 floating around and stored. V4 miners are clearing the blocks with the ASICS and then the 6 following blocks include transactions now.  This is keeping Testnet4 moving smoothly. I've not had a customer support ticket in a while regarding the network. That exchange you are testing just looks buggy AF.  I'll send some testers, but you get the real fun testers when there's value attached. Jan 2026 probably. Which will be interesting.  I do agree this is the right call as well.

I take it the buyers don't know that less than a third of that amount would be enough to wipe testnet 3 and start over from scratch: (disclaimer: unless my math is wrong) The last V4-block that included transactions was 7 hours ago, the one before that 10 hours ago.

Lol today I got a customer support ticket about Testnet lol... oooo the irony. We require 100 confirmations, so imagine how those poor bastards feel. I don't think the buyers give a shit about it being attacked.  They are buying for testing; if some dick hits it, then back to the drawing board.  If you were testing with 0.001 BTC for a product that was going to earn you 50 BTC (or much more)... would you give a shit? The fact of the matter is the vibe in Testnet is very not give a shit.  It is lovely. If your numbers are correct, I am 100% sure that I've given multiple Bitcoin developers plenty of Bitcoins... I'm going to guess they have better plans for the coins than to blow them on Testnet.  . I think you're underestimating the cost of attacking Testnet regardless.  You should try it and report back with real data.  It'd be cool to see. Attacking Testnet is like beating up the retarded kid at school IMO.  This whole OP gives that vibe... little retarded testnet is just trying to live and do its best!

Maybe. It's the first time I did the math on this (and nobody pointed out any mistakes). I don't have 0.66386 BTC worth of hashing power to waste on this, so I'll skip this one Most definitely! I can imagine someone with enough hashing power to start from genesis, ignore testnet block 1, and create a new chain from there. Create many blockstorms along the way, run through 32 halvings, end up with the chain with most work, 6,720,000 blocks and 0 block reward remaining. At that point you'll connect to the internet and all testnet nodes will switch to your chain with most work and empty blocks. You'll own almost 21 million testnet coins and have successfully taken over. Even better if you broadcast this on April 1st! Let's call it a $100,000 joke Similarly, by not creating blockstorms and just backdating blocks to increase the difficulty as much as possible, you could probably end up with a most-work-chain that hasn't even seen it's first halving yet. Note: I haven't done the math on this yet. I think you missed the hypothetical part of this

There are far more people with 0.001 BTC that want easy access to Testnet than there are people who want to burn .66386 BTC just attempting to be a dick. Even if someone attacked Testnet... so what?  Then what?  It sounds like a gold Bitcoin cookie award. I sell all my TBTC into BTC, as per the FAQ I typed as well, that trade is a trade even if the smuck gets pwned by a the network. So you hurt a ton of people who didn't trade testnet, + you harm people who acquired their coins with us, and the exchange skips along with their Bitcoin.  Cute April Fool's joke, all of these innocent projects that have hundreds of man-hours in them are now fucked up...  Cool.  Me... we clear the books and start her up again.  It would take you longer to rent the miners than it would be for me to freeze/reset our books. Traders may get excited and cause the price to go up (Look at Monero, 18 blocks reorged and the price spikes?)... or they may get scared and smash her down.  I don't know.  Why stir the pot when they are reasonably well behaved? (Edited due to post above quoting this line) When you've got enough bitcorns and balls to hypothentically fuck over a bunch of innocent folks, because of me or whatever, go for it.