Bitcoin Forum
December 09, 2016, 03:45:53 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Getting the address that received funds  (Read 992 times)
davout
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
December 16, 2010, 12:04:53 PM
 #1

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.

1481298353
Hero Member
*
Offline Offline

Posts: 1481298353

View Profile Personal Message (Offline)

Ignore
1481298353
Reply with quote  #2

1481298353
Report to moderator
1481298353
Hero Member
*
Offline Offline

Posts: 1481298353

View Profile Personal Message (Offline)

Ignore
1481298353
Reply with quote  #2

1481298353
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481298353
Hero Member
*
Offline Offline

Posts: 1481298353

View Profile Personal Message (Offline)

Ignore
1481298353
Reply with quote  #2

1481298353
Report to moderator
1481298353
Hero Member
*
Offline Offline

Posts: 1481298353

View Profile Personal Message (Offline)

Ignore
1481298353
Reply with quote  #2

1481298353
Report to moderator
1481298353
Hero Member
*
Offline Offline

Posts: 1481298353

View Profile Personal Message (Offline)

Ignore
1481298353
Reply with quote  #2

1481298353
Report to moderator
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
December 16, 2010, 02:33:52 PM
 #2

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

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

Activity: 1358


1davout


View Profile WWW
December 16, 2010, 02:54:15 PM
 #3

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
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
December 16, 2010, 04:29:39 PM
 #4

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.

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

Activity: 1358


1davout


View Profile WWW
December 16, 2010, 05:28:24 PM
 #5

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
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
December 16, 2010, 05:46:46 PM
 #6

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?
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!