I've been tempted... but no, I'm more interested in doing web-based Bitcoin apps, and extending the existing C++ implementation's JSON-RPC API is a whole lot less work than re-implementing the whole shebang.

Great catch!  Simpler fix is to specify the BIO_FLAGS_BASE64_NO_NL in the rpc.cpp/EncodeBase64 function:

Well, at least do it on the TEST network FIRST!

If you manage to break the TEST network, it's a pretty good bet that you'll be able to break the production network.  If it doesn't break the TEST network, then I'd say go ahead and run against the production network to look for "scaling up" problems.

Answering my own questions:  Project using CMake

I looked at 'weechat'; they're migrating from gnu autotools to cmake (still support both, but recommend cmake).

So another +1 for cmake.

Is there something simpler than CMake that would work?

cmake-2.8.2.tar.gz - 5.1MB
cmake-2.8.2-Darwin-universal.dmg - 27.2 MB

Adding Yet Another Multi-Megabyte Dependency to build bitcoind seems like a backwards step to me.

What's the most popular build solution for other small-ish, successful open source projects?

They key bits of code are:
pchMessageStart are the four magic bytes, and those are written with FLATDATA.

The CBlock itself is written by << *this, and that's done by the IMPLEMENT_SERIALIZE in main.h:

The READWRITE macros Do The Right Thing, reading in or writing out the members in a machine-independent way.

See http://github.com/gavinandresen/bitcointools for simplified Python code that can dump out transactions and blocks.

If a philanthropist wants to give away bitcoins to the bitcoin community, I'd be happy to reset the Bitcoin Faucet rules to whatever the philanthropist would like.

Could be:  donate 10,000 Bitcoins and then have the Faucet distribute 10 per IP address (regardless of whether or not they got coins from the Faucet before) until they're gone.

Yes, that's right, rpcpassword is only required if you use -server or -daemon or bitcoind (I just tested to be sure).

RE: what if the programmer can't figure out how to make their legacy COBOL code do HTTP authentication?
Then I think another config file setting to explicitly turn off RPC authentication would be better than a magical "if you set a blank rpcpassword then that turns off authentication."   But I wouldn't implement that until somebody really does have a problem or until we have more than one way of doing the authentication (maybe https someday...).

lachesis: is supporting HTTP Basic Authentication a problem for you?

What's funny?

A server lying about whether or not your transactions are valid would be like your ISP lying about whether or not your HTTP requests are valid or not.

If they lie, you'll very quickly find another service provider (or download a Bitcoin iPhone app that doesn't suck and say that your transactions are invalid).

I strongly disagree; software should be secure by default, and running bitcoind without a password (or bitcoin -server) is definitely NOT secure.

I just don't see somebody saying "Man, Bitcoin sucks because I have to add a password to a configuration file before running it as a daemon."  I can see somebody saying "Man, Bitcoin sucks because I accidently ran it with the -server switch and somebody stole all my money."

OK, I did Python and PHP, and I added what I know about Java.  Can somebody who has used Java JSON-RPC update the wiki page with a working example?

I've updated the RPC wiki page for how the password stuff will work in Bitcoin 0.3.3.

One nice side effect: you can prepare for the changes now; create a bitcoin.conf file with a username and password and modify your JSON-RPC code to do the HTTP Basic Authentication thing.  Old code will just ignore the .conf file and the Authorization: HTTP header.

Question for everybody:  should I add a section to the wiki page describing, in detail, how to do HTTP Basic authentication?  PHP and Python make is really easy-- just use the http://user:pass@host:port/ URL syntax.  I don't want to just duplicate the HTTP Basic authentication Wikipedia page.

TxIn: prev(82df...6428:1) means the second TxOut of transaction 82df...something...6428  (it abbreviates the full 256-bit transaction hash and starts counting at zero).

To see that transaction:
This looks like bitnickels coins coming out of the Bitcoin Faucet.  The transaction before THAT is:

To compute the net transaction value, just add up the values of all the TxOuts; they have to equal the sum of all the TxIns (well, unless there are transaction fees).  So for that first transaction, 66.07+0.05 = 66.12 (which is, indeed, bfb0...cd16:1)

I think this won't work because there is not a one-to-one relationship between "unspent transactions" and public keys.

Example:  I start with 0 BTC.  Two people each send me 50, to the same receiving address "GavinPubKey".

Balance Sheet:  GavinPubKey: 100
I spend the first one:
Balance Sheet:  GavinPubKey: 50

If I'm dishonest, what stops me from waiting a few months and then spending that first 50 again instead of spending that second 50?  Double-spending that first 50 will look like a perfectly valid transaction to any nodes using the balance sheet method who weren't around to see the first time I spent it.

I've implemented it so that all the command-line options can also be specified in the bitcoin.conf file.

Options given on the command line override options in the conf file.  But I need to do more testing, especially with the "multiargs" options like "addnode".

I volunteered to implement this, and made good progress today.  Satoshi: I should have patches for you tomorrow.

Done: teach Bitcoin to read settings from {BITCOIN_DIR}/bitcoin.conf file, and added -conf=path_to_config_file.conf command-line option. 
Done: teach Bitcoin RPC to require HTTP Basic authentication, and reject requests with the wrong username/password.

TODO: teach Bitcoin command-line RPC to add the Authorization: header.  You won't have to give the username/password when controlling bitcoin from the command line, it'll read them from the bitcoin.conf file and Do the Right Thing.
TODO: dialog box or debug.log warning if no rpc.user/rpc.password is set, explaining how to set.
TODO: limit password guessing attempts if the rpc.password is < 15 characters long.
TODO: update the JSON-RPC wiki page

After all that is done and I've sent patches to Satoshi, I'm going to add a couple more things to bitcoin.conf :

port=   # to set the listen port (override default 8333)
rpc.port= # to set the JSON-RPC port (override default 8332)

With the existing -datadir option, that'll make it easier for me to run multiple bitcoins on one box.

chroot: won't protect you.

Running as a separate VM:  I think will protect you.  But I thought browsers wouldn't allow XMLHTTPRequests to "localhost" from web pages fetched from the web, so my advice would be to test it.  See if you can talk to the Bitcoin daemon from another VM on the same machine by running "bitcoind getinfo" or "bitcoin getinfo" on the non-bitcoin-vm.

You can still generate bitcoins, just don't run bitcoind or bitcoin -server or bitcoin -daemon on machine that you use to browse the Web.

As sirius says, if you do you could browse to a website that empties your Bitcoin wallet without your knowledge or permission.

I sent him 10 Bitcoins, and my hair grew back!

So I sent him 20 Bitcoins, and I won the lottery!

No Joke!!!!  Now I'm hairy and rich!!!!

I think there's no such thing a a "typical" settings file on Linux!

I just did a quick survey of 20 .conf files in /etc on my debian system, and found:
 1 file used "key value"
 5 used "key=value"  (actually, a couple were  "key = value", allowing whitespace around the "=")
 14 did their own thing.

The 14 that did their own thing were all over the map; from one-value-per-line to "key:value" to full-blown XML.  # is
the universal comment character in the Linux world.

My vote would be for:

# comment
key1=value1