Regarding testing, It is important for it to be done with a deterministic 
chain if you're building some kind of node.

But other things like wallets can easily mock the blockchain by having 
lists of static blocks with specially crafted transactions in them. It 
allows for things like signing to be tested without having to connect to 
some live blockchain RPC interface that might fail for some reason.

-Ali

On Monday, April 15, 2024 at 6:01:25 PM UTC Garlo Nicon wrote:

> > nothing stops people from using, say, regtest for that kind of testing.
>
> How can you test the scenario, where it is hard to get new coins, and you 
> have to get them from the current owners, by using regtest? If the 
> difficulty is absolutely minimal, and every second nonce gives you a valid 
> block hash, then you don't have to worry about your hashrate, because you 
> can always produce a new block, and publish your tests, no matter what.
>
> Also, if you have no difficulty adjustments, then you cannot realistically 
> see your hashrate, even on your CPU. You have to apply a lot of soft-forks 
> on regtest, if you want to check those cases. And you cannot test "getting 
> coins from the current owners" either, because regtest is not safe enough 
> to be deployed online, and you have to soft-fork it into signet, if you 
> want to do so.
>
> Which means, that if you want to test "how the network could behave after 
> many halvings", then testnet3 is a better choice than regtest (which you 
> cannot safely deploy online) or signet (which have less halvings than even 
> mainnet).
>
> And in general, I think it is a good idea, to have at least one test 
> network, which will have more halvings than the mainnet, so we can see in 
> advance, what could happen, before those problems will hit the main 
> network. By the way, when I think about it now, then my conclusion is, that 
> it would be nice, to even have a network, where timestamps are pushed 
> forward, and for example we could see year 2038 or year 2106 problem in 
> some test network earlier, than on the mainnet.
>
> sunday, 31 march 2024 at 23:30:04 UTC+2 Peter Todd wrote:
>
> On Sun, Mar 31, 2024 at 06:01:51PM -0300, Nagaev Boris wrote: 
> > > If we fix the difficulty reset bug, we might as well also fix the coin 
> supply 
> > > issue: get rid of the halving for testnet and just make every block 
> create new 
> > > coins. 
> > 
> > If such a change is made, then such a network won't be suitable to 
> > test halvings and software behaviour related to halvings. 
>
> I don't think that's very important. That's a very small part of what 
> testnet 
> is used for, and nothing stops people from using, say, regtest for that 
> kind of 
> testing. We already changed important consensus code around difficulty 
> with 
> testnet-specific behavior. 
>
> -- 
> https://petertodd.org 'peter'[:-1]@petertodd.org 
>
>

-- 
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 on the web visit https://groups.google.com/d/msgid/bitcoindev/664a3cd1-44d2-46d7-ae1a-2dca6f609b56n%40googlegroups.com.