Calculating a sum of received bitcoins

2

I have a list of bitcoin addresses provided by a user and I am trying to find out a sum deposited to these addresses. I am using blockexplorer.com API to obtain transactions.

This is a typical API call (for convenience only for one address) my script does. The call supports parameters from and to, these can be used to effectively streamline an entire transaction ledger.

https://blockexplorer.com/api/addrs/1Archive1n2C579dMsAu3iC6tWzuQJz8dN/txs?from=0&to=20

There appears to be no error in my streamlining algorithm, but if I summarize values found in valueIn (which should presumably stand for values sent to an address), the result is completely off when compared to result returned in API call totalReceived.

https://blockexplorer.com/api/addr/1Archive1n2C579dMsAu3iC6tWzuQJz8dN/totalReceived

Why am I getting a totally different results?

Is this a correct way to find out if a certain amount was deposited to address (or addresses)?

Fun fact: blockexplorer.com returns a value of totalReceived that is different from a value returned by blockchain.info.

LostGoneAndNotFound

Posted 2015-10-07T21:49:41.213

Reputation: 21

Answers

1

Transactions can have multiple outputs, and multiple inputs. The valueIn field is the sum of all of the inputs of the transaction, not the amount going toward the address you're interested in.

Instead of summing valueIn, you should make a list of all of the outputs, then filter out the ones that aren't sent to the address you're interested in, then sum those up.

Fun fact: blockexplorer.com returns a value of totalReceived that is different from a value returned by blockchain.info.

The meaning of 'total received' is not well-defined. For example, if I take money at address A, and send it to address A, has address A "received" money? Different APIs calculate this differently.

Note: I assume you're intentionally not looking to find the balance of the address, which is well-defined.

Nick ODell

Posted 2015-10-07T21:49:41.213

Reputation: 26 536

The reason why I am not looking for a balance is that in my understanding this value is being lowered when value is sent out from this address. What I am looking for is actual value transmitted to an address without taking into account any possible "withdrawals". My application allows users to paste a list of addresses, then it monitors all of them, summarising the amount of bitcoins sent to them. – LostGoneAndNotFound – 2015-10-08T09:39:08.273

1

Why am I getting a totally different results?

You're going to run into a lot of confusion with this sort of API, simply because the information they are displaying is not standardised and is not actually present in the Bitcoin block chain to begin with. As a result there's very little continuity in these values between services, by and large it's not clear how any of them come up with these values.

In this case, the "total received" is probably talking about the amount of outputs that have been confirmed which spend to OP_DUP OP_HASH160 6c1b511a63306b6294e1d3390ac8cd481f76705d OP_EQUALVERIFY OP_CHECKSIG, the script for the P2PKH address you posted. Some block explorers subtract change outputs from this amount, such as in this transaction where 1Archive is re-used for the remainder which is not spent to a new address.

The "total received" for your example address on a few different services:

The "balance" of an address as shown by these APIs presumably contains a total of all confirmed unspent outputs with that script, but depending on the API this sometimes includes unconfirmed transactions or simply indecipherable values like negatives.

Is this a correct way to find out if a certain amount was deposited to address (or addresses)?

Probably not, if you are able you can use a Bitcoin Core node and the watch-only function to monitor your list of addresses and get an independent verification of how much Bitcoin is available to be spent. This will be slow to set up however and isn't suited for situations where you will be adding new addresses frequently (it takes time to re-process historical data, possibly up to 30 minutes now). If you must use these APIs you are probably better off using the unspent outputs endpoint available and making a tally of them yourself.

Anonymous

Posted 2015-10-07T21:49:41.213

Reputation: 10 054

Asked: 2015-10-07T21:49:41.213

Viewed: 497 times

Active: 2015-10-08T00:29:32.310