The only thing stopping me from announcing 0.3.20 "Final!" is confirmation from Windows users that switching to the mingw build process fixed the rendering issues.

So:  if you're a Windows bitcoin user, please install the latest 0.3.20 from SourceForge and let me know how it works for you.

Version 0.3.20.01 is now at:
  https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.20/

Differences with the first release candidate 0.3.20:

+ Windows built with mingw instead of Visual C++ (my fingers are crossed that fixes the rendering issue)
+ Fix for a denial-of-service attack reported in IRC

I've generated lots of blocks on the new -testnet.

I've made public the windows, linux32 and linux64 Amazon Machine Images used to build bitcoin 0.3.20.  If you have an Amazon EC2 account, you can launch them and have your own working build environment for linux or windows bitcoin (paid for by the hour).

They are:
  ami-4adf2c23        32-bit Linux (Ubuntu 9.04)
  ami-12df2c7b        64-bit Linux (Ubuntu 9.04)
  ami-7a21d213       Windows (with MinGW)

All created in the us-east-1b zone (I don't know if Amazon automatically migrates public AMIs across the world).

After launching the Linux VMs, you login as root (using the ssh keypair you specify when you launch).

After launching the Windows VM, you connect via Remote Desktop and then login as Administrator, password "bitcoin development" (you should change that for your instance as soon as you login, of course).

They contain bitcoin, bitcoind, and everything needed to build them, already built.  You could launch instances and try to generate coins, but that's not cost-effective.

(Updated 22 Feb with 0.3.20.01 Windows AMI)

I just committed (to git and svn) an updated build-msw.txt
Thanks to m0mchil for putting together a working windows/mingw build environment.

And I'll be making the 0.3.20 build environment virtual machines (for Windows, Linux32, and Linux64, in the Amazon EC2 cloud) public, hopefully, if all goes well, later today.

The linux binaries are built on Ubuntu 9.04; that's the earliest ubuntu that has all the required dependencies.

Ubuntu and Debian are kissing cousins; Debian 5 would be a good choice if they don't have an Ubuntu that's more recent than 8.10.

No, but there should be.

Proposal:  treat immature coins as starting with -100 confirmations, and modify listtransactions to list immature category=generate coins (with negative confirmations).

There's probably an off-by-one-error lurking there... (will have to make sure the coinbase transaction is spend-able when it goes from -1 to 0 confirmations).

First, "potentially forking" changes like that would be structured as:

if (block number < SOME_BLOCK_NUMBER_IN_THE_FUTURE)
  ...old rules
else
  ...new rules

Assuming a super-majority of people agree with the change and upgrade before we get to SOME_BLOCK_NUMBER_IN_THE_FUTURE, the switch will happen smoothly.

Is there a chance of changing?  Sure, but I think anybody who wants to make such a fundamental change would need to do a LOT of testing-- maybe spin up or recruit a few hundred machines all over the world on a test network, have them mine and simulate transactions to each other (ideally with similar volume to the real network) while going through the transition and making sure there weren't any unintended consequences.  And convince a super-majority of people that the benefit of their potentially forking change outweighs the risk of disrupting the network if there's some consequence they didn't think of or that their test network didn't simulate properly.

Practically, would dropping the block time from 10 minutes to 1 minute be worth the risk?  I doubt it.  1-10 minutes (1 would be the average, get unlucky and it could take 10) is still too long to wait for small-value in-person transactions.

RE: democratic organ:  bitcoin is a kind of a democracy.  Whatever code the majority of miners/nodes is running makes the rules.

Update on the problem and release:

m0mchil reports no rendering issues running a 0.3.20 bitcoin compiled using the mingw toolchain, and has volunteered to document/setup the build environment (in an Amazon EC2 virtual machine that I'll make public so it'll be easier for anybody to get a working bitcoin windows build environment up and running).

And responding to alkor:  Windows/Mac open source coders seem to be a lot rarer than Linux... which is not surprising, I suppose.

PS to genjix:  Looking good!  I'll try to find some time to give it a try (I don't know Qt programming so I probably won't be able to help code, though).

Sure.   sirius:  after getting the 0.3.20 release out, I want to work with you (and everybody else) to make the bitcoin.org website more newbie-friendly.

Huh.

I live next to a major research university, and at least around here people get PAID to participate in psychological experiments.

Not the other way around.

So I guess my short answer would be "no".

Thanks for all the positive feedback!

And ribuck's right-- when I first started putting together the talk there were about 5 million bitcoins worth about 2.5 million dollars.

By the time I gave it, they were worth about 4 million dollars.  And two days after I gave it bitcoins hit $US 1.00 ...

The 5-minute Ignite! talk I did about Bitcoin is up:
  http://blip.tv/file/4771178

It was mostly what I wanted to say; I think I ended better than I started.  My slides and script
with exactly what I planned to say are here:
  http://www.skypaint.com/bitcoin/GavinIgniteTalk.pdf

Feel free to remix it.  If I ever do another Ignite! talk (they're 5 minute talks with slides that auto-advance ever 15 seconds) I'll plan to say less, try to interact with the audience more, and may hire somebody (with bitcoins, of course) to replace my text-heavy slides with more pretty pictures.

One more thought:  the "finney attack" can only be profitable if the reward from cheating is greater than (reward of mining times the probability your block will be rejected because you delay announcing it while you "run down to the store").

Reward for block is currently $50, that will (hopefully!) continue to rise for the next decade or two.

Say it takes you 5 minutes to complete a transaction at the corner store (half the average block gen time)... today you'd have to make a $25-or-greater purchase just to break even.

Seems likely this attack will be completely impractical for transactions under $200 when the block reward is worth more than $400.  0-confirmations (just wait N seconds to look for a quick double-spend) for any transaction under $200 seems "good enough" to me.

I'm lost.  Who are X and Y?  You're going to spam the network with payments to X == yourself and Y == the corner grocery store in the hopes of... what?

Remember the original attack:
Again, it seems to me some rules that make attempted double-spends more costly to those who attempt to pull off double-spends might be a good idea.

theymos' objection (that there's no real incentive for miners to try to detect/punish double spends) is worth thinking about.  Is there enough "interest in the common good" for miners to spend some CPU cycles so that the bitcoin system as a whole is more robust, or would self-interest lead to a tragedy of the commons where miners do the absolute minimum to just get their blocks accepted?


bfever:  my gut reaction is that the "fast payment problem" won't be solved by more complicated transactions.  And my gut reaction to more complicated transactions is that that the more complicated something is the more likely it is to have security holes....

There is a bug in the 0.3.20 candidate release that causes rendering issues on Windows.

I have no idea how to fix it; I don't even have a real Windows machine on which to test it (I built 0.3.20 on an Amazon EC2 windows virtual machine).

Anybody willing to step up and fix it?

If nobody steps up and commits to continuing to develop the wxWidgets GUI, we may have to stop supporting/developing it and start releasing only bitcoind.

2.1 quadrillion basic units should be plenty.  The US M2 money supply is (according to Wikipedia) less than 1 quadrillion pennies.

If bitcoin is ever twice as popular as dollars, that would be a very good problem to have.

The help text is misleading; never pass the "foo=" part.

Somebody could teach bitcoin to accept either  getreceivedbyaccount foo 10    or    getreceivedbyaccount address=foo minconf=10
... but maybe we should just change how the help text shows default arguments or improve the documentation.

I think it is a reasonable assumption that major miners will be well-connected with each other.  There is certainly a strong incentive for miners to be well-connected in general (better connected == more likely to win 'block races').

So I don't see how you could freeze the block chain-- if you generate lots of double-spends, the miners will quickly see both of spends and will drop those transactions like hot potatoes.  The "finney attack" only works if the first double-spend is generated by a miner that finds a block and includes it in the block without transmitting it.

Also, my proposal was to only reject blocks containing 'suspicious' transactions that you hadn't seen transmitted that have a double-spend attempt before the next block.

I'd just like a rational system where policy changes are proposed along with specific, testable predictions for those policy changes.

Then the policy change is adopted.  Evaluated after a little while.

And accepted or rejected based on whether or not the policy change had the intended effect.

Then maybe we could take turns adopting our favorite policies, and see if that nice liberal "inequality reducing" policy actually, you know, reduces inequality (and we could argue about whether it is OK to do if it reduces inequality by making rich people a lot less rich and poor people a little more poor).

Or if that nice libertarian "cost saving" policy actually, you know, saves money (and we could argue about whether the cost savings is worth it if it increases our chances of getting a scalp infection from an unlicensed barber).