"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:

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).

How often do you get the chance to work on a potentially world-changing project?

That would be awesome, it was the case in the previous unofficial patch.

The rest is scary though.

So that basically means that if you're relying on listtransactions to track incoming transactions to a web app account you're in deep trouble...

You just need someone to forge that kind of transaction, sending 1 BTC to an address that belongs to his account on the web app, and 99 BTC to one of his addresses for him to be able to withdraw 100 BTC :/

Even if such a withdrawal doesn't pass the "sendfrom" checks it's going to mess some things up like the account history display.(Assuming i'm regularly synchronizing the transaction history into my database).

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

You mean when using listtransactions <account> ?If so, that's good!

I'm still kind of worried about the duplicate ID thing, ok, here is an example.

A single transaction credits A and B addresses, both addresses are on my app on different accounts.Things are starting to get bad if I try to use the tx ID to match transactions that the client spits out to the transactions I record in my database since an ID isn't unique anymore.

Maybe a composite ID would solve the problem, anyway I think that if something is called ID it should be guaranteed to be unique (or collision likelihood should be limited to the probability of a hash collision)

Maybe a composite ID would solve the problem, anyway I think that if something is called ID it should be guaranteed to be unique (or collision likelihood should be limited to the probability of a hash collision)

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).

How often do you get the chance to work on a potentially world-changing project?