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)

There's a stackoverflow question about double hashing, by the way.  Consensus is that it's not less secure.  It's too late for my brain to process the nuances of hashing...

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.

Yep, Americans have been getting a really sweet deal from the Chinese for a while now-- we send them pieces of paper with dead presidents on them (well, the electronic equivalent) and they send us all sorts of useful stuff.

If I understand correctly, you've got two chances to find a collision instead of one.

So this decreases the security of SHA256 by a factor of 2... which is just Not a Big Deal.  Bitcoin is using, essentially SHA255 instead of SHA256.  It'll still take longer than forever to find a collision...

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

Ok.

As long as I get eleven.

(it's my favorite number)

So about two hours ago (8AM EST, 24 July) I see a big spike in traffic to the Bitcoin Faucet:


What's up with that?  The slashdot effect was just tapering off...

Thanks Xavier!

To everyone else:  the Faucet is now giving out bit-nickels; it just went under 500 BTC.  I've got just under 2,000 BTC left to refill it, but I think I'll start letting it drain a nickel-at-a-time and keep it above zero for as long as I can (refilling it to just under 500 if it gets near zero).

5 lots (25 BTC) on 011 please.

Eleven is my favorite number.

My point was that if "they" mount an attack, I think they're unlikely to do something subtle like try to mess with the block chain.

If "they" want to mess with the network, it would be far easier to do something like what China's doing with its Great Wall-- forcing connections they don't like to be dropped.  Or what botnets do now:  mount a denial-of-service attack by flooding the network.

Much more likely:  "they" will catch you for tax evasion when you convert your bitcoins to your local fiat currency and buy that fancy sports car you've always wanted.

Making it easier for merchants to accept bitcoins, and users to pay using them, aught to be priority number 1.

There's a great talk by the CTO of Facebook available on Youtube, and I think he gave the right advice on scaling:
Don't worry much about it until just before it becomes a problem.  Don't overengineer, because you're likely to waste time doing something that turns out to be irrelevant.

I think Satoshi has done an amazingly fantastic job; over the last two days of Bitcoin being "slashdotted" I haven't heard of ANY problems with Bitcoin transactions getting lost, or of the network crashing due to the load, or any problem at all with the core functionality.

Yes, it's annoying to have to wait for the block chain to download (especially with the Microsoft Security Essentials weirdness), and yes it would be nice if all the pieces of Bitcoin functionality were already nicely separated and ready to be rearranged and extended in all the ways we all want to rearrange and extend it.  But I've been poking at the Bitcoin code for over a month now, and the more I learn the more impressed I become at the thought that's gone into it.

This quote seems appropriate:
"We reject: kings, presidents and voting.
We believe in: rough consensus and running code."  -- David D. Clark

Yeah, that would be a good problem to have.

Why would they mess around with the block chain, though?  Are you imagining the men in black double-spending enough Bitcoins to make merchants think it is untrustworthy? ("I shipped 100 computers to Langley, Virginia when the transaction had six confirmations, and now there's a new block chain that says those coins were paid to somebody else!!!")

I'm imagining:

A lightweight client would have a wallet with coins in it (public+private key pairs).

And a secure way of sending messages to, and getting messages from, any of the ultra-fast, always-connected heavyweight nodes.

The lightweight client sends money by:
  creating a transaction (signing coins with the private key)
  sending the signed transaction securely to the ultra-fast server, which puts it on the network.
  receiving confirmation that the transaction was valid and sent, and updating its wallet (marks coins as spent)
   (or getting a "you already spent those coins" error from the server)

The lightweight client receives money by:
  Either polling the server every once in a while, asking "Any payments to these BC addresses that I have in my wallet?"
   ... or asking the server to tell it whenever it sees a transaction to a list of BC addresses (or maybe when it sees
    a relevant transaction with N confirmations)
  When transactions occur, the lightweight client updates its wallet (adds the coins).

You don't have to trust the server; it never has your private keys.

Well, you do have to trust that the server doesn't lie about whether your transactions are valid or not, but why would the server lie about that?

No, actually, in the current source code it never gets lowered:
There's no "else if (bnNew < ...something)"

UPDATE:  rodin is right, I'm wrong.  bnProofOfWorkLimit is a constant, and this code just make sure the proof of work never gets too easy.

That sounds about right.

So a million transactions a day would be 600 million bytes.  600 megabytes a day, 18 GB a month.

That's not bad.  Actual network bandwidth will be higher (the way the network is connected you get the same transaction multiple times from your peers).  You won't be running an always-connected-network node on your iPhone, but any low-cost server will give you twenty times that bandwidth per month.  And 18GB isn't much disk space in these days of terabyte hard drives.

A million transactions per day is a LOT!  For comparison, in 2006 there were about 60 million credit card transactions per day in the US.

Eventually, if Bitcoin survives and gets as popular as credit cards for paying for stuff I expect somebody will create a compatible version with a more efficient network structure (maybe by that time there will be some fancy IPV6 multicast protocol or something).  And they'll implement a couple of gateway nodes (running on really fast connections) that shuttle transaction and block traffic from the current Bitcoin network into the super-efficient network.  And I expect most of us will be running lightweight clients that just keep our wallets, sign transactions, and send and receive transactions to the ultra-fast nodes that ARE looking at every transaction.

You know, kind of like how we have those Big Routers in the Sky that handle Internet backbone traffic (or the ultra-fast DNS root servers).  The Internet didn't start out with astoundingly fast routers zinging packets around.

... like how the RIAA screws around trying to disrupt BitTorrent swarms...

Umm, good luck with that.  I'm betting The Swarm will win most of the battles.

After he's downloaded all 66,312 blocks and is up-to-date, transactions are very fast.

Thanks for the donations... whoever you are who donated!

The Faucet has about 2,000 coins in it at the moment; I just deployed a new version that will automatically start giving out bit-nickels if the balance falls below 500 (but allows anybody who gets a bit-nickel to come back later and get the 5 bitcoins "they deserve" if/when the Faucet is refilled).

Yeah, I could, but it seemed like more trouble than it was worth; if you got coins from the Faucet into a non-empty wallet and then donated them back there's no guarantee that the donation back would be the SAME coins.  I just don't want to deal with a lot of "I got five coins and then sent back ten but I still can't get more from the Faucet...."