Works nicely on Linux, and is the recommended way to close dialogs.

Anybody able to give it a quick compile and test on Windows?

Weird.  Are you on Linux or Mac?  If you are, grab my bitcointools and run
  ./dbdump.py --wallet

... then look for:

nLimitProcessors:
  and
fGenerateBitcoins:

... and I just noticed an egregious bug:  listtransactions was reporting the receiving address instead of the account name for "receive" transactions.  Fix is svn rev 104.  Please bang on it and let me know if I screwed anything else up.

While I was committing, I also added "time" to transaction info output, and fixed a little bug reported a while ago (setgenerate true 0 is now the same as setgenerate false).

Just use transactionID+account.

You've already got the problem that if a customer sends coins from account A to an address that belongs to account B, that is a single, unique transaction that affects two accounts.

listtransactions will Do the Right Thing (generate two entries, different accounts, same transaction id).  And gettransaction won't lie to you (it doesn't say anything about what accounts were involved, on purpose, for exactly this reason).

No, only the amount sent to the address associated with the web app's account(s) will be reported in listtransactions.

But that's exactly why this is a lot harder than it seems-- we've got to think about weird transactions people might use to try to break websites that use this API.

Do you have gen=something in your bitcoin.conf?

Outputting the transaction time would be easy.

"The address that received funds" is not as obvious as you might think.  It is possible to generate transactions that are split and go to several addresses (well, it is possible if you use your own custom client, standard Bitcoin doesn't expose that feature).

Some or all of those addresses might be yours, and might be associated with any number of accounts.

I see two possible ways of dealing with this:

1. Generate multiple entries for a single transaction.  E.g. if you receive a split transactions, where 50 BTC goes to address '1aaa...' and 10 to address '1bbbb...', listtransactions will list that as two separate entries that share the same txid:

You can already get two separate entries for one transaction if you send to yourself, so this might be the best answer.  And it makes the common case simpler.

2. Or maybe 'toaddress' should be address:amount pairs, like this:

Writing all this down, I'm thinking that listtransactions aught to generate multiple entries, but gettransaction aught to generate address:amount pairs (and still omit category/account, as it does now).

move <fromaccount> <toaccount> <amount> [minconf=1] [comment]

minconf does what you want (gives an Account has insufficient funds error if not enough funds with minconf confirmations).

I just committed svn rev 103.  Changes are:

listaccounts :  lists all the accounts in your wallet along with their current balances.

listtransactions : call it with no arguments, or give it '*' as the account name, and it lists the last N (default 10, as before) transactions from all accounts.  Part of this change is disallowing '*' as an account name.

-rpctimeout : Thanks to Mt`AwAy who pointed out that, if somebody was allowed to connect to the bitcoin rpc port (via -rpcallowip), then they could connect, do nothing, and hang the connection, causing a denial-of-RPC-service.  Now bitcoin's RPC thread will close the connection if it doesn't get the HTTP request within -rpctimeout (default 30) seconds.

A big spike 18 hours ago, but then back to pretty much normal.

No, implementing it would be easy.  Implement it (don't forget the UI), test it on the test network (where it is pretty trivial to get non-IsStandard stuff into blocks), and then lobby for a new 'standard' transaction type.

theymos, please stop acting like the current IsStandard test is set in stone. It is not, and, as Satoshi said, new versions of the client are rapidly adopted by a majority of the network, so introducing a new transaction type will not be a big deal.

I deleted two posts-- one from you that was a quote of ByteCoin's simulation results (and nothing else).

And a second from ByteCoin (if I recall correctly), saying essentially "what's up with the empty post?"

Simplest way:

Call getaccountaddress "charity_name"  when you generate the web page.  You'll get the same address over and over, until somebody donates.  Then you'll get a new address.

Then periodically call:
  getbalance "charity_name"
... and if the balance is greater than zero, call:
  sendfrom "charity_name" charity_real_bitcoin_address amount

... to send the charity the accumulated coins.

If you deal with several charities this way, AND you're bundling up several donations before forwarding the coins to the charity, then it'll be hard to connect donors to particular charities.

If you're simulating, be sure you're not overlooking the 'opportunity cost' of working on the next-valid-block when you're 'holding back' blocks.

Example:

Cartel finds block N.  Instead of releasing it right away, Cartel holds it and starts working on block N+1 (trying to get a head start).

Before Cartel finds block N+1, somebody else finds an alternate block N and announces it.

IF Cartel loses the race to announce, then Cartel has wasted time looking for a block N+1 that will not be accepted.

If they simply announce block N right away, they'll never waste time trying to find a block N+1 that has only a 50% chance  of being accepted.

Unless the Cartel can propagate their blocks across the network faster than the whole rest of the network, there is never an advantage to holding back blocks.

There is something wrong with your simulation.  Proof:

Imagine a bitcoin world with two Cartels, each with 50% of the power, each following the strategy you outline.

It is obvious that they cannot BOTH get 59% of the blocks.

Did you simulate network connectivity at all?  Bitcoin is a semi-randomly connected network, where most of the connections are (I would guess) outbound connections from non-generating nodes who are sitting behind firewalls.  With a typical node having 8 random connections, to different /16 networks, it seems to me it would be pretty tough to get tight-enough control over enough network connections to consistently win the "announce a new block" race.

Anybody know how to estimate what percentage of connections the cartel would have to control to only lose the announce-a-block race 15% of the time?  It'll be way more than 15%....

What theymos said.  You're asking for the balance of the account named '1Fs5rqB2sXZ3kax1r3HfuYpK2ksSxLYJT8', and there is no such account.

Whether bitcoin should return an error (instead of 0) if you ask for the balance of a non-existant account is debatable...

If the hashing algorithms are broken I might be able to generate an ECDSA private/public key pair where the public key hashes to the same bitcoin address as one of your public keys.

If I can do that, then I can spend your coins.

On my list of things to worry about, this is just below "Asteroid impact destroys the earth" (but above "Aliens invade and make me their slave").

getaccountaddress is designed for exactly this kind of thing-- it will return the same address over and over, until it gets used (until somebody donates).  After that, it returns a different address...

Of course, if "the public" is grabbing the donation address off your "Donate to Us" page, they could generate a list of donation addresses, add up the donations received on all those addresses, and figure it out.  Depending on how many donations you're getting that might be easy (scrape the page once per day) or hard (if you're getting dozens of donations per day).

You could make it much harder for anybody to figure out how much you're getting in donations by randomly donating to yourself (using the same address returned by getaccountaddress), preferably from a wallet shared by lots of other people (like a MyBitcoin or Mt.Gox account)... 

Change "getnewaddress(label)"  to "getaccountaddress(label)" and you'll get the same address over and over, until somebody donates.  Then you'll get a different one.