<p>As the other answer has noted, balances don't <em>technically</em> exist for a specific address. This is because there may be many outputs that are addressed to an address you own, but you can only spend these outputs discretely (I.e. You can say deduct x from my account, you can only say deduct this output amount which was previously awarded to this address). </p>

<p>We can define a pseudo-notion of a balance, though, let's call it the address' unlock-able value (UV), because the owner of the private key for that address can unlock some # of coins by knowing the private key for that address. </p>

<p>Now, to calculate the UV balance, total received, and total sent of an address, you follow this pseudo-algorithm:</p>

<pre><code>Address a;
Uv = 0;
Received = 0;
Sent = 0;
For each (output in blockchain):
    If (output is unlock-able by owner of address a):
        Received += output.amount;
        If (output has been spent):
            Sent += output.amount;
        Else:
            Uv += output.amount;
</code></pre>

<p>At the end of all the outputs in the blockchain, the Uv amount will have a value that is similar in concept to a balance. But here we can also see why this is a very tricky notion:</p>

<ul>
<li>How do you know if an output is unlock-able by owner of address? Sometimes only the key holder themselves can know. </li>
<li>What if an output can be unlocked by, say, 1 of a set of 3 keys? Do you credit the balances of all three keys, or none? </li>
</ul>

<p>I suspect the way blockchain.info does this is by basically running the above pseudo algorithm (although much more optimized and using a database), but only considering outputs in the Pay-to-Pubkey-Hash format. </p>

<hr>

<p>Alright, through contacting the blockchain.info support team and some testing I've found that the problem was the API link given in the question is both paginated and rate limited. The following PHP code produces the same values that blockchain.info shows on their site, assuming you don't run into rate limiting problems.</p>

<pre><code>&lt;?php

// Method: POST, PUT, GET etc
// Data: array("param" =&gt; "value") ==&gt; index.php?param=value

function CallAPI($method, $url, $data = false)
{
    $curl = curl_init();

    switch ($method)
    {
        case "POST":
            curl_setopt($curl, CURLOPT_POST, 1);

            if ($data)
                curl_setopt($curl, CURLOPT_POSTFIELDS, $data);
            break;
        case "PUT":
            curl_setopt($curl, CURLOPT_PUT, 1);
            break;
        default:
            if ($data)
                $url = sprintf("%s?%s", $url, http_build_query($data));
    }

    // Optional Authentication:
    curl_setopt($curl, CURLOPT_HTTPAUTH, CURLAUTH_BASIC);
    // curl_setopt($curl, CURLOPT_USERPWD, "username:password");

    curl_setopt($curl, CURLOPT_URL, $url);
    curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);

    $result = curl_exec($curl);

    curl_close($curl);

    return $result;
}

$address = "1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ";
$offset=0;
$txs = array();

while (true)
{
    $val = json_decode(CallAPI("GET", "https://blockchain.info/address/$address?format=json&amp;limit=10&amp;offset=$offset"), true);
    if (count($val["txs"]) == 0)
        break;
    else 
        $txs = array_merge($txs, $val["txs"]);

    $offset += 10;
}

$uv       = 0;
$received = 0;
$sent     = 0;
$nrefs    = 0;

foreach ($txs as $tx)
{   
    $ininputs = false;
    $totalin = 0;
    foreach ($tx["inputs"] as $input)
    {
        if ($input["prev_out"]["addr"] == $address)
        {
            $ininputs = true;
            $nrefs += 1;
            $totalin += $input["prev_out"]["value"];
        }
    }

    $inoutputs = false;
    $totalout = 0;
    foreach ($tx["out"] as $output)
    {
        if ($output["addr"] == $address)
        {
            $inoutputs = true;
            $nrefs += 1;
            $totalout += $output["value"];
        }
    }

    $uv       += ($totalout - $totalin);

    // $received += $totalout;
    // $sent     += $totalin;

    if ($ininputs &amp;&amp; $inoutputs &amp;&amp; $totalout &gt;= $totalin)
    {
        $received += $totalout - $totalin;
    }
    else if ($ininputs &amp;&amp; $inoutputs &amp;&amp; $totalout &lt; $totalin)
    {
        $sent += $totalin - $totalout;
    }
    else if ($inoutputs)
    {
        $received += $totalout;
    }
    else if ($ininputs)
    {
        $sent += $totalin;
    }
}
echo "\n";

echo "nrefs    : " . $nrefs . "\n";
echo "uv       : " . $uv . "\n";
echo "received : " . $received . "\n";
echo "sent     : " . $sent . "\n";
</code></pre>

<p><img src="https://i.sstatic.net/nycDz.png" alt="Result of running program"></p>

<p><img src="https://i.sstatic.net/Ok1jm.png" alt="enter image description here"></p>

CC BY-SA 3.0
2015-05-01T19:56:27.170Z
I don't think your algorithm is complete. For one, it double counts "change" for payments which goes back to the original address (e.g. address A spends outputs and pays to address B and the change goes back to address A, where it gets counted as it were originally given to it, i.e. it's counted twice: once in the original outputs, and once again as change). This is the gist of my original question: you can't run a simple sum like your own example, so what can you do?
Ivan Voras
CC BY-SA 3.0
2015-05-01T21:04:07.407Z
Hmm, so you're saying that you don't want to double-count an address sending coins to itself towards the total received? But what if two addresses send coins back and forth to the other, even if both owned by the same user, is that really any different? You can only go by what's in the blockchain, and if the blockchain says that an address was 'spent from' and awarded coins in the same transaction, then that's what happened.
morsecoder
CC BY-SA 3.0
2015-05-01T21:05:02.160Z
Trying to infer real world information will only lead you down a rabbit whole where you can be sure you won't cover all the edge cases. Best you can do is go by the blockchain. Now, it might be possible to calculate total unique coins an address has ever owned, adjusting for the mixing that happens in a transaction. While that would be an interesting number to calculate, I don't think it makes the best sense for the 'total received' number. See [this](http://bitcoin.stackexchange.com/questions/450/is-there-any-way-to-track-an-individual-bitcoin-or-satoshi) for more info on tracking % of coins.
morsecoder
CC BY-SA 3.0
2015-05-02T12:02:53.940Z
Well, basically, I need to do whatever blockchain.info does, and it looks like one of the things it does is not double-counting change in total received. It looks like it's doing even more, which I'm hoping to find out.
Ivan Voras
CC BY-SA 3.0
2015-05-05T15:34:04.077Z
@IvanVoras, see updated answer.
morsecoder
CC BY-SA 3.0
2015-05-01T06:15:14.020Z
2015-05-05T15:32:06.710Z
2015-05-05T15:32:06.710Z
morsecoder
<p>Some of these answers are absurd. Yes, there is a difference between having the key to spend from an address and simply totalling in and out. But if you have the key pair to spend from an address, its final total is precisely exactly a 'spendable balance'. </p>

<p>I have no idea how the block explorers lack a consensus on account balances. I would guess likely the bigger numbers are accurate sums of an address in/out. The inaccurate ones would be lower and are inaccurate probably because they don't compute the coinbase properly for each input that ends up in an address and isn't spent.</p>

<p>Coinbase values are not stored in the chain, they are in the chain parameters, what you might call 'ephemeral consensus'. Coinbase values are calulated according to the block reward halving schedule. Getting a different total at the end can only be because you are not counting all of the valid inputs and outputs, of which coinbase is very very important.</p>

CC BY-SA 4.0
2018-10-16T13:23:48.203Z
`Coinbase values are not stored in the chain, they are in the chain parameters`. This is incorrect, the current block reward + fees is very much on chain, in the output of the coinbase transaction. Any block explorer summing up outputs should be able to pick it up without additional work.
Raghav Sood
CC BY-SA 4.0
2018-10-16T13:29:59.463Z
Do you mean is that you can infer the coinbase value by the total value of outputs it used as an input?
Louki Sumirniy
CC BY-SA 4.0
2018-10-16T13:52:33.500Z
But you can't say what the next block's coinbase value should be based on the data in the chain. Strictly speaking although a precise number of blocks relates will be found to have a consistent coinbase value, the halving regime, ie, number of blocks, initial subsidy, it is NOT coded, though the result is.

The function GetBlockValue and the start and min subsidy values in the source code dictate the block reward. Like checkpoints... It's what I am calling ephemeral consensus, and any node ignorant of it will fork the chain.
Louki Sumirniy
CC BY-SA 4.0
2018-10-16T19:32:52.287Z
Sure, but you can predict the reward based on the height. Moreover, the current reward is irrelevant when calculating the total sum of inputs and outputs for an address, since all the information you need for that is on the chain. The current block reward has no bearing on that.
Raghav Sood
CC BY-SA 4.0
2018-10-17T23:33:41.943Z
The current block reward does matter for generation transactions. However as I learned today the 'value' field tells you anyway and if it's the only tx in a block it's quite clear. But you can only infer from more than halving period number of blocks when it occurs, and it's an edge case, sure, but getting that wrong would lose you a block reward.
Louki Sumirniy
CC BY-SA 4.0
2018-10-16T13:12:46.233Z
2018-10-16T13:12:46.233Z
Louki Sumirniy
<blockquote>
  <p>The sum of the unspent outputs is the current balance.</p>
</blockquote>

<p>Not really, that's just the unspent outputs for a particular pubkeyhash. Balances don't exist in Bitcoin, it's extremely misleading to people to suggest that they do by using this terminology. </p>

<blockquote>
  <p>What I want to do is simply arrive at the same total_received, total_sent and balance stats for the given data.</p>
</blockquote>

<p>It's not a part of the network so it's not even defined what this term could possibly mean. The information displayed isn't consistent between the websites claiming to be able to show a "total received" for an address. </p>

<ul>
<li><p><a href="https://insight.bitpay.com/address/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ" rel="nofollow">Insight says</a> 521.29736505 BTC</p></li>
<li><p><a href="https://blockchain.info/address/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ?format=json" rel="nofollow">blockchain.info says</a> 251.24164662 BTC</p></li>
<li><p><a href="https://chain.so/address/BTC/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ" rel="nofollow">chain.so says</a> 389.85919867 BTC</p></li>
<li><p><a href="https://live.blockcypher.com/btc/address/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ/" rel="nofollow">blockcypher.com says</a> 289.5535 BTC</p></li>
<li><p><a href="http://webbtc.com/address/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ.json" rel="nofollow">webbtc.com says</a> 521.29736505 BTC</p></li>
<li><p><a href="https://api.chain.com/v2/bitcoin/addresses/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ?api-key-id=DEMO-4a5e1e4" rel="nofollow">Chain.com says</a> 251.24164662 BTC</p></li>
<li><p><a href="http://blockchains.io/multi/search/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ/" rel="nofollow">blockchains.io says</a> 1042.59473010 BTC</p></li>
<li><p><a href="https://helloblock.io/addresses/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ" rel="nofollow">helloblock.io says</a> 217.80681263 BTC</p></li>
</ul>

<p>So who is right?</p>

<p>It's better just not to confuse everyone by showing faulty data to begin with. Extrapolating this information out to people doesn't do any good, and if services are built using these sort of faulty assumptions about the behavior of the network it can be potentially disastrous and lead to loss of funds. </p>

CC BY-SA 3.0
2015-04-30T21:52:06.923Z
For better or for worse, people in the real world think in terms of account "balance", for their and other people's accounts, so I don't think that is changeable. What do you suggest as an alternative name? "Spendable amount"?

For starts, I'd like to replicate some or any of the non-trivial results (521.29736505 is just a plain sum of outputs, including change). Any ideas on how blockchain.info does it?
Ivan Voras
CC BY-SA 3.0
2015-04-30T22:16:52.693Z
Total spendable outputs would be better, but it would be better if this sort of stuff wasn't shown to end users to begin with. I don't think anybody but blockchain.info could tell you how they calculate theirs.
Claris
CC BY-SA 3.0
2015-04-30T22:17:27.987Z
`Balances don't exist in Bitcoin,` That might be true at a protocol level, but people don't directly construct Bitcoin transactions - they use clients that abstract those details away. I mean, you could apply similar logic to say that Domain Names don't exist, since you're really communicating with an IP address.
Nick ODell
CC BY-SA 3.0
2015-04-30T22:18:43.183Z
A wallet can have a balance, but an address most certainly does not, it has a collection of atomic outputs that can be either spent or unspent. A "balance" implies many things that are just simply not applicable. As for the results above, I don't think anybody actually understands how anybody else is calculating this, which would explain the variance.
Claris
CC BY-SA 3.0
2015-04-30T22:21:00.503Z
@Bitcoin `A "balance" implies many things that are just simply not applicable.` And saying that you open your web browser to a domain name also implies things that aren't true. And yet, it's a useful abstraction.`I don't think anybody actually understands how anybody else is calculating this,` True for total_received, but balance is much better defined.
Nick ODell
CC BY-SA 3.0
2015-04-30T22:24:35.003Z
People don't say they browse a web domain, they say they browse a website. The balance abstraction just serves to confuse people ("I spent 0.1 BTC, but there's 0.9 going to this weird address I don't know about did I get stolen from!") and serves absolutely no useful purpose. The "balance" also differs between different websites and implementations.
Claris
CC BY-SA 3.0
2015-04-30T21:45:47.900Z
2015-04-30T22:12:42.710Z
2015-04-30T22:12:42.710Z
Claris
<p>This is something which I think should be simple but it's driving me crazy. See for example this list of transactions associated with an address:</p>

<p><a href="https://blockchain.info/address/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ?format=json" rel="noreferrer">https://blockchain.info/address/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ?format=json</a></p>

<p>What I want to do is simply arrive at the same total_received, total_sent and balance stats for the given data.</p>

<p>An obvious requirement is to not count the "change" as a new payment to the address. My idea was to simply sum all the outputs in transactions whose inputs are not from the same target address, e.g. if a transaction has an input (or multiple inputs) from A and outputs to B and A, treat this output as change and don't include it in the sum -- only this doesn't produce the same sum as blockchain.info! In this case, it produces 158.11536395 vs 251.24164662. It looks like I'm missing something?</p>

<p>The next step would be to take the list of outputs produced by the first step, and see which are spent and which are not. The sum of the unspent outputs is the current balance. Is this correct?</p>

<p>Anyone?</p>

CC BY-SA 3.0
2015-05-01T06:38:07.797Z
You are along the right lines, but whether or not it's a change address is irrelevant to how much it has received/sent.
morsecoder
CC BY-SA 3.0
2015-05-05T14:13:00.857Z
Their [API docs](https://blockchain.info/api/blockchain_api) show that you need to use the ?limit and ?offset parameters. There was pagination going on, so you weren't actually using all of the transaction data when you calculated 158.11536395 vs 251.24164662 (I got the same numbers with the [data at the time of the question](http://pastebin.com/7AwyP1DH)).
morsecoder
<transactions><blockchain><raw-transaction><balance>
Calculating "total received" and balance by an address
Ivan Voras
# Calculating "total received" and balance by an address

(Asked by: username_0 on 2015-04-30)

This is something which I think should be simple but it's driving me crazy. See for example this list of transactions associated with an address:

<https://blockchain.info/address/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ?format=json>

What I want to do is simply arrive at the same total\_received, total\_sent and balance stats for the given data.

An obvious requirement is to not count the "change" as a new payment to the address. My idea was to simply sum all the outputs in transactions whose inputs are not from the same target address, e.g. if a transaction has an input (or multiple inputs) from A and outputs to B and A, treat this output as change and don't include it in the sum -- only this doesn't produce the same sum as blockchain.info! In this case, it produces 158.11536395 vs 251.24164662. It looks like I'm missing something?

The next step would be to take the list of outputs produced by the first step, and see which are spent and which are not. The sum of the unspent outputs is the current balance. Is this correct?

Anyone?

**Tags:** transactions, blockchain, raw-transaction, balance

> **Comments:**
> **username_1**: You are along the right lines, but whether or not it's a change address is irrelevant to how much it has received/sent.  
> **username_1**: Their [API docs](https://blockchain.info/api/blockchain_api) show that you need to use the ?limit and ?offset parameters. There was pagination going on, so you weren't actually using all of the transaction data when you calculated 158.11536395 vs 251.24164662 (I got the same numbers with the [data at the time of the question](http://pastebin.com/7AwyP1DH)).  

---

## 3 answers

### Answer by username_1 on 2015-05-01. Score: 3 | Accepted answer

As the other answer has noted, balances don't *technically* exist for a specific address. This is because there may be many outputs that are addressed to an address you own, but you can only spend these outputs discretely (I.e. You can say deduct x from my account, you can only say deduct this output amount which was previously awarded to this address).

We can define a pseudo-notion of a balance, though, let's call it the address' unlock-able value (UV), because the owner of the private key for that address can unlock some # of coins by knowing the private key for that address.

Now, to calculate the UV balance, total received, and total sent of an address, you follow this pseudo-algorithm:

```
Address a;
Uv = 0;
Received = 0;
Sent = 0;
For each (output in blockchain):
    If (output is unlock-able by owner of address a):
        Received += output.amount;
        If (output has been spent):
            Sent += output.amount;
        Else:
            Uv += output.amount;

```

At the end of all the outputs in the blockchain, the Uv amount will have a value that is similar in concept to a balance. But here we can also see why this is a very tricky notion:

* How do you know if an output is unlock-able by owner of address? Sometimes only the key holder themselves can know.
* What if an output can be unlocked by, say, 1 of a set of 3 keys? Do you credit the balances of all three keys, or none?

I suspect the way blockchain.info does this is by basically running the above pseudo algorithm (although much more optimized and using a database), but only considering outputs in the Pay-to-Pubkey-Hash format.

---

Alright, through contacting the blockchain.info support team and some testing I've found that the problem was the API link given in the question is both paginated and rate limited. The following PHP code produces the same values that blockchain.info shows on their site, assuming you don't run into rate limiting problems.

```
<?php

// Method: POST, PUT, GET etc
// Data: array("param" => "value") ==> index.php?param=value

function CallAPI($method, $url, $data = false)
{
    $curl = curl_init();

    switch ($method)
    {
        case "POST":
            curl_setopt($curl, CURLOPT_POST, 1);

            if ($data)
                curl_setopt($curl, CURLOPT_POSTFIELDS, $data);
            break;
        case "PUT":
            curl_setopt($curl, CURLOPT_PUT, 1);
            break;
        default:
            if ($data)
                $url = sprintf("%s?%s", $url, http_build_query($data));
    }

    // Optional Authentication:
    curl_setopt($curl, CURLOPT_HTTPAUTH, CURLAUTH_BASIC);
    // curl_setopt($curl, CURLOPT_USERPWD, "username:password");

    curl_setopt($curl, CURLOPT_URL, $url);
    curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);

    $result = curl_exec($curl);

    curl_close($curl);

    return $result;
}

$address = "1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ";
$offset=0;
$txs = array();

while (true)
{
    $val = json_decode(CallAPI("GET", "https://blockchain.info/address/$address?format=json&limit=10&offset=$offset"), true);
    if (count($val["txs"]) == 0)
        break;
    else 
        $txs = array_merge($txs, $val["txs"]);

    $offset += 10;
}

$uv       = 0;
$received = 0;
$sent     = 0;
$nrefs    = 0;

foreach ($txs as $tx)
{   
    $ininputs = false;
    $totalin = 0;
    foreach ($tx["inputs"] as $input)
    {
        if ($input["prev_out"]["addr"] == $address)
        {
            $ininputs = true;
            $nrefs += 1;
            $totalin += $input["prev_out"]["value"];
        }
    }

    $inoutputs = false;
    $totalout = 0;
    foreach ($tx["out"] as $output)
    {
        if ($output["addr"] == $address)
        {
            $inoutputs = true;
            $nrefs += 1;
            $totalout += $output["value"];
        }
    }

    $uv       += ($totalout - $totalin);

    // $received += $totalout;
    // $sent     += $totalin;

    if ($ininputs && $inoutputs && $totalout >= $totalin)
    {
        $received += $totalout - $totalin;
    }
    else if ($ininputs && $inoutputs && $totalout < $totalin)
    {
        $sent += $totalin - $totalout;
    }
    else if ($inoutputs)
    {
        $received += $totalout;
    }
    else if ($ininputs)
    {
        $sent += $totalin;
    }
}
echo "\n";

echo "nrefs    : " . $nrefs . "\n";
echo "uv       : " . $uv . "\n";
echo "received : " . $received . "\n";
echo "sent     : " . $sent . "\n";

```

![Result of running program](https://i.sstatic.net/nycDz.png)

![enter image description here](https://i.sstatic.net/Ok1jm.png)

> **Comments:**
> **username_0**: I don't think your algorithm is complete. For one, it double counts "change" for payments which goes back to the original address (e.g. address A spends outputs and pays to address B and the change goes back to address A, where it gets counted as it were originally given to it, i.e. it's counted twice: once in the original outputs, and once again as change). This is the gist of my original question: you can't run a simple sum like your own example, so what can you do?  
> **username_1**: Hmm, so you're saying that you don't want to double-count an address sending coins to itself towards the total received? But what if two addresses send coins back and forth to the other, even if both owned by the same user, is that really any different? You can only go by what's in the blockchain, and if the blockchain says that an address was 'spent from' and awarded coins in the same transaction, then that's what happened.  
> **username_1**: Trying to infer real world information will only lead you down a rabbit whole where you can be sure you won't cover all the edge cases. Best you can do is go by the blockchain. Now, it might be possible to calculate total unique coins an address has ever owned, adjusting for the mixing that happens in a transaction. While that would be an interesting number to calculate, I don't think it makes the best sense for the 'total received' number. See [this](http://bitcoin.stackexchange.com/questions/450/is-there-any-way-to-track-an-individual-bitcoin-or-satoshi) for more info on tracking % of coins.  
> **username_0**: Well, basically, I need to do whatever blockchain.info does, and it looks like one of the things it does is not double-counting change in total received. It looks like it's doing even more, which I'm hoping to find out.  
> **username_1**: @username_0, see updated answer.  

---

### Answer by username_2 on 2018-10-16. Score: 0

Some of these answers are absurd. Yes, there is a difference between having the key to spend from an address and simply totalling in and out. But if you have the key pair to spend from an address, its final total is precisely exactly a 'spendable balance'.

I have no idea how the block explorers lack a consensus on account balances. I would guess likely the bigger numbers are accurate sums of an address in/out. The inaccurate ones would be lower and are inaccurate probably because they don't compute the coinbase properly for each input that ends up in an address and isn't spent.

Coinbase values are not stored in the chain, they are in the chain parameters, what you might call 'ephemeral consensus'. Coinbase values are calulated according to the block reward halving schedule. Getting a different total at the end can only be because you are not counting all of the valid inputs and outputs, of which coinbase is very very important.

> **Comments:**
> **username_3**: `Coinbase values are not stored in the chain, they are in the chain parameters`. This is incorrect, the current block reward + fees is very much on chain, in the output of the coinbase transaction. Any block explorer summing up outputs should be able to pick it up without additional work.  
> **username_2**: Do you mean is that you can infer the coinbase value by the total value of outputs it used as an input?  
> **username_2**: But you can't say what the next block's coinbase value should be based on the data in the chain. Strictly speaking although a precise number of blocks relates will be found to have a consistent coinbase value, the halving regime, ie, number of blocks, initial subsidy, it is NOT coded, though the result is.  The function GetBlockValue and the start and min subsidy values in the source code dictate the block reward. Like checkpoints... It's what I am calling ephemeral consensus, and any node ignorant of it will fork the chain.  
> **username_3**: Sure, but you can predict the reward based on the height. Moreover, the current reward is irrelevant when calculating the total sum of inputs and outputs for an address, since all the information you need for that is on the chain. The current block reward has no bearing on that.  
> **username_2**: The current block reward does matter for generation transactions. However as I learned today the 'value' field tells you anyway and if it's the only tx in a block it's quite clear. But you can only infer from more than halving period number of blocks when it occurs, and it's an edge case, sure, but getting that wrong would lose you a block reward.  

---

### Answer by username_4 on 2015-04-30. Score: 0

> The sum of the unspent outputs is the current balance.

Not really, that's just the unspent outputs for a particular pubkeyhash. Balances don't exist in Bitcoin, it's extremely misleading to people to suggest that they do by using this terminology.

> What I want to do is simply arrive at the same total\_received, total\_sent and balance stats for the given data.

It's not a part of the network so it's not even defined what this term could possibly mean. The information displayed isn't consistent between the websites claiming to be able to show a "total received" for an address.

* [Insight says](https://insight.bitpay.com/address/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ) 521.29736505 BTC
* [blockchain.info says](https://blockchain.info/address/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ?format=json) 251.24164662 BTC
* [chain.so says](https://chain.so/address/BTC/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ) 389.85919867 BTC
* [blockcypher.com says](https://live.blockcypher.com/btc/address/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ/) 289.5535 BTC
* [webbtc.com says](http://webbtc.com/address/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ.json) 521.29736505 BTC
* [Chain.com says](https://api.chain.com/v2/bitcoin/addresses/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ?api-key-id=DEMO-4a5e1e4) 251.24164662 BTC
* [blockchains.io says](http://blockchains.io/multi/search/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ/) 1042.59473010 BTC
* [helloblock.io says](https://helloblock.io/addresses/1EZK42jGEJVniyBn1wXrUx92wzyUkYB8kJ) 217.80681263 BTC

So who is right?

It's better just not to confuse everyone by showing faulty data to begin with. Extrapolating this information out to people doesn't do any good, and if services are built using these sort of faulty assumptions about the behavior of the network it can be potentially disastrous and lead to loss of funds.

> **Comments:**
> **username_0**: For better or for worse, people in the real world think in terms of account "balance", for their and other people's accounts, so I don't think that is changeable. What do you suggest as an alternative name? "Spendable amount"?  For starts, I'd like to replicate some or any of the non-trivial results (521.29736505 is just a plain sum of outputs, including change). Any ideas on how blockchain.info does it?  
> **username_4**: Total spendable outputs would be better, but it would be better if this sort of stuff wasn't shown to end users to begin with. I don't think anybody but blockchain.info could tell you how they calculate theirs.  
> **username_5**: `Balances don't exist in Bitcoin,` That might be true at a protocol level, but people don't directly construct Bitcoin transactions - they use clients that abstract those details away. I mean, you could apply similar logic to say that Domain Names don't exist, since you're really communicating with an IP address.  
> **username_4**: A wallet can have a balance, but an address most certainly does not, it has a collection of atomic outputs that can be either spent or unspent. A "balance" implies many things that are just simply not applicable. As for the results above, I don't think anybody actually understands how anybody else is calculating this, which would explain the variance.  
> **username_5**: @Bitcoin `A "balance" implies many things that are just simply not applicable.` And saying that you open your web browser to a domain name also implies things that aren't true. And yet, it's a useful abstraction.`I don't think anybody actually understands how anybody else is calculating this,` True for total_received, but balance is much better defined.  
> **username_4**: People don't say they browse a web domain, they say they browse a website. The balance abstraction just serves to confuse people ("I spent 0.1 BTC, but there's 0.9 going to this weird address I don't know about did I get stolen from!") and serves absolutely no useful purpose. The "balance" also differs between different websites and implementations.  

---

