<p>My application is using <code>bitcoinj-0.11.3</code>. I am using <a href="http://plan99.net/~mike/bitcoinj/0.11/com/google/bitcoin/core/Wallet.html#getBalance(com.google.bitcoin.core.Wallet.BalanceType)" rel="nofollow">Wallet.getBalance(balanceType)</a> to read wallet balance. </p>

<ul>
<li>For <code>AVAILABLE</code> I get 8.94106037<br>
This is supposed to include all confirmed transactions.</li>
<li>For <code>ESTIMATED</code> I get 22.43822671.<br>
This mode assumes that all of the transactions in the memory pool are included into the blockchain.</li>
</ul>

<p>Knowing my transactions this looks inaccurate as confirmed by <a href="http://tbtc.blockr.io/address/info/mnJGoxK2iBqQ6BGHBEYpg4GsdPJcQ8MfKs" rel="nofollow">blockr</a> which indicates a balance of 24.48442767. Note that this doesn't include unconfirmed transactions.</p>

<p>So, there are two inaccuracies here:</p>

<ul>
<li>22.43822671 vs 24.48442767</li>
<li><code>AVAILABLE</code> shows ~9 when it should show ~24.</li>
</ul>

<p>While blockr balance seems right my funds keep in pending state. I suspect that wallet balance calculation is somehow wrong.</p>

<p>[Edit]:
Might also help the output of <code>Wallet.toString</code> :</p>

<p><code>Wallet containing 22.43822671 BTC (available: 8.94106037 BTC) in:
  5 pending transactions
  79 unspent transactions
  390 spent transactions
  0 dead transactions
</code></p>

<p>I think this also answers to Nick question that I am not scrambling numbers while converting the BigInteger.</p>

CC BY-SA 3.0
2014-11-25T06:43:55.443Z
I notice that getBalance returns a BigInteger. Are you converting this into a float at any point? That might be the cause of the minor innacuracy.
Nick ODell
CC BY-SA 3.0
2014-11-25T13:52:12.860Z
People occasionally use testnet to test large block chain reorganizations (reorgs), sometimes creating forks of 2,000 blocks or more.  Those reorgs break lots of software.  It might be worth backing up your data directory and then telling BitcoinJ to rescan for transactions from its earliest key-creation date---if a reorg created the problem, that should fix it.  (If that works, let me know and I'll turn this into an actual answer.)
David A. Harding
<bitcoinj><balance>
BitcoinJ seems to be calculating balance incorrectly
ftraian
# BitcoinJ seems to be calculating balance incorrectly

(Asked by: username_0 on 2014-11-25)

My application is using `bitcoinj-0.11.3`. I am using [Wallet.getBalance(balanceType)](http://plan99.net/~mike/bitcoinj/0.11/com/google/bitcoin/core/Wallet.html#getBalance(com.google.bitcoin.core.Wallet.BalanceType)) to read wallet balance.

* For `AVAILABLE` I get 8.94106037  
  This is supposed to include all confirmed transactions.
* For `ESTIMATED` I get 22.43822671.  
  This mode assumes that all of the transactions in the memory pool are included into the blockchain.

Knowing my transactions this looks inaccurate as confirmed by [blockr](http://tbtc.blockr.io/address/info/mnJGoxK2iBqQ6BGHBEYpg4GsdPJcQ8MfKs) which indicates a balance of 24.48442767. Note that this doesn't include unconfirmed transactions.

So, there are two inaccuracies here:

* 22.43822671 vs 24.48442767
* `AVAILABLE` shows ~9 when it should show ~24.

While blockr balance seems right my funds keep in pending state. I suspect that wallet balance calculation is somehow wrong.

[Edit]:
Might also help the output of `Wallet.toString` :

`Wallet containing 22.43822671 BTC (available: 8.94106037 BTC) in:
5 pending transactions
79 unspent transactions
390 spent transactions
0 dead transactions`

I think this also answers to username_1 question that I am not scrambling numbers while converting the BigInteger.

**Tags:** bitcoinj, balance

> **Comments:**
> **username_1**: I notice that getBalance returns a BigInteger. Are you converting this into a float at any point? That might be the cause of the minor innacuracy.  
> **username_2**: People occasionally use testnet to test large block chain reorganizations (reorgs), sometimes creating forks of 2,000 blocks or more.  Those reorgs break lots of software.  It might be worth backing up your data directory and then telling BitcoinJ to rescan for transactions from its earliest key-creation date---if a reorg created the problem, that should fix it.  (If that works, let me know and I'll turn this into an actual answer.)  

---

## 0 answers

