I shoulda butted in, I think I'm too polite to be on a show with Jason Calacanis...

Extending the getnewaddress RPC call to take a [count] parameter would be easy.  Doing the same for the GUI would be pretty easy, too...

   https://github.com/bitcoin/bitcoin/pull/215

This pull is prompted by changes I'm making to ClearCoin, and should apply to any service where customers will owe the service bitcoins.   It removes the account balance checks from the RPC move command.

I'll use it to create accounts associated with users that keep track of how many bitcoins they owe; for example, if I owed 1 bitcoin ClearCoin will tell bitcoin:
  move 'gavinandresen' 'total_owed' 1.00

Assuming I'm not carrying a balance, that makes the gavinandresen account balance -1.00 BTC.  When I pay to one of the addresses associated with the 'gavinandresen' account, the account balance will be automatically credited.

If I were a professional accountant I probably would have written 'move' this way to begin with...

Have you done any benchmarking to see if that is true?

Fine, the entire transaction except for:
  "The scripts for all transaction inputs in txCopy are set to empty scripts"

... is signed.   You're starting to make me grumpy...

The entire transaction is signed.  See:  https://en.bitcoin.it/wiki/OP_CHECKSIG  for the rules.

Agreed; that is the longer-term goal.  This is a short-term fix.

No, it is not possible, there is a rule against that.

Collusion to gain oversized-profits never succeeds in the long-term, unless there are artificial barriers to entry (like government regulations).

I won't worry until our governments decide to pass the Officially Licensed and Inspected Bitcoin Generating Devices Law.

Will all of the internationalization/translations from the wxBitcoin port straight over to qtBitcoin?

No and no, in my opinion.

I think being able to explain the block reward as "starts at 50 every 10 minutes and is cut in half every 4 years" is a big advantage.  I like simple-- "the simplest possible solution that will work" is a good engineering rule of thumb.

Good idea:  https://github.com/bitcoin/bitcoin/issues/206

Why?  Thats years and years away.  I don't think any of us can predict exactly what is going to happen 10 or 15 or 20 years from now; I don't think it is possible to get a consensus now because there has never been a system like bitcoin before, so predicting how merchants, miners, and users will interact in 10 years seems to me to be impossible.

So:  do you think this supposed problem will happen all at once?  Or will it happen slowly over time?  If you think it will happen all at once, would there be any warning signs?  If it is a problem that we can clearly see coming, then there will be time to react.

I'm much more worried on the problems I see coming in the next year or two or three-- bitcoin-specific viruses and trojans, poorly coded bitcoin web services, and maybe bitcoin service operators getting charged with financial crimes that they didn't know they were violating.

They tend to get put back together when you send larger payments.

The algorithm that the current bitcoin client uses isn't the best possible algorithm for deciding when to combine or split coins; ideally, it would have some notion of how big your average transaction would be, and when sending coins it might split change or combine extra coins to make change that is about that big (so the next time you make a transaction there are old, previous, high-priority transactions it can use).

If you ask nicely, I bet tcatm or somebody else will create a little web service that could tell you how long you have to wait for a 0.10 (or whatever) coin to mature before you can send it without a fee.

Wednesday May 25'th bitcoin lunch in la Défense is on my calendar.

The networking code is the same in either case, so it was almost certainly just a coincidence and you got unlucky with the peers you connected to running -server from the command line.

The rules that the GUI (and bitcoind sends) follows to figure out if you should pay a fee are now the same as the rules in the block generation code.  The rules themselves didn't change.

I learned long ago that it is much better to create a sub-optimal system that is simple and robust than to try to create a perfectly optimal system.

Pretty darn good, with the right incentives in place to drive the long-term desired behavior, is good enough for me right now.  I think "we" have been pretty good at responding fairly quickly to problems as they appear.   I'm keeping a close eye on the free-transaction backlog, but I think tcatm's recent changes to http://bitcoincharts.com/bitcoin/ , showing transaction priority, and the recent change to the bitcoin client, so the default fee rules are the same for miners, relaying across the network, and the client, are working nicely.

If your 0.33 bitcoins came from one or two recent payments to you, then waiting a day or three to let the inputs "mature" will let you send them without a fee.  The transaction priority fee rules are designed to discourage people from sending lots of small bitcoin transactions in a short time.

If your 0.33 bitcoins came from 20 or 30 penny-sized payments to you, then you'll have to go to a lot of work to send them without a fee, because a 20- or 30-input transaction will be too big to qualify to be free.  The transaction size fee rules are designed to discourage people from wasting everybody's disk and network bandwidth by sending big transactions.

If you did receive lots of tiny payments, you can try to bundle them up in chunks-- you might be able to send three payments of 0.10 BTC without a fee (because each of them would be smaller than the "too big to be free" size).

But you should ask yourself:  is it really worth your time?  0.01 BTC is less than 5 US cents.  If it takes you more than 20 seconds to send 2 or 3 payments to avoid the 0.01BTC fee, then you're valuing your time at less than US minimum wage.

Priority is a function of how many bitcoins are involved in the transaction (more is higher priority), the size (in bytes) of the transaction (smaller is higher priority), and the age of the transaction's previous transactions (older is higher priority).

Your transaction is taking a long time because it involved only 0.14 BTC which you got from a transaction that happened earlier today.  If you were running bitcoin version 0.3.21, it would have required that you add a 0.01BTC fee to send it.