Testnet4 and Scalenet

Technical
#1

The main testnet for BCH, testnet3, has gotten bloated. People have used it for testing 32 MB block propagation for weeks on end. As a result, testnet3 now takes a long time to sync and is kinda annoying to work with. I think the problem here is that we’ve had two separate use cases for a testnet which don’t mesh well. I think we would be better served if we replaced testnet3 with two separate nets.

I propose we add two new testnets to BCH full nodes: testnet4 and scalenet.

testnet4 is optimized for convenience. It’s intended to be kept lightweight and quick to sync. Its main purpose is for compatibility testing and feature testing. Writing a new transaction script, and want to test it out? Developing a full node or a wallet, and want to make sure it speaks the p2p language correctly? Don’t want to bother with paying for a 1 Gbps pipe and 512 GB SSD just to make sure you can send a 200 byte transaction? If so, testnet4 is the place for you to be. testnet4 will come with a default 1.2 MB blocksize limit to discourage spamming, and a 1 hour ASERT half-life to make sure that it can recover to CPU mining quickly after anyone uses an ASIC.

scalenet will be the proving ground for high-throughput activity. Want to check how long it takes for your node to process a 128 MB block? Want to measure block propagation time? Want to spam stuff just for fun? Great! Scalenet is the place for you to be. Scalenet will be reset every 6 months or so (probably by changing a checkpoint block at e.g. height 10,000), so don’t worry about doing long-term damage to the syncability of scalenet. (Yes, this means that scalenet will not accurately simulate blockchain storage costs, but that’s easy enough to calculate manually, and is relatively uninteresting.) scalenet will have a default block size limit that is a few times higher than mainnet’s limit, and can serve as a proving grounds to determine when limit increases are safe for mainnet. ASIC mining on scalenet will be encouraged, and the ASERT half-life will be 2 days in order to allow accurate explorations of mining shenanigans (should anyone want do them).

Testnet4 is online already (though its parameters have not yet been finalized, and no seeders exist yet):

Scalenet is coming soon.

7 Likes
Staging CHIPs on Testnet
Staging CHIPs on Testnet
#2

Can you outline all of the proposed changes that the first iteration of the scalenet will have (compared to mainnet) so we can discuss if we think more or less things should be changed?

#3

Scalenet differences vs mainnet:

  1. Default blocksize limit: probably 256 MB

  2. 20-minute diff=1 rule

  3. Allow non-standard transactions

  4. History cleared every 6 months or so by replacing block 10,000

#4

Would you consider going up to 512 instead of 256?

#5

I would consider it, but I would like to hear reasoning.

My predisposition is that 256 MB will uncover plenty of issues, and that 512 MB will be unnecessary and possibly detrimental as a multi-node consensus rule over the next 6 months. I think that it’s likely that BU can handle larger blocks without much problem, but when node teams want to test things that it is known that other teams (e.g. Bitcore) will not be able to cleanly handle, I think the best approach on scalenet is to simply fork off with a larger blocksize limit for a while and run your tests. That way, you don’t disturb anyone else on the chain.

It’s a testnet with funny money. We don’t need to maintain consensus at all times.

We can also change it later. We don’t need to wait for a regular hard fork cycle to modify the scalenet consensus limit. All we need to do is get most of the people running active scalenet nodes to change their settings.

1 Like
#6

I dont think most of the full node implementations will break under 256 MB. I think all of them would break except for BU under 512 MB. I was thinking that the limit should be above what is able to be handled cleanly so that we are able to observe the “breaking point” but you make a good point that since this is a testnet with a lifespan of a couple of months at a time, this could cause more issues than the information it would provide us is worth.

You also make a good point about the smaller library stuff such as bitcore which i had not considered at all.

#7

We don’t have to actually break things on scalenet. All we need to do is to stress things enough so that we can (a) see where the pain points are, and see what would break if we push mainnet too hard, so that we can fix those things, and (b) to show what level of stress it can reliably handle without breaking.

That said, I don’t mind if things do occasionally break on scalenet. It’s an acceptable outcome, just not the actual goal.

2 Likes
#8

A draft of scalenet is online now. Parameters might change if deemed necessary. Please do not spam scalenet until we pass block height 10,000.

#9

I think the testnet4 parameters are now fairly final, right?
You might want to update the topic post (at the bottom).

#10

Hey!
Any news on Testnet4 seeders?

#11

testnet4:
vSeeds.emplace_back(“testnet4-seed-bch.bitcoinforks.org”);
vSeeds.emplace_back(“testnet4-seed-bch.toom.im”);
vSeeds.emplace_back(“seed.tbch4.loping.net”);

scalenet:
vSeeds.emplace_back(“scalenet-seed-bch.bitcoinforks.org”);
vSeeds.emplace_back(“scalenet-seed-bch.toom.im”);
vSeeds.emplace_back(“seed.sbch.loping.net”);

1 Like
#12

Overview Table

Attribute/Network testnet3 testnet4 scalenet
Default p2p port 18333 28333 38333
Network magic bytes 0xf4e5f3f4 0xe2b7daaf 0xc3afe1a2
CashAddr prefix bchtest bchtest bchtest
Default excessive block size 32MB 2MB 256MB
Block Target spacing 10 min 10 min 10 min
POW limit 2^224 2^224 2^224
ASERT half-life 1 hour 1 hour 2 days
Allow min diff blocks yes yes yes
Require standard txs no no no
Default consist. chks. no no no
Halving interval (blks) 210000 210000 210000
BIP16 height 514 1 1
BIP34 height 21111 2 2
BIP65 height 581885 3 3
BIP66 height 330776 4 4
CSV height 770112 5 5
UAHF (BCH fork) height 1155875 6 6
Nov 13 2017 HF height 1188697 3000 3000
Nov 15 2018 HF height 1267996 4000 4000
Nov 15 2019 HF height 1341711 5000 5000
May 15 2020 HF height 1378460 0 (Note 1) 0 (Note 1)
Base58 prefix: pubkey 1, 111 1, 111 1, 111
Base58 prefix: script 1, 196 1, 196 1, 196
Base58 prefix: seckey 1, 239 1, 239 1, 239
Base58 p: ext. pubkey 0x043587cf 0x043587cf 0x043587cf
Base58 p: ext. seckey 0x04358394 0x04358394 0x04358394

Table is from BCHN MR 813, I thought I’ll cross-post as a useful reference.

Note 1: set to 0 because historical sigop code has been removed from BCHN. The chainparams.cpp has more detailed comments.

1 Like
#13

Oh I got lost when the maximum block size on testnet4 went from 1.2 MB to 2 MB.
Was it discussed somewhere?

#14

Not really. I just made an executive decision at one point because I didn’t want to fiddle with the default maximum block generation size (which was 2 MB), since BCHN errors at startup if the default generation limit is larger than the excessive block size setting.

1 Like
#15

Noting these block explorer URL’s here so I don’t have to look them up elsewhere each time:

http://tbch.loping.net:3001/ (testnet3)
http://tbch4.loping.net:3002/ (testnet4)
http://sbch.loping.net:3003/ (scalenet)

2 Likes
#16

This table does not mention the time for the May 2019 upgrade (the one with Schnorr). Logically one may come to the conclusion that it would be between 4000 and 5000, but correctly validating nodes would reject this chain then since in block 181 Schrnorr signatures are already used.

#17

Thanks @tom for bringing this up.

Schnorr was part of the May 2019 HF, and the on/off logic code was removed from ABC (and therefore BCHN) in this commit:

Consequently, I think the May 2019 HF activation height should be specified at 0, the same as the May 2020 HF activation height, for both testnet4 and scalenet. @freetrader can you update the table and Note 1?

#19

I noticed yesterday that my SPV wallet had troubles connecting to testnet4.
After some digging it turned out that all the DNS seeders had empty host lists, while one had an IP that didn’t actually work.

So, I updated my Flowee seeder to become aware of Testnet4 and we now have testnet4-seed.flowee.cash as a new DNS seed.

The seeder for Flowee uses the P2P library in order to actually have a bare-bones client that crawls the network. The seeder will keep running every day and only the nodes that have the longest uptime will make it into the DNS seed.

We also seed mainnet on seed.flowee.cash.

1 Like
#20

Hi,

I am trying to integrate with testnet4 however I cannot find any faucets. Have any been created for testnet4?

Thanks

#21

If you post an address I can send you some coin.