Topic: TEST network, for experimental development and hacking - page 3. (Read 27375 times)

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.

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.

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.

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

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)

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.

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.

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?

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...)

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

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...