18-21 August works for me.  New York City in August: ah, I can smell it now....

RE: changing the confusing transaction fee message:  good idea, and yes, "we" can.

How about:

This transaction requires a transaction fee of at least 0.0N because of its amount, complexity, or use of recently received funds


I don't want to use the word "recommend", because the GUI doesn't let you try to send them without a fee.

We've already got ParseMoney in util.cpp, this patch adds parseNumber/uriParseAmount.  Having more than one way to convert strings into bitcoin amounts is not a good idea, in my humble opinion.

Also, instead of having a separate executable it would be more 'wxbitcoin-like' to have one executable that acts as either client or server depending on what command-line arguments are given.  The problem with two executables is you'll have clueless users double-clicking on bitcoinuri.exe and then wondering why it doesn't do anything.

I do like the use of boost message queues to communicate.

Actually, Clearcoin only requires 3 confirmations.

And now that I've got some pressing core bitcoin stuff off my plate, I'll get back to working on a -testnet version of Clearcoin, and as soon as that is done I'll be announcing a JSON-RPC API so you can write code that interacts with clearcoin (creating escrows, getting their status, releasing coins if you're properly authorized, etc).

After putting together the 0.3.21 release candidate today, I'm thinking after 0.3.21 is out the door it might be a good time to do a major source tree re-org.   I like the idea of following the GNU directory layout standard, and it would make my job easier if source was in src/, readmes/etc were in doc/, scripts to automate the Windows build were in build/, etc.

PS: jaromil is the second person I've heard who says they'd prefer a development mailing list.  I don't care one way or another, but it would be easy to create one using SourceForge's mailing list feature.  What do others think?

Linux and Windows binary releases are at:
  https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.21/

Changes and new features include:

• Support for Universal Plug and Play to open a port for incoming connections (off by default, turn it on using the -upnp=1 command-line switch or the checkbox on the Options dialog box).
• Sending and displaying arbitrary precision amounts of bitcoins (you can send exactly 1.0001 bitcoins if you like).  Sending less than 0.01 bitcoins requires a 0.01 bitcoin fee, however.
• New rpc command "sendmany" to send bitcoins to more than one person in a single transaction (already being used by some of the mining pools for payouts).
• Several bug fixes, including a serious intermittent bug that would sometimes cause bitcoind to stop accepting rpc requests.

If you find bugs, report them at: https://github.com/bitcoin/bitcoin/issues

This is a single-line change that allows non-standard transactions to get into the transaction memory pool (and, therefore, relayed and written into blocks) on -testnet.

Satoshi suggested this to me in an email a few weeks ago, and I agree it is a good idea-- we should encourage people to experiment on -testnet with new features, or they will figure out less efficient ways of wedging what they want to do into the existing standard transaction types.

The 0.3.21 release (I hope to have a release candidate available today) will support full-precision values-- you will be able to send 1.00123456 BTC, if you like.

Sending less than 0.01 BTC still requires a 0.01 BTC fee, though.  Changing that to "sending less than 0.01 BTC requires a 0.001 BTC fee" might be worth thinking about, but I think there are higher priorities on the core bitcoin TODO list.

It is a Berkeley DB binary database file.

https://github.com/gavinandresen/bitcointools  has fairly easy to read python code for parsing it-- see
https://github.com/gavinandresen/bitcointools/blob/master/wallet.py

Nope, penny-flooder.

Run the gui with the -server switch.

Yup, although I'd like more brains to think it through-- are there any potential denial-of-service attacks if bitcoin is listening for RPC commands by default (note that JavaScript in your web browser CAN access http://localhost:8332/, the same-origin-policy for JavaScript doesn't apply to localhost URLs)?

Does it open up any extra security holes if you're on a multi-user system?

And I don't think it should go into mainline bitcoin until there is a compelling need for it-- and I don't think there will be a need until the 'click on a link, popup payment dialog from bitcoin' functionality is worked out...

It might make more sense to allow non-sensitive RPC commands to function without a password.  Where "non-sensitive" would be getblockcount/getdifficulty maybe getnewaddress/getaccountaddress and a new 'you clicked on a bitcoin: URI so popup a payment confirmation dialog'.

"Making it easier for other applications to integrate with bitcoin" is bad if the other applications are trying to steal your wallet, so I'm reluctant to have bitcoin do things like create passwords for users.

I pulled a patch that makes Linux/Mac bitcoin/bitcoind write a bitcoind.pid file when started with the -daemon switch (and erases it on shutdown).

Next release will have several changes to make startup on Linux/Mac more unix-standard-like.

When you launch your instance, make sure the firewall ("Security Group" in AWS-speak) is setup to allow remote desktop access from your machine's IP address to port 3389.

I run Remote Desktop Client on my Mac, but the process should be the same on PC.

Connect using the "Public DNS" machine name-- something like:   ec2-184-2-91-236.compute-1.amazonaws.com

Login as Administrator, password:    bitcoin development

(I just launched the 0.3.20.2 Windows AMI to get ready to build a 0.3.21 release candidate).

Thanks for the suggestions and comments, everybody; I think a combination of dropping the faucet reward again (I'll start bundling up faucet payments into 'sendmany' transactions, so the transaction fees are lower) and "community watch program" will work.

The 'community watch' will be a web page that anybody can see that shows the last 100 IP addresses that got payments along with an obfuscated version of the email address (I'll obfuscate by randomly turning an email address like 'gavinandresen@gmail.com' into 'gavniadresen23@gmail.com').  And I'll recruit some trusted people and give them access to a master faucet shut-off switch if it starts getting abused again.

It always bothered me that the MySQL's SELECT... LIMIT statement could skip records if the database was changing between calls, but that doesn't seem to bother anybody else.

This patch is very much like MySQL LIMIT, is needed for the same reason (paging through results efficiently in a GUI), is backwards compatible, and looks good to me.

There are actually a few different ways to get a negative account balance.

1. As theymos said, the "" account is special, and can go negative if you use sendtoaddress instead of sendfrom.

2. Other accounts can go negative if they receive coins on a bitcoin address, you send those coins from that account, and then you use setaccount to re-assign those received coins to some other account.

3. They can also go negative by the transaction fee amount if you sendfrom the coins in an account and the send needs a transaction fee.

Also as theymos says, you can never send more coins than are in your total wallet.  And it should ALWAYS be true that the sum of coins in all accounts equals the number of coins you can send.

You're right-- full-precision is in git-head, but wasn't in 0.3.20.  It will be in 0.3.21.

No, they don't.