I suppose if we figure out how to make click-to-pay work for both the "I'm using an online wallet service" and the "I'm using the client" cases, then users won't have to know how to copy&paste addresses and human-type-able addresses won't be critical.

RE: DoS resistance:  please DO keep thinking about it; I'm not a networking expert (in fact, if you know any networking experts, see if you can get them thinking about it....).

Good idea.  I opened a feature request at https://github.com/bitcoin/bitcoin/issues/100

Clearcoin now supports sending unreleased coins to a charity instead of refunding them, which gives both buyer and seller the same incentives.

Crashing bugs, any bug that might result in loss of bitcoins, and security fixes are always highest priority, but here are the big things I think are very high priority that, as far as I know, nobody is working on.  I think they all need to be done before we can say we have a "Bitcoin 1.0" :

• finish download-only-blockheaders client mode
• password-protect the wallet private keys (mitigate the steal wallet.dat problem: see https://gist.github.com/803170 )
• import a backed-up wallet
• figure out how to do click-to-pay
• design/implement a secure DNS-like "map string to bitcoin address" system  (so I can send bitcoins to "gavin@acm.org")
• export+encrypt part of your balance (for long-term storage; I still waffle on whether we want to encourage that right now)

The tag is v0.3.20.2, and it is signed by my (gavinandresen@gmail.com) gpg key.

RE: roadmap for v0.4 :  I worry that we'll spend time creating a roadmap and then... people will work on whatever strikes their fancy.  So the 0.4 release will end up being completely different from what the roadmap says.

That said, I'll start a roadmap thread; maybe we CAN all agree on priorities and find people to actually work on the highest priority stuff.

The maxsendbuffer bug (0.3.20.1 clients not being able to download the block chain from other 0.3.20.1 clients) was only going to get
worse as people upgraded, so I cherry-picked the bug fix and created a minor release yesterday.

The Amazon Machine Images I used to do the builds are available:
(mac build will be done soon)

If you have already downloaded version 0.3.20.1, please either add this to your bitcoin.conf file:
... or download the new version.

fopen() is a standard C library call; it is weird Bitcoin can't find it.

Is anybody else running bitcoin on OSX 10.5 ?   I'm running 10.6.6; Laszlo does the OSX builds, I'll ask him what he's running.

I was editing the bitcoin.org homepage to update the download links, and I couldn't resist make a few changes:

• I removed the "If you are running version 0.3.9 or earlier please update" message.  People running really old versions of bitcoin SHOULD update, but there is no longer any security risk if they don't.
• I replaced "there were X blocks as of Y date" with a link to jgarzik's Bitcoin Watch site.
• I made the SHA1 checksums at the bottom of the page tooltips of the download links.  I think it is easier to match up checksums to filenames that way, and I think it looks less intimidating for people who have no idea what SHA means.

PS:  I read the thread about replacing the self-signed bitcoin.org security certificate, and agree that needs to be done...

Nice analysis!  I'm tempted to put a link to your post in the code as a comment...

The whole transaction prioritization scheme was written by Satoshi after I suggested that de-prioritizing "small new" transactions might help the spamming problem.  In the last couple of days we've exchanged email about possibly modifying it; pull request 88 is the first suggested change (it makes the CreateTransaction fee calculations match the CreateBlock calculations).

Until somebody finishes implementing lightweight 'headers-only block download', we should try to keep block size small-- otherwise new users will have to wait an even longer time before being able to use bitcoin.

Also:  the Faucet is now paying a 0.01 BTC fee per transaction.  With the CreateTransaction fix, it probably would be anyway (the transactions it creates look very spammy).

I wouldn't have any objections to changes that let you decide which input transactions or receiving addresses to choose when sending coins, as long as it is well-tested, follows the coding guildelines (see coding.txt in the source directory)  and it doesn't make the "I just want to send some coins" case look more complicated (maybe hide it behind an Advanced... button in the Send dialog).

fread failed means bitcoin couldn't read some data off of your hard disk.

You might want to invest in a copy of SpinRite and check your hard disk for errors.

There was a good Skeptoid podcast about it.

Our brains are really good at pattern-matching, and are really good at fooling us into seeing patters where none exist.

Please help test:  https://github.com/bitcoin/bitcoin/pull/95

Sets the -maxsendbuffer and -maxreceivebuffer limits to 10MB each (so possible max of 2GB of memory if you had 100 connections).

I tested by running a 0.3.20 node to act as server, then ran a client with:
  -connect={server_ip} -noirc -nolisten
... to make sure I was downloading the block chain from that 0.3.20 node.

500MB per connection times 100 connections would be 50 GB.  That re-opens the door to a memory exhaustion denial-of-service attack, which is the problem -maxsendbuffer fixes.

As transaction volume grows I think there will be lots of things that need optimization/fixing.  One simple fix would be to request fewer blocks as they get bigger, to stay inside the sendbuffer limit...

(ps: I've been re-downloading the current block chain connected to a -maxsendbuffer=10000 0.3.20 node, and the workaround works)

Huh?  See that 'import json' statement at the top?  That would be the standard (as of python 2.6) JSON parsing library.

The code I posted tells the standard JSON parsing library to read JSON Numbers as Decimal.  If you are doing monetary calculations in python, then you should be using Decimal.  That is what it is for.

Oops.

My fault-- I DID test downloading the entire production block chain with a 0.3.20 client, but I wasn't careful to make sure I downloaded it from another 0.3.20 client.

Workaround:  if you are running 0.3.20, run with -maxsendbuffer=10000

You can't open and close the file; it is not thread-safe (thread one closes fp and sets it to NULL and sleeps, thread two wakes up and uses a NULL fp).

And you can't wrap the open/close in a CRITICAL_SECTION, because logging happens at shutdown, CRITICAL_SECTION relies on a destructor to work properly, and you can't control the order in which C++ destructors are called during shutdown.

I learned all that the hard way a few releases back.

You can rotate the logs using the "copytruncate" feature of logrotate.

genjix: here is how to do it right in Python2.6 :

Produces output:

Note that EVEN IF YOU PASSED THE 'WRONG' strings to Bitcoin, Bitcoin would do the right thing. That is, these two are equivalent once they are parsed by bitcoin:
... because bitcoin does proper rounding.

On the bitcoin side, this is a non-issue.  And if code on the other end of the JSON-RPC connection does the wrong thing (truncates values like 10.000999999999999 instead of rounding them to the nearest 8'th decimal place) then that's a bug in that code.

Wiki page created:  https://en.bitcoin.it/wiki/Proper_Money_Handling_(JSON-RPC)

genjix:  You should be calling json.loads(..., parse_float=decimal.Decimal) and use a custom JSON encoder class to convert decimals to JSON strings with no loss of precision...

Can we not beat this dead horse?

I think there are MUCH more important things to work on / worry about than whether or not "send 1 BTC" is expressed as "sendtoaddress FOO 1.00" or "sendtoaddress FOO 100000000" in the JSON-RPC.

How about we (I'll start) write a "Proper Money Handling" page for the Wiki that discusses the issue and gives code example of how to convert to/from JSON double-precision floating point and 64-bit integer?