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

... or, in other words:  have you thought about what will happen when somebody buys a bunch of bitcoins from you and then disputes the charge on their credit card?

Or worse:  buys a bunch from you, turns around and sells them to you.  Waits a day.  Does it again.
And then disputes all the charges at the end of the month...

I am not a lawyer.

But if you generated bitcoins and then sold them I'd think you'd only done something illegal when you fail to declare that income on your income tax return.  Just like if you grew tomatoes in your back yard and sold them to somebody.  You aren't likely to get into any trouble until you make a lot of money on tomatoes and then fail to report that income to the IRS (or you get shut down for farming in a residential zone or something).

I think that applies to what madhatter is doing (taking payment for bitcoins through the mail).  But again, I am not a lawyer.

I am not a lawyer.

But it looks to me like No, just running Bitcoin doesn't make you a "money transmitting business."  To be a "business" you have to be charging people for your service.

If you're running Bitcoin to buy or sell goods or services in exchange for bitcoins, I'd say you're not in the money transmitting business.

However, if I were to start a company in the business of buying and selling Bitcoins, or that was a Bitcoin payment processing intermediary that took a percentage of transactions between buyers and sellers, I'd talk to a lawyer and jump through all the legal hoops (looks like here in Massachusetts I'd need a license and would have to post a $50,000 bond).

Or to put it in more concrete terms:  I am not a money transmitting business when I use my credit card to pay for something from Amazon.com.
And Amazon.com is not a money transmitting business just because they accept payments.

However, Amazon Payments, Inc. (Amazon's Paypal competitor) is licensed as a money service business in a bunch of US states.

I think bittorrent would be a really good model to follow.

But it's not the only path to success; Perl is a good example of a successful technology with One True implementation and no specification beyond the One True implementation.

Then again, development of Perl 6 seems to be going really slowly.

And I think breaking up the functionality is a really good idea.  For example, if the algorithm for signing transactions and the format for public and private keys were standardized it would be possible to create a Bitcoin iPhone app that stored the private keys (wallet) on the phone and submitted signed transactions to a proxy that was connected to the p2p network.

I see the functionality broken out into these pieces:

1. p2p nodes that are constantly connected and relay blocks and transactions
2. transaction monitoring ("tell me when there are new transactions that match some set of criteria")
3. new block monitoring ("tell me when there are new blocks that match some set of criteria")
4. transaction validation (answers question "is this transaction valid, and how many validations does it have?")
5. block validation ("is this block valid, and how many validations does it have?")
6. bitcoin mining: race to generate a new block and earn ฿
7. wallet storage (generate new addresses, and store their public/private keys and any transactions that correspond to them)
8. generate new transactions (sign ฿ with private key(s) and submit to p2p network)

I did some research into money exchanging and money transfer regulations in the U.S.

The raw legal code is online at:  http://www.access.gpo.gov/nara/cfr/waisidx_08/31cfr103_08.html

I am not a lawyer; trying to understand legalese is just an odd hobby of mine.  From my reading of the regulations, if you exchange less than $1,000.USD worth of Bitcoin per day you don't have to worry:


It looks to me like if you exchanged more than $1,000.USD per day a good lawyer might be able to argue that Bitcoins do not meet the legal definition of "currency":

Then again, if Bitcoins are not legally "currency" then it might be left up to a Court to decide what, exactly, they are, and the result might be really unpleasant (if a judge decided that they're like stocks and are therefore subject to regulation by the Security and Exchange Commision you might find yourself in jail for being an unlicensed stock broker).

I think Bitcoin needs some licensed, regulated exchanges that abide by all the regulations, treating Bitcoins just like another foreign currency, and make it really easy to buy or sell a few hundred dollars worth of Bitcoins.  The regulations are not as onerous as I expected; basically you just have to get identification from customers that make large transactions and report them.