TEST network, for experimental development and hacking

[Gavin Andresen]

I went ahead and created a modified Bitcoin client with a brand-new block chain and a few other changes (detailed below) that will make it independent of the "production" Bitcoin network.

I intend to use it to test out some code I'm writing for my next project; I don't want to accidentally break (or slowdown or otherwise interfere with) the real Bitcoin network.  It should also be useful for anybody who wants to see if they can purposely break Bitcoin (for the purposes of a security audit).

Code is hosted at github: http://github.com/gavinandresen/bitcoin-git

Patches to go from 'production' bitcoin to 'TEST network' bitcoin are also at github: http://gist.github.com/502460

... so go nuts and start hacking.

Changes are:

+ Listen port is 18333 (instead of 8333).  Uses 18332 for JSON-RPC (instead of 8332).
+ Uses irc.lfnet.org channel #bitcoinTEST  for bootstrapping.
+ Never tries to connect to "well known" nodes for bootstrapping.
+ Uses bitcoinTEST for the default data directory (e.g. ~/.bitcoinTEST on Linux, %APPDATA%/BitcoinTEST on Windows, etc)
+ Uses a different ADDRESSVERSION for Bitcoin Addresses (0xff instead of 0x0), so you can't screw up copying and pasting Bitcoin addresses (if you try to use a TEST address on the production system it will tell you it's invalid; you can, however, lose TESTcoins by trying to send them to a valid production address)
++ Has a brand-new block chain (with a different genesis block)
++ Initial difficulty is 4 times easier than production Bitcoin
++ protocol message header bytes are { 0xfa, 0xbf, 0xb5, 0xda } instead of { 0xf9, 0xbe, 0xb4, 0xd9 }

(16 July: "++" stuff added in response to the suggestions below in this thread)

A very generous TEST Bitcoin Faucet is running at: https://freebitcoins.appspot.com/TEST/

I think the TEST and production GUIs don't play well with each other; at least on my Mac, I have to quit the "real" bitcoin before running TEST.  That's probably an easy fix, I just need to figure out how...

[1714960152]

1714960152

[1714960152]

1714960152

[1714960152]

1714960152

[SmokeTooMuch]

make a windows binary and I'll be insta-testing

[bdonlan]

Changing the genesis block would be a VERY good idea - better yet, change the protocol version as well. This will help avoid the possibility of the two networks merging (peers do exchange address lists...)

[jib]

Yeah, change the genesis block. At the moment if someone connects a test client but gives it the data files from a real client then the real block chain will be longest and will spread throughout the test network, right?

[Gavin Andresen]

Very good point about the genesis block.

Unfortunately, I'm not exactly sure HOW to generate a valid genesis block; I can tweak the data but need to generate a valid block hash... hmm, I see some time in gdb in my near future...

RE: changing the protocol version:  Good Idea, too.  Every wire protocol message starts with the bytes '{ 0xf9, 0xbe, 0xb4, 0xd9 }', I'll tweak that in the TEST code so TEST and production clients can't talk to each other even if they manage to get connected.

[bdonlan]

Very good point about the genesis block.

Unfortunately, I'm not exactly sure HOW to generate a valid genesis block; I can tweak the data but need to generate a valid block hash... hmm, I see some time in gdb in my near future...

It should be sufficient to just change things to invert the hash in the prevBlock pointer or something... Then the genesis block doesn't need to change.

[Gavin Andresen]

It's ALIVE!



Source on git now has:

+ different genesis block
+ ridiculously easy minimum proof of work threshold
+ protocol message header bytes are { 0xfa, 0xbf, 0xb5, 0xda } instead of { 0xf9, 0xbe, 0xb4, 0xd9 }

If you compile and connect and turn on coin generation you'll generate a lot of play money quickly...
(I've turned off generation, but will keep my three clients -- two Linux, one Mac -- connected)

[bdonlan]

It's ALIVE!



Source on git now has:

+ different genesis block
+ ridiculously easy minimum proof of work threshold
+ protocol message header bytes are { 0xfa, 0xbf, 0xb5, 0xda } instead of { 0xf9, 0xbe, 0xb4, 0xd9 }

If you compile and connect and turn on coin generation you'll generate a lot of play money quickly...
(I've turned off generation, but will keep my three clients -- two Linux, one Mac -- connected)

870 blocks already? How long will that take to bootstrap once it gets going?

[EricJ2190]

MSVC9 won't accept the fact that pnSeed[] in net.cpp is empty. It fails with the message "error C2466: cannot allocate an array of constant size 0".

edit: After looking at pnSeed[]'s purpose (network bootstrapping), I added a single value of 0 to it which allows it to compile past that point.

edit2: It compiles fine now, but for some reason won't run. It does absolutely nothing when the EXE is run.

edit3: Nevermind. It is working now. Not sure why it wasn't before.

[Gavin Andresen]

I know EricJ2190 tried out the test network today-- Eric (and anybody else who might have compiled and run) you need to git pull, recompile, and nuke your ~/.bitcoinTEST directory.  The client was generating blocks WAY too fast.

That'll teach me to go messing with code I don't really understand (on the bright side, I now know what the OpenSSL BN_bn2mpi() routine does).

Oh, and Eric:  I added your pnSeed fix to my git branch.

[XaviorPenguin]

Well poo.  If I knew how to compile a Windows binary, I would and start testing for ya.  I wouldn't mind being a node/connection to help out in the network at all.

[bdonlan]

I'm working on an alternate bitcoin client and I'd like to try it on the test network. Is there a list of bootstrap hosts for the test network somewhere, so I don't need to implement an IRC client at this point?

[Gavin Andresen]

I'm working on an alternate bitcoin client and I'd like to try it on the test network. Is there a list of bootstrap hosts for the test network somewhere, so I don't need to implement an IRC client at this point?

The TEST Faucet will be running on host:  li133-197.members.linode.com
(starting tomorrow, if all goes as planned).  You can connect to it to bootstrap.

[bdonlan]

I'm working on an alternate bitcoin client and I'd like to try it on the test network. Is there a list of bootstrap hosts for the test network somewhere, so I don't need to implement an IRC client at this point?

The TEST Faucet will be running on host:  li133-197.members.linode.com
(starting tomorrow, if all goes as planned).  You can connect to it to bootstrap.

*waves from across the rack*
I couldn't wait, so I set up a node on my own linode as well. You can connect at fushizen.net. Currently my custom client isn't doing much more than maintaining a connection - figuring out how to decode and verify the block chain's probably going to be a weekend project (or two).

[Gavin Andresen]

TESTcoins are maturing, and the TEST Faucet is open and giving out 50 TESTcoins per visit:  https://freebitcoins.appspot.com/TEST/

Feel free to grab some play money any time; there's no coins-per-IP-address limit, but you will have to solve the CAPTCHA if you revisit.

[knightmb]

The client was generating blocks WAY too fast.

My bad, I'll restrict the 32 core systems to doing the main bitcoin generation next time instead of seeing what would happen at the beginning of a test network  

[EricJ2190]

I modified my test client to handle full precision values.

http://github.com/EricJ2190/bitcoin-git/tree/fullprecision

[ArtForz]

Generated blocks 992 - 2016 in 2h15 min
Sent 3 largish transactions to the test faucet.

[lfm]

I was unable to build the test network version on a system where the standard version builds ok. (both v. 0.3.6)

It seems it is a problem with boost 1.35. Its an older Ubuntu (9.04) system.

I tried to get boost 1.40 but I failed. It conflicts with installed stuff or something.

[Gavin Andresen]

Can you be more specific about where your build fails?  Is it in the new code to support the -port / -rpcport options (which I should have put on a different git branch) ?

[lfm]

Can you be more specific about where your build fails?  Is it in the new code to support the -port / -rpcport options (which I should have put on a different git branch) ?

# make -f makefile.unix bitcoind
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I"/usr/include" -I"/usr/local/include/wx-2.9" -I"/usr/local/lib/wx/include/gtk2-
unicode-debug-static-2.9" -o obj/nogui/util.o util.cpp
In file included from headers.h:71,
                 from util.cpp:5:
/usr/include/boost/interprocess/sync/file_lock.hpp:166: error: ‘bool boost::interprocess::file_lock::timed_acquire_file_lock(boost::interprocess::file_handle_t, bool&, const boost::posix_time::ptime&)’ cannot be overloaded
/usr/include/boost/interprocess/sync/file_lock.hpp:110: error: with ‘bool boost::interprocess::file_lock::timed_acquire_file_lock(boost::interprocess::file_handle_t, bool&, const boost::posix_time::ptime&)’
/usr/include/boost/interprocess/sync/file_lock.hpp:194: error: ‘bool boost::interprocess::file_lock::timed_acquire_file_lock_sharable(boost::interprocess::file_handle_t, bool&, const boost::posix_time::ptime&)’ cannot be overloaded


... and so on for a long-long time

[Gavin Andresen]

That IS part of the new -port / -rpcport code (I use boost::interprocess::file_lock to make sure bitcoins running on different ports don't try to use the same wallet/blkindex/etc files).

I'll create an svnTEST branch that omits those changes, and will always be just a TEST-network version of the latest svn trunk.

[Gavin Andresen]

svnTEST branch is up on github.

I also uploaded just the production-bitcoin-to-TEST-network-bitcoin patches to github, at: http://gist.github.com/502460
... so:

Code:

curl http://gist.github.com/raw/502460/2182724de9ef2d6721bf0e0962cc6a6895bcbee4 | patch -l

... should patch production network source code to TEST network.  And:

Code:

curl http://gist.github.com/raw/502460/2182724de9ef2d6721bf0e0962cc6a6895bcbee4 | patch -l --reverse

... will go the other way.

[lfm]

That IS part of the new -port / -rpcport code (I use boost::interprocess::file_lock to make sure bitcoins running on different ports don't try to use the same wallet/blkindex/etc files).

I'll create an svnTEST branch that omits those changes, and will always be just a TEST-network version of the latest svn trunk.

So if I just grab the .tar.gz from github will I get this? I haven't figured out git and/or svn yet really

[lfm]

nevermind now, it seems like the stadard 0.3.7 has incorporated your changes for ports and now It won't build on the old boost version either. Ill need to figure out some other solution.

[Anonymous]

http://bitcointalk.org/index.php?topic=997.msg13237#msg13237

An officially supported fork so that companies can pay the bitcoin network in transaction fees and allowing bitcoin as an accepted payment method in exchange for certification and ongoing support.After all who knows the most about bitcoin and could make sure nothing funky was going on ?

 Why dont we take advantage of the fact that the users of bitcoin are the best ones to "certify" forks of bitcoin?

This secondary "virtual currency" implementation could be run on each separate website and allow proprietary networks to be developed while promoting bitcoin as an accepted payment method. If we do this before a company such as facebook makes the first move it could be a smart move.
In effect bitcoin would establish itself as the certifying authority on future forks of the project.

[WNS]

Have the specs for testnet changed? I'm not getting any block chain data when I attempt to connect with bitcoind 0.3.21

[dserrano5]

Have the specs for testnet changed? I'm not getting any block chain data when I attempt to connect with bitcoind 0.3.21

I get all 22683 blocks correctly. Now I expected to generate some coins in a couple of minutes...

[ene]

Have the specs for testnet changed? I'm not getting any block chain data when I attempt to connect with bitcoind 0.3.21

Testnet was reset recently with a new genesis block. If you have any data from the old testnet e.g. C:\Users\Owner\AppData\Roaming\Bitcoin\testnet you should delete it, otherwise your client will be confused and refuse to download any blocks.

[neosam]

Hi all,

I have started the bitcoin client in testmode two hours ago.  It's mining for 1 1/2 h at 200 kHash/s but I didn't get any coins yet.  But I need playmoney to do some test transactions.   Am I doing something wrong?  I use the original bitcoin client version 0.3.21-beta on ubuntu 11.04 (started with ./bitcoin -testnet).

Cheers,
Simon.

[dserrano5]

I recall having read something about a couple of days somewhere in this forum, don't ask me where exactly...

Or you may use the bitcoin test faucet, although that will only give you around 0.11 BTC currently.

[Gavin Andresen]

Testnet faucet is up and running if you need testnet coins:
  https://testnet.freebitcoins.appspot.com/

Although I've mostly been using testnet-in-a-box for testing recently:
  https://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/

[neosam]

Super, thanks!

I always tried https://freebitcoins.appspot.com/test/ but the page is down.   https://testnet.freebitcoins.appspot.com/ works!

Thanks!

Cheers,
Simon.

[cuqa]

hey, I wanna build a pool frontend and set up a server w/ pushpool which is running in testnet currently.

I mined all night and some hours today, summed up maybe 10 hours with 35 Mhash/s and I havent solved a single Block. Usually I should create 1 Block every 30 minutes so I start to think that I did something wrong.

What could be the problem? Everything seems to work fine except that I dont receive any Test Coins.

However, I havent switched any ports in server.json or bitcoin.conf ..

[ene]

cuqa if I had to guess, I would say you are accidentally mining on realnet instead of testnet. ;-)

[seer]

I have to say testnet is getting hard to generate coins/blocks or something is wrong. I am hardly getting any blocks coming in so my transactions are not processing so i moved my miner that does 650Mhash/s onto the testnet network.  This is saved setting that worked in the past and normally generate the coins in 3-15 min.  So far it has been 40 min with no coins generated and only 1 other block coming in from the network.  Looks like it will take me about 80 min to test a single transaction at the min. 

Wish i could use testnet in a box but using multiple machines linux and win plus need to use custom build of the client on the backend.

Is this just because the difficulty on the testnet is getting too high?  Couldn't it be set lower so more blocks come out and people can do tests faster?

[dbitcoin]

I have to say testnet is getting hard to generate coins/blocks or something is wrong. I am hardly getting any blocks coming in so my transactions are not processing so i moved my miner that does 650Mhash/s onto the testnet network.  This is saved setting that worked in the past and normally generate the coins in 3-15 min.  So far it has been 40 min with no coins generated and only 1 other block coming in from the network.  Looks like it will take me about 80 min to test a single transaction at the min.  

Wish i could use testnet in a box but using multiple machines linux and win plus need to use custom build of the client on the backend.

Is this just because the difficulty on the testnet is getting too high?  Couldn't it be set lower so more blocks come out and people can do tests faster?

Use this with modified configs:

https://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/

[Furyan]

What exactly are the use cases for the TEST network?

Should I use it when setting up a new pool, for example, to make sure everything is running correctly? Or is it intended more for miners & ecommerce apps that will be consuming bitcoins?

[gmaxwell]

What exactly are the use cases for the TEST network?

Should I use it when setting up a new pool, for example, to make sure everything is running correctly? Or is it intended more for miners & ecommerce apps that will be consuming bitcoins?

"Yes". Its for testing.


Though, at the moment the testnet difficulty is high enough again that its less useful for any kind of testing that requires mining.

[Furyan]

What exactly are the use cases for the TEST network?

Should I use it when setting up a new pool, for example, to make sure everything is running correctly? Or is it intended more for miners & ecommerce apps that will be consuming bitcoins?

"Yes". Its for testing.


Though, at the moment the testnet difficulty is high enough again that its less useful for any kind of testing that requires mining.

So if I run bitcoind in testnet mode and it downloads the block chain, and then I switch to the live chain, what happens?  What do I need to delete/reset/watch out for?

And vice versa - what if I've already downloaded the live block chain and switch to testnet mode.

[EricJ2190]

So if I run bitcoind in testnet mode and it downloads the block chain, and then I switch to the live chain, what happens?  What do I need to delete/reset/watch out for?

And vice versa - what if I've already downloaded the live block chain and switch to testnet mode.

Bitcoin uses a different default location for the testnet blockchain and wallet, so you can switch between networks freely.

[Furyan]

So if I run bitcoind in testnet mode and it downloads the block chain, and then I switch to the live chain, what happens?  What do I need to delete/reset/watch out for?

And vice versa - what if I've already downloaded the live block chain and switch to testnet mode.

Bitcoin uses a different default location for the testnet blockchain and wallet, so you can switch between networks freely.

Awesome, thanks.  Pool's all set up... testing now.

Only took one day. Not bad.

[Furyan]

Hmm.. odd but testnet won't work for me:

Code:

./bitcoind -daemon -testnet -rpcuser=hungry -rpcpassword=forfood -rpcport=8332

results in the following log:

Code:

Bitcoin version 0.3.25-beta
Default data directory /home/randomuser/.bitcoin
Bound to port 18333
Loading addresses...
dbenv.open strLogDir=/home/randomuser/.bitcoin/testnet/database strErrorFile=/home/randomuser/.bitcoin/testnet/db.log
Loaded 0 addresses
 addresses                28ms
Loading block index...
LoadBlockIndex(): hashBestChain=00000007199508e34a9f  height=0
 block index               0ms
Loading wallet...
nFileVersion = 32500
fGenerateBitcoins = 0
nTransactionFee = 0
fMinimizeToTray = 0
fMinimizeOnClose = 0
fUseProxy = 0
addrProxy = 127.0.0.1:9050
 wallet                   44ms
Done loading
mapBlockIndex.size() = 1
nBestHeight = 0
setKeyPool.size() = 101
mapPubKeys.size() = 102
mapWallet.size() = 0
mapAddressBook.size() = 1
0 addresses found from DNS seeds
ThreadRPCServer started
sending: version (85 bytes)
pv4 eth0: MYSERVERIP
addrLocalHost = MYSERVERIP:18333
ThreadSocketHandler started
ThreadIRCSeed started
ThreadOpenConnections started
ThreadMessageHandler started
connect() failed after select(): No route to host
IRC connect failed
IRC waiting 71 seconds to reconnect
ThreadRPCServer method=getinfo
keypool reserve 2
keypool return 2

at which point bitcoind simply hangs and no blocks are ever downloaded.

The sticky part appears to be the inability to connect to MYSERVERIP:18333.  I've just replace MYSERVERIP there.  No, that doesn't show up as 127.0.0.1 or localhost.

What is going on here?

[error]

Hmm.. odd but testnet won't work for me:

Code:

./bitcoind -daemon -testnet -rpcuser=hungry -rpcpassword=forfood -rpcport=8332

results in the following log:

Code:

Bitcoin version 0.3.25-beta
Default data directory /home/randomuser/.bitcoin
Bound to port 18333
Loading addresses...
dbenv.open strLogDir=/home/randomuser/.bitcoin/testnet/database strErrorFile=/home/randomuser/.bitcoin/testnet/db.log
Loaded 0 addresses
 addresses                28ms
Loading block index...
LoadBlockIndex(): hashBestChain=00000007199508e34a9f  height=0
 block index               0ms
Loading wallet...
nFileVersion = 32500
fGenerateBitcoins = 0
nTransactionFee = 0
fMinimizeToTray = 0
fMinimizeOnClose = 0
fUseProxy = 0
addrProxy = 127.0.0.1:9050
 wallet                   44ms
Done loading
mapBlockIndex.size() = 1
nBestHeight = 0
setKeyPool.size() = 101
mapPubKeys.size() = 102
mapWallet.size() = 0
mapAddressBook.size() = 1
0 addresses found from DNS seeds
ThreadRPCServer started
sending: version (85 bytes)
pv4 eth0: MYSERVERIP
addrLocalHost = MYSERVERIP:18333
ThreadSocketHandler started
ThreadIRCSeed started
ThreadOpenConnections started
ThreadMessageHandler started
connect() failed after select(): No route to host
IRC connect failed
IRC waiting 71 seconds to reconnect
ThreadRPCServer method=getinfo
keypool reserve 2
keypool return 2

at which point bitcoind simply hangs and no blocks are ever downloaded.

The sticky part appears to be the inability to connect to MYSERVERIP:18333.  I've just replace MYSERVERIP there.  No, that doesn't show up as 127.0.0.1 or localhost.

What is going on here?

The important part being:

connect() failed after select(): No route to host

So either your network is down, or something is blocking your connection to IRC.

[etotheipi]

EDIT: Okay I didn't realize this thread was started a year ago... I thought Gavin was proposing a NEW test network, a third one on top of the production and test networks already there.  Please ignore this message.

As someone interested in developing a new client soon, can you tell me what is the difference between this new network, and the previous test-network?  I mean, I thought that's what the test network was for... right?

In other words, what are the use cases for the two networks?
-Eto

[Furyan]

The important part being:

connect() failed after select(): No route to host

So either your network is down, or something is blocking your connection to IRC.

I checked the log and the IRC connection fails even for the live connection.  However, the key part actually seems to be this:

Code:

0 addresses found from DNS seeds

For the live connection, this list is not empty (it has 48 addresses). If I operate on the assumption that the live connection was NEVER able to connect to IRC, then it got that seed list from somewhere.

[gim]

Code:

0 addresses found from DNS seeds

For the live connection, this list is not empty (it has 48 addresses). If I operate on the assumption that the live connection was NEVER able to connect to IRC, then it got that seed list from somewhere.

There is no DNS seeding available for the testnet work. Current options are IRC connection or using static --addnodes.

[Furyan]

Code:

0 addresses found from DNS seeds

For the live connection, this list is not empty (it has 48 addresses). If I operate on the assumption that the live connection was NEVER able to connect to IRC, then it got that seed list from somewhere.

There is no DNS seeding available for the testnet work. Current options are IRC connection or using static --addnodes.

Fantastic, that's what I was missing, thanks!

[haydent]

ive had my client in testnet mode for some time and it says 14 connections but the initial 1000 blocks hasn't changed...

does it normally take ages at moment ??

[haydent]

restarting it worked, its away now

[piotr_n]

testnet seems to be pretty useless ATM because it doesn't introduce new blocks with a reasonable intervals.
you want to test something and you have no idea how long you will need to wait for a new block.