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+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/bitcoindev/8E819BCF-EEAE-4F10-89A1-FA3FDE0F67E3%40sprovoost.nl.

Reply via email to