Getting the address that received funds

[davout]

I can't see a way, using the latest API to get the address that received funds.

I can list the transactions for a given account, but even if I use gettransaction I can't see which address received the funds, nor can I see the transaction timestamp.

[1713952363]

1713952363

[1713952363]

1713952363

[1713952363]

1713952363

[1713952363]

1713952363

[1713952363]

1713952363

[Gavin Andresen]

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:

Code:

    {
        "category" : "receive",
        "amount" : 50.00000000,
        "txid" : "2c9d43db0142130a9926ef4b1c58abf17e8b4dfd2148bf2072b0df6d2bac8789",
        "toaddress" : "1aaa", ... etc, irrelevant fields omitted...
    },
    {
        "category" : "receive",
        "amount" : 10.00000000,
        "txid" : "2c9d43db0142130a9926ef4b1c58abf17e8b4dfd2148bf2072b0df6d2bac8789",
        "toaddress" : "1bbb", ...
    },

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:

Code:

    {
        "category" : "receive",
        "amount" : 60.00000000,
        "txid" : "2c9d43db0142130a9926ef4b1c58abf17e8b4dfd2148bf2072b0df6d2bac8789",
        "toaddress" : { "1aaa" : 50.000000, "1bbb" : 10.000000 }
    },

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

[davout]

Outputting the transaction time would be easy.

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

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...',

+1, that sounds like the most intuitive output

listtransactions will list that as two separate entries that share the same txid:

"different things sharing the same ID" sounds really bad to me
it could also be that each entry of listtransactions shows a composite ID


Anyway thank you for your precisions

[Gavin Andresen]

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

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.

[davout]

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)

What do you think ?

[Gavin Andresen]

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