Testnet utxos should be spendable by anyone after N blocks, for some large N #8956

As a modification of a suggestion from developer Rusty Russell, I suggest that testnet be hard-forked to allow anyone to spend any output older than N blocks, for some suitably large value of N like 26,208 blocks (nominally six months). This has at least three benefits:

1. Ensures testnet coins never have value. If coins can be trivially obtained by 'stealing' old outputs, there is no scarcity from which economic value might originate.
2. UTXO set reduction. There is presently no incentive for people to clean up their UTXOs after performing an experiment on testnet. It is good that the testnet block chain contains a record of all of these experiments, but it is not useful for the UTXO set to hold leftover outputs for perpetuity. All this does is increase the requirements of running a testnet node.
3. Perpetual faucet. It would be easy to write an RPC that claimed funds from expired UTXOs, eliminating the need for faucets or the generosity of others to obtain funds. This is particularly a concern now that testnet mining is basically centralized and individual cpu miners are unable to get test coins from mining blocks..

NACK

If UTXO bloat is an issue on testnet, I think that's a good warning sign for mainnet as well; I'd rather be able to point to testnet as an example for this kind of issue. In general, if we can't get sufficient testnet nodes due to scaling issues, that's a warning sign for Bitcoin as well.

Having said that, I do agree that in general we want to ensure that testnet coins remain valueless; a special "faucet" output that isn't removed from the UTXO set after spending it may be a good solution here.

Point 2 doesn't make sense if point 1 holds true.

@btcdrak I think @maaku is correct in his logic: with his proposed change, the incentive is mostly unchanged, but it becomes easy for anyone to clean up UTXO's created by others. Equally, if you are short of coins, grabbing someone else's UTXO is an easy way to get them (though that will likely be a minor incentive compared to simple altruistic cleanups).

@btcdrak can you explain? @petertodd With respect, the purpose of testnet is not to be some sort of cautionary tale for mainnet. The purpose of testnet is testing and experimentation. High availability and low variance in running requirements cause less headaches for people.

I do think @petertodd and @maaku have valuable points here. However, I've long through that a single testnet can't fullfill all functions we want from a testnet. In particular, I think it's worthwhile to have a network where extreme network and/or chain conditions occur (partitioning, huge reorganizations, slow blocks). On the other hand, I would also like to see more businesses and software authors provide testnet versions of their services, where users can actually test interaction with those services. The latter is not very appealing when the network is a wild west.

Note that I want this for DIY testnets, where it makes more sense. In particular, Lightning and any layer-2 development would have benefit from a predictable, stable testnet.

However, I've long through that a single testnet can't fullfill all functions we want from a testnet.

I tend to agree. I also don't think it should be up to us define all kinds of testnet that should be possible. In the future I'd imagine it'll be possible to load some chainparams from a .json file, which defines the rules and settings to join an arbitrary testnet (e.g. @jtimon's #8855 would be a first step there). (of course the individual rules would have to be part of bitcoin core, but a testnet could pick and choose either wild-west conditions or stable as possible ones or any combination)

"Wladimir J. van der Laan" notifications@github.com writes:

However, I've long through that a single testnet can't fullfill all functions we want from a testnet.

I tend to agree. I also don't think it should be up to us define all kinds of testnet that should be possible. In the future I'd imagine it'll be possible to load some chainparams from a .json file, which defines the rules and settings to join an arbitrary testnet (e.g. @jtimon's #8855 would be a first step there). (of course the individual rules would have to be part of bitcoin core, but a testnet could pick and choose either wild-west conditions or stable as possible ones)

In practice you need to change rpcport and port, as well as whatever rules are needed for the testchain. So I think a new conf is better than a json file.

My original idea was that you would give a genesis blockhash and DNS seed or manually addnode. The genesis block would tell you the other chain parameters.

Cheers, Rusty.

Please let's not get into a discussion of file formats. JSON was just an example as it is easy to support nested structures, and to generate from python. But I'm fine with whatever is implemented. As long as it is not ASN.1 I guess.

Closing for now. This should first be discussed on the mailing list. When and if an implementation (like signet) is ready, it can be considered for Bitcoin Core.