Bitcoin Forum
May 27, 2024, 01:47:44 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Wallet.BalanceType.AVAILABLE  (Read 1097 times)
jonas.schnelli (OP)
Member
**
Offline Offline

Activity: 66
Merit: 10

bitcoin core contributor


View Profile WWW
September 30, 2013, 03:07:07 PM
 #1

Hi

I try to get a nice end-user capable balance with bitcoinj.

For the main display i use the Wallet.BalanceType.AVAILABLE.
2nd, i display a value for "Funds on the way" with Wallet.BalanceType.AVAILABLE minus Wallet.BalanceType.ESTIMATED.

But it seams that Wallet.BalanceType.AVAILABLE is also not counting transaction "from my own wallet to my own wallet".

Is there a way to get the balance including tx to my own wallet?

Or what's best practice to show a end user capable balance?
Andreas Schildbach
Hero Member
*****
Offline Offline

Activity: 483
Merit: 501


View Profile
September 30, 2013, 03:16:52 PM
 #2

I'm not sure what you mean by "does not count".

I'd expect that a standard tx from me to myself should not touch any balance - except for the fee -, be it available or estimated. Reason: We expect transactions created by ourselves will confirm shortly, because we created them ourselves (adding the correct fee etc.). We thus should be able to build transactions on top immediately without the risk of building unconfirming chains.

Up to now, when talking about this topic we always looked at spending our own change. But there is no reason this should not also work for payments to ourselves. I assume for bitcoinj it will not make any difference.
Mike Hearn
Moderator
Legendary
*
Offline Offline

Activity: 1526
Merit: 1129


View Profile
September 30, 2013, 03:48:30 PM
 #3

Right. More specifically, look at the documentation:

http://plan99.net/~mike/bitcoinj/0.10/com/google/bitcoin/core/Wallet.BalanceType.html

Quote
AVAILABLE
Balance that can be safely used to create new spends. This is whatever the default coin selector would make available, which by default means transaction outputs with at least 1 confirmation and pending transactions created by our own wallet which have been propagated across the network

If you want to change that behaviour, override the default coin selector to reflect your chosen policy and AVAILABLE will reflect that.
jonas.schnelli (OP)
Member
**
Offline Offline

Activity: 66
Merit: 10

bitcoin core contributor


View Profile WWW
September 30, 2013, 06:11:11 PM
 #4

hmm..

i've read...

Quote
The default coin selector bitcoinj provides (Wallet.DefaultCoinSelector) implements a relatively safe policy: it requires at least one confirmation for any transaction to be considered for selection, except for transactions created by the wallet itself which are considered spendable as long as it was seen propagating across the network.
(i assume Wallet.DefaultCoinSelector returns the same amount as BalanceType.AVAILABLE does).

But i encountered that after spending some coins to one of my own address, the balance with BalanceType.AVAILABLE does not count the coins until they are 1 block deep.
What exactly are the policies to "...was seen propagating across the network"?

thanks
Mike Hearn
Moderator
Legendary
*
Offline Offline

Activity: 1526
Merit: 1129


View Profile
October 01, 2013, 09:34:19 AM
 #5

As in, you were connected to 2 or more nodes, and those nodes all announced the transaction with an inv packet (i.e. they accepted and relayed the tx).

The coin selector is an object that is given a bunch of outputs that are allowed to be spent according to the Bitcoin rules, and an amount, and it's supposed to give back a subset of those outputs that add up to that amount or more according to its chosen policies. The AVAILABLE balance is thus calculated by asking the coin selector to give back MAX_MONEYs worth of outputs (as many as possible).

How did you create the spend that wasn't considered selectable? Perhaps we can see your code?
Mike Hearn
Moderator
Legendary
*
Offline Offline

Activity: 1526
Merit: 1129


View Profile
October 01, 2013, 09:45:21 AM
 #6

One simple thing that can lead to what you observe, is if for testing you're only connected to a single node. In that case it will look the same as if you had broadcast an unacceptable transaction because of how the Bitcoin protocol works.

I'd like to fix that by adding error codes to the p2p protocol, but it's not ever been a high enough priority.
jonas.schnelli (OP)
Member
**
Offline Offline

Activity: 66
Merit: 10

bitcoin core contributor


View Profile WWW
October 01, 2013, 01:59:58 PM
 #7

Thanks Mike.

Yes. It seams to be a testnet issue. To reach the required 4 peers before the Future gets fired is not so easy on the testnet. Smiley
Played around with the 2nd broadcastTransaction parameter in case of a enabled testnet was helping out. Smiley
---
</jonas>
Mike Hearn
Moderator
Legendary
*
Offline Offline

Activity: 1526
Merit: 1129


View Profile
October 01, 2013, 02:58:11 PM
 #8

Testnet is sadly pretty broken these days and I'm not sure why.

I tend to use regtest mode. I run a node locally and a node on my personal VPS and connect them together. The advantage is you get a block exactly when you want, immediately, and at no other time.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!