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.
Topic: Wallet.BalanceType.AVAILABLE (Read 1111 times)
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.
Played around with the 2nd broadcastTransaction parameter in case of a enabled testnet was helping out.
---
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.
Played around with the 2nd broadcastTransaction parameter in case of a enabled testnet was helping out.
---
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.
I'd like to fix that by adding error codes to the p2p protocol, but it's not ever been a high enough priority.
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?
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?
hmm..
i've read...
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
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
Right. More specifically, look at the documentation:
http://plan99.net/~mike/bitcoinj/0.10/com/google/bitcoin/core/Wallet.BalanceType.html
If you want to change that behaviour, override the default coin selector to reflect your chosen policy and AVAILABLE will reflect that.
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
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.
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.
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.
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?
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?
Jump to: