Transactions with "0 confirmations" are transactions that your client has seen, but haven't been put into a block yet.

Here's what happened when you bought the bitcoins:

Seller:  "Hey Bitcoin Network!  These here Bitcoins are getting sent to that there Bitcoin Address!"

Your client, listening in on all the payment network messages:  "Wow, spiffy, that's one of MY Bicoin Addresses!  I'll add that transaction to my wallet, and show that transaction as 0/unconfirmed in the UI."

Then your client goes on its merry way downloading the 66,241 blocks in the block chain.

In the meantime, some lucky soul generates block number 66,242, and includes your transaction in that block.  When your client connects that block up to the block chain (which it won't do until it gets all 64,241 previous blocks), it'll show it as "1/unconfirmed"

Then 2 confirmations when block 66,243 gets generated, etc.

Wonky things can happen if two nodes generate a different block 66,241 (especially if one of them included your transaction and one of them didn't, you can go from 1/unconfirmed back to 0/unconfirmed for a little while), but after a couple more blocks get generated everything sorts itself out.

First: it looks like we're in the middle of our first Bitcoin Bubble.  Price today went from about 0.8 US cents to 1.4 US cents on the Bitcoin Market.  Maybe the price won't crash back down... will be interesting to see what happens.

Second, RE: lending:  I think it's going to be really hard to establish enough trust to create a lending bitcoin bank.  I base that on my experiences dabbling as a Prosper.com lender; when hard times hit, repaying your Bitcoin debts will be WAAAAY down on the priority list.

Instead, I think we'll see Ponzi schemes masquerading as lending banks.  Buyer beware!

That's when I sleep!  Meeting whenever is most convenient for Satoshi makes sense to me.

Sure, you could build specialized hardware that computed SHA256 hashes faster than ANYBODY!
And then you'd be able to generate most of the bitcoins.

So:  how much would it cost you, in dollars or euros-- and don't forget to pay yourself for the time needed to design and build such a system?

Because you'd be able to generate, at most, 50 bitcoins every 10 minutes or so.  Soon after you started generating, all the other nodes on the network notice that bitcoins are being generated quicker than normal and increase the difficulty of the problem being solved (you've gotta twiddle the block header more times to find SHA256Hash(block_header) < target_value ).

If Bitcoins become even more wildly popular, then maybe people will think they can profit by building or renting specialized hardware.  That would be a very good problem for Bitcoin to have.

The Bitcoin Faucet is handling the slashdotting really well... except that I'm running out of coins to give away.  over 5,000 have flowed out of the Faucet since I refilled it last night.

Any of you early adopters who generated tens of thousands of coins back in the early days, are you willing to send a few to the Faucet to be given away so more people can try out Bitcoin?  I know that most of them are likely to be lost (I suspect there a lot of slashdot lookey-loos who won't stick around long enough to spend their 5 bitcoins), but if that's the case then that'll just increase the value of your other bitcoins, anyway...

Fountain donation address is:  15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC

Depending on donations and how long the slashdotting lasts, I might have to start giving away bitnickels...

Reminder to anybody running a bitcoind server:   be sure the debug.log isn't filling up your server's disk.  With the slashdotting, now might be a good time to setup a debug.log housekeeping system.

I'm doing this on my Debian server:

My crontab:My bc_logrotate.conf file:

The fee is paid to whoever generates the block that the transactions are in, and that's random.

Your friend could run a node that refunds the fee, but unless your friend can convince a lot of other people to run nodes that do the same thing you're almost certainly going to end up paying the fee.

Remember that all transactions (even payments from you to your friend) are broadcast across the payment network; they HAVE to be, because if they weren't you could spend the same coins twice without getting caught.

But how would you distinguish between a legitimate micropayment-processing IP and a spammy "I want to make Bitcoin use so much bandwidth nobody is willing to run it any more" IP?

Really small micropayments seem to me to be a really hard problem, and I don't think Bitcoin should try to solve too many very hard problems all at once.

If you have finished downloading the "block chain" (the history of previous transactions) then you'll get your bitcoins right away.

If you haven't finished that initial download (if the "blocks" number at the bottom of Bitcoin is less than 65-thousand-something), then you'll get your free bitcoins as soon as you download the block containing that 5-bitcoin transaction.

By the time Bitcoins replace the Euro  I think most people will be running lightweight clients on wireless smartcards in their (physical) wallet that don't pay attention to every single transaction.

But that's WAAAY down the road.  And who knows, by then maybe we'll all have a hundred-gigabits of bandwidth in our pants.

From the source code:

It's a bad idea to try to break the "in-production" bitcoin network.

If anybody is starting serious work on either extending Bitcoin or developing compatible implementations or trying to break it by creating bad transactions, I think creating a "parallel universe" test network with its own block chain, data directory, etc makes sense.

Satoshi:  would you be open to a --testnetwork (or something) flag to bitcoin that swapped to an alternate genesis block, data directory, listen port and IRC channel?  Maybe with a really short average block generation time, too (like once per minute instead of once per 10 minutes) so everything happens ten times a fast to make testing quicker.
 

In a thread in the Bitcoin Discussion forum, dwdollar says:
I think it will be impossible to tell if a bubble&crash is "natural" or "the men in black helicopters manipulating the system."

Bitcoin will get mentioned someplace with lots of readers, a bunch of those readers will like the idea and try to buy Bitcoins, their price will rise which will draw even more people to "invest", which will drive the price up even more... until people decide that the price isn't going to rise any more and everybody rushes to sell before the price drops.  I predict there will be between one and five Bitcoin bubbles (price will double or more and then crash back down below the starting price) in the next four years .

What do you all think-- are bubbles and crashes a natural emergent property of markets, or would Bitcoin be immune if nobody were trying to cause a bubble?

I'm sure somebody somewhere would/will be happy to sell you bitcoins anonymously; just put cash and a bitcoin receiving address in an envelope and mail it.  The exchange (who you'd have to trust to actually send you the coins) takes the cash and send coins to the address.  They have no idea who you are, and your identity isn't linked to the coins.

Well, it isn't linked to the coins until you forget to turn on TOR or I2P before spending coins on something illegal.  Or you remain completely and utterly anonymous right up until you spend coins on something physical and have it shipped to your home address.  Or you arrange to have contraband "dead dropped" somewhere, and you get arrested when you go to pick it up.

None of which have anything to do with Bitcoins, and all of which seem to me to be more likely ways of getting into trouble than somebody managing to figure out that "transaction for purchase of illegal stuff" is linked to "Gavin purchased a bunch of Bitcoins from Bobby's Discount Bitcoin Emporium" last year.

Would the transactions on the other block chain be lost?

I thought they'd just be re-integrated into the new-best-chain (if they were valid), just starting with '1 confirmation' again...

Whatever mechanism is chosen, it had better not significantly slow down the network or client unless strong anonymity is required/requested.

I've tried I2P and Tor, and, for me, super-strong privacy isn't worth the performance cost.

Also, regarding forking the block chain by a network split:

It's only "really bad" if I can get away with double-spending some coins before the network merges again.
If I'm buying valuable stuff, then the merchants will likely require 6 confirmations before releasing the goods, so I'd have to be able to keep the network split for an hour or more.

Merchants will likely have very-well-connected, long-running nodes.  For example, the Bitcoin Faucet has 66 connections right now.  If I wanted to try to implement a "fork the block chain attack" I'd have to somehow manage to insert my "cancer nodes" in between two merchants that I want to rip off (I'll end up ripping off one of the two, because eventually one of the two double-spend transactions will "win").

I don't know enough about network analysis to figure out how many cancer nodes you'd need to have a significant chance of getting in between two merchants with 60+ connections in a network of (say) 1,000 non-cancerous nodes, but I bet it is a very large number.

The "scripting language" ("expression evaluator" would be more accurate) is a little stack-based intepreter that looks at lot like Forth.

So, for example, here's an example of a GENERATED coin getting spent:

TxIn:          73:3046...0f01
Prev.TxOut: 65:046d...bb9c CHECKSIG

That's intepreted as:
  PUSH a 73 byte value onto the stack
  PUSH a 65 byte value onto the stack
  call CHECKSIG.  CHECKSIG pops two values off the stack (public key and digital signature), then does the digital signature thing using the OpenSSL ECDSA_Verify() function.

An example of how bitcoin works on a bit-level:  Ok, I'll give it a shot.

Here's what the current best-block (according to my bitcoin client) looks like, dumped in a geek-readable format:

BLOCK 68fa61ac1f55a5787dfa0c75bc83e67376ae8356e6887a2ab74cdb0900000000
Next block: 0000000000000000000000000000000000000000000000000000000000000000
Time: Mon Jul  5 15:51:22 2010
Previous block: c18adb50289393b5a995b3506f039ac75e8de79f511515448811510200000000
3 transactions:
1 tx in, 1 out
['TxIn: COIN GENERATED coinbase:0442310d1c029c00']
['TxOut: value: 50.00 pubkey: 17sdrb1X7qpjPMJortqaNwWtBbtouSoJn2 Script: 65:046d...bb9c CHECKSIG']
1 tx in, 1 out
['TxIn: prev(580a...e82e:0) pubkey: (None) sig: 71:3044...db01']
['TxOut: value: 50.00 pubkey: 1FeFgJRvCYUTCBj1u696eL23xpAdNB4B8p Script: DUP HASH160 20:a09d...6d81 EQUALVERIFY CHECKSIG']
3 tx in, 1 out
['TxIn: prev(c0a0...6bc3:0) pubkey: (None) sig: 73:3046...0f01', 'TxIn: prev(f909...2493:0) pubkey: (None) sig: 73:3046...1601', 'TxIn: prev(bc0a...fe64:0) pubkey: (None) sig: 72:3045...6201']
['TxOut: value: 150.00 pubkey: 1BHxjkqPmtNdmJxLZgneijvGszRxM9hPkz Script: 65:04ee...1d02 CHECKSIG']

So:  that big long string of hex at the top is the block header's hash value.  Note that it ends with 8 zeroes; that's the proof-of-work  (my utility for dumping blocks doesn't bother dumping the Nonce values).

What's hashed in the block header?  The Nonce.  The block's generation time.  The previous block's hash.  And a hash of all the transactions in the block. (and probably some stuff I'm forgetting).

This block has three transactions in it.  The first is the 50.00 (which is really 5,000,000,000 of the smallest possible units) reward for finding/creating the block.  It can only be spent by whoever has the private key that matches the public key in the TxOut  (17sdrb1X7qpjPMJortqaNwWtBbtouSoJn2 -- you can think of public keys and bitcoin addresses as equivalent), which will be whoever generated the block.

The second is a payment of 50.0 from.... somebody... to... somebody.   How does Bitcoin know that transaction is valid?  Well, it:
 + Looks up the previous transaction.  That's the TxIn: prev(580a...e82e:0)  stuff-- fetch TxOut zero (which will be a coin generated txn) from previous transaction 580a....
 + EVALUATE(TxIn.pubkey + previous transaction TxOut.pubkey) and make sure it evaluates to true.  This is where the cryptography happens; the receiver uses the private key known only to them and provides a correct digital signature.

The third is a payment of 150.0 (three 50.0-value in, one 150.0-value out).

Clear as mud?

I've started reverse-engineering and documenting the wallet and block databases, and have written some Python code that deserializes many of the Bitcoin data structures.  I was going to let it ferment a little more before announcing, but Mr. Google will surely find and index it soon, and it should be a good head start for anybody who wants to start a Python bitcoin client.

Open source, MIT license, at:
  https://code.google.com/p/bitcointools/
  MOVED TO git:  http://github.com/gavinandresen/bitcointools

If you're worried about elliptic curve cryptography being broken, then don't store any significant wealth in Bitcoin.   Just like if you're worried about your (real, physical) wallet being stolen don't hold more cash than you need to get through a couple of days of purchases.

By the way: I think an economical method for separating gold atoms from seawater will be found before elliptic curve cryptography is broken (and I think both are unlikely in the next 25 years).