Closing this thread now.
The patch is included in bitcoin core 0.9. If you find a bug, please report to upstream github.com/bitcoin/bitcoin.
Topic: Yet another Coin Control Release [CLOSED] (Read 47464 times)
about 4)
This is expected. Addresses you create by yourself are not considered as change addresses by the
wallet. So they will not appear as child. This may not be what you expect in this case, but this problem
is rather related to the way the wallet recognizes change in general, than to coin control.
This is expected. Addresses you create by yourself are not considered as change addresses by the
wallet. So they will not appear as child. This may not be what you expect in this case, but this problem
is rather related to the way the wallet recognizes change in general, than to coin control.
Still a bug.
make tickets on github.com/Bitcoin/bitcoin if you want attention on these. The devs don't scour the boards looking for random problems. ( or at least they shouldn't be 
)
https://github.com/bitcoin/bitcoin/issues?state=open
) https://github.com/bitcoin/bitcoin/issues?state=open
Done already, no responses yet.
https://github.com/bitcoin/bitcoin/issues/3840
Thanks, I will check it later today on Testnet (of course).
There were problems right from the first start:
1. New client does not recognize testnet=1 over bitcoin.conf file. Using -testnet over command line helped but then ...
2. New client failed to recognize testnet datadir (testnet3) is a subdirectory of datadir root so it shocked me a bit to see 0 coins and no blockchain
downloaded. To solve issue, I had to copy all data from testnet3 subdirectory to datadir root (are we getting testnet4 maybe?).
3. Once all was set and ready to go, I noticed "Tree mode" checkboxes are not working properly. If there is one unspent input on some address and
I click on checkbox to select that address, checkbox will turn into partially selected state, as if there are more than one unspent input but not all of
them are selected. If I expand that tree I can see both checkboxes have partially selected state, which is totally hmm given that unspent input itself
has that state as well, as if part of it is selected (not really possible). https://i.imgur.com/n67yTb5.png shows incorrect state of checkboxes after
user clicks once on address checkbox (top 2 cases, unexpanded and expanded tree) and how it should look like regardless of the number of unspent
inputs on that address (bottom 2 cases, unexpanded and expanded tree).
If address checkbox is not selected, expanding the tree and clicking on unspent input checkbox turns both checkboxes to fully selected state, as it all
is supposed to work with this scenario. In short, if some tree is not expanded and user clicks on address checkbox, that checkbox and checkboxes of
all unspent inputs at that address should become fully selected, not partialy.
4. Problem as explained earlier (post on previous page) still exists.
https://i.imgur.com/0XyjpOz.png
50 BTC were selected and 25 BTC sent to Testnet3 faucet (mimoZNLcP2rrMRgdeX5PSnR7AjCqQveZZ4) leaving to wallet to create a new address for
change. Remaining 25 BTC ended up on that address and are shown properly as child of original address (mfaULtk7AFHCSBefQKZo6AiLzqktJEwm2Z).
http://pool.qdoop.net:18331/tx/1febd5191ff6b5a830fb79b6185464c17471b4a18dc563aee4d2db06a9b7345f
Another 50 BTC were selected and 25 BTC sent to Testnet3 faucet but this time I created new address (mq9TuNTCVhGzcYQGv7RWiKhcHnwUBt5tC3),
named it "Test" and used it as a change destination. As you can see from screenshot posted above, remaining 25 BTC were sent to that address but
they did not ended up shown as a child of original address but as a normal unspent input.
http://pool.qdoop.net:18331/tx/615b729cefdfc039e53ff475b0540a266db5a9f51566af5387a59278cca5a0a7
After some thinking and given options which Coin Control provides I just don't see how it all can be fixed. With few unspent inputs on few different
addresses it seems that correct visual representation of taints could easily become a horror or even impossible.
5. Not related to Coin Control but annoying, there is no "Copy address" upon right-clicking some receiving address nor address itself is shown
To see receiving address user must double-click on address row to pop-up window with QR code. Then to copy address it takes to double-click it so
it becomes selected and then right-click > Copy or CTRL+C (this is starting to remind me of Microsoft "genius" changes to WinOS and other software).
https://i.imgur.com/PQRm0Ms.png
Client version v0.9.0.0-gd6e0e17-beta on Win7 64-bit.
make tickets on github.com/Bitcoin/bitcoin if you want attention on these. The devs don't scour the boards looking for random problems. ( or at least they shouldn't be
) https://github.com/bitcoin/bitcoin/issues?state=open
@subSTRATA
about 3)
I can confirm this on windows.
It should not affect coin control functionality, but the checkbox state is misleading currently.
My first thought is that this is related to going from qt4 to qt5, in any case I will look into this.
Edit: Just compiled under linux, yes this is a qt5 bug. I will try to submit this upstream somehow.
about 4)
This is expected. Addresses you create by yourself are not considered as change addresses by the
wallet. So they will not appear as child. This may not be what you expect in this case, but this problem
is rather related to the way the wallet recognizes change in general, than to coin control.
Edit: By the way if you prefer the old receive tab, its still available through menu->File->Receiving addresses
about 3)
I can confirm this on windows.
It should not affect coin control functionality, but the checkbox state is misleading currently.
My first thought is that this is related to going from qt4 to qt5, in any case I will look into this.
Edit: Just compiled under linux, yes this is a qt5 bug. I will try to submit this upstream somehow.
about 4)
This is expected. Addresses you create by yourself are not considered as change addresses by the
wallet. So they will not appear as child. This may not be what you expect in this case, but this problem
is rather related to the way the wallet recognizes change in general, than to coin control.
Edit: By the way if you prefer the old receive tab, its still available through menu->File->Receiving addresses
Thanks, I will check it later today on Testnet (of course).
There were problems right from the first start:
1. New client does not recognize testnet=1 over bitcoin.conf file. Using -testnet over command line helped but then ...
2. New client failed to recognize testnet datadir (testnet3) is a subdirectory of datadir root so it shocked me a bit to see 0 coins and no blockchain
downloaded. To solve issue, I had to copy all data from testnet3 subdirectory to datadir root (are we getting testnet4 maybe?).
3. Once all was set and ready to go, I noticed "Tree mode" checkboxes are not working properly. If there is one unspent input on some address and
I click on checkbox to select that address, checkbox will turn into partially selected state, as if there are more than one unspent input but not all of
them are selected. If I expand that tree I can see both checkboxes have partially selected state, which is totally hmm given that unspent input itself
has that state as well, as if part of it is selected (not really possible). https://i.imgur.com/n67yTb5.png shows incorrect state of checkboxes after
user clicks once on address checkbox (top 2 cases, unexpanded and expanded tree) and how it should look like regardless of the number of unspent
inputs on that address (bottom 2 cases, unexpanded and expanded tree).
If address checkbox is not selected, expanding the tree and clicking on unspent input checkbox turns both checkboxes to fully selected state, as it all
is supposed to work with this scenario. In short, if some tree is not expanded and user clicks on address checkbox, that checkbox and checkboxes of
all unspent inputs at that address should become fully selected, not partialy.
4. Problem as explained earlier (post on previous page) still exists.
https://i.imgur.com/0XyjpOz.png
50 BTC were selected and 25 BTC sent to Testnet3 faucet (mimoZNLcP2rrMRgdeX5PSnR7AjCqQveZZ4) leaving to wallet to create a new address for
change. Remaining 25 BTC ended up on that address and are shown properly as child of original address (mfaULtk7AFHCSBefQKZo6AiLzqktJEwm2Z).
http://pool.qdoop.net:18331/tx/1febd5191ff6b5a830fb79b6185464c17471b4a18dc563aee4d2db06a9b7345f
Another 50 BTC were selected and 25 BTC sent to Testnet3 faucet but this time I created new address (mq9TuNTCVhGzcYQGv7RWiKhcHnwUBt5tC3),
named it "Test" and used it as a change destination. As you can see from screenshot posted above, remaining 25 BTC were sent to that address but
they did not ended up shown as a child of original address but as a normal unspent input.
http://pool.qdoop.net:18331/tx/615b729cefdfc039e53ff475b0540a266db5a9f51566af5387a59278cca5a0a7
After some thinking and given options which Coin Control provides I just don't see how it all can be fixed. With few unspent inputs on few different
addresses it seems that correct visual representation of taints could easily become a horror or even impossible.
5. Not related to Coin Control but annoying, there is no "Copy address" upon right-clicking some receiving address nor address itself is shown
To see receiving address user must double-click on address row to pop-up window with QR code. Then to copy address it takes to double-click it so
it becomes selected and then right-click > Copy or CTRL+C (this is starting to remind me of Microsoft "genius" changes to WinOS and other software).
https://i.imgur.com/PQRm0Ms.png
Client version v0.9.0.0-gd6e0e17-beta on Win7 64-bit.
Thanks, I will check it later today on Testnet (of course).
Can you please see if the same bug exists in Bitcoin 0.9 rc2?
Pls, pls fill the bug report if u can do this with 0.9 RC2, ty.
The last version of CC or OMG clients (Win binary) I can find are both version 0.8.5
http://download1.rpmfusion.org/~warren/bitcoin-0.8.5-OMG10/
Is there any newer Win binary?
https://bitcoin.org/bin/0.9.0/test/
Can you please see if the same bug exists in Bitcoin 0.9 rc2?
Pls, pls fill the bug report if u can do this with 0.9 RC2, ty.
The last version of CC or OMG clients (Win binary) I can find are both version 0.8.5
http://download1.rpmfusion.org/~warren/bitcoin-0.8.5-OMG10/
Is there any newer Win binary?
Bug with "Tree mode":
1. Select some unspent input on address X, send some coins from it to different wallet and let Bitcoin-Qt handle change address (make a new one in
the background). That change address will be shown as a child of address X, as a visual aid for existence of connection between those two addresses.
2. Do the same as in 1. but for change address (or second destination, where number of coins to be sent = change) use address Z which you created
in the same wallet. Afterwards, address Z will not be shown as a child of address X even though there is direct link between those two addresses, e.g.
change address in case 1. and address Z have the same status toward address X.
Client version v0.8.5.0-gef14a26-beta on Win7 64-bit.
I will post screenshots if neccessary.
Pls, pls fill the bug report if u can do this with 0.9 RC2, ty. 1. Select some unspent input on address X, send some coins from it to different wallet and let Bitcoin-Qt handle change address (make a new one in
the background). That change address will be shown as a child of address X, as a visual aid for existence of connection between those two addresses.
2. Do the same as in 1. but for change address (or second destination, where number of coins to be sent = change) use address Z which you created
in the same wallet. Afterwards, address Z will not be shown as a child of address X even though there is direct link between those two addresses, e.g.
change address in case 1. and address Z have the same status toward address X.
Client version v0.8.5.0-gef14a26-beta on Win7 64-bit.
I will post screenshots if neccessary.
Can you please see if the same bug exists in Bitcoin 0.9 rc2?
Bug with "Tree mode":
1. Select some unspent input on address X, send some coins from it to different wallet and let Bitcoin-Qt handle change address (make a new one in
the background). That change address will be shown as a child of address X, as a visual aid for existence of connection between those two addresses.
2. Do the same as in 1. but for change address (or second destination, where number of coins to be sent = change) use address Z which you created
in the same wallet. Afterwards, address Z will not be shown as a child of address X even though there is direct link between those two addresses, e.g.
change address in case 1. and address Z have the same status toward address X.
Client version v0.8.5.0-gef14a26-beta on Win7 64-bit.
I will post screenshots if neccessary.
1. Select some unspent input on address X, send some coins from it to different wallet and let Bitcoin-Qt handle change address (make a new one in
the background). That change address will be shown as a child of address X, as a visual aid for existence of connection between those two addresses.
2. Do the same as in 1. but for change address (or second destination, where number of coins to be sent = change) use address Z which you created
in the same wallet. Afterwards, address Z will not be shown as a child of address X even though there is direct link between those two addresses, e.g.
change address in case 1. and address Z have the same status toward address X.
Client version v0.8.5.0-gef14a26-beta on Win7 64-bit.
I will post screenshots if neccessary.
Normally the Coin Control window waits for user input and doesn't update itself
when a new block is accepted. However it does update the number of confirmations when "List mode"/"Tree mode" is toggled
and the selections and sorting is preserved when toggled back (which is pretty awesome).
Is there any trouble to expect if CoinControlDialog::updateView()
would run every time nBestHeight goes up?
when a new block is accepted. However it does update the number of confirmations when "List mode"/"Tree mode" is toggled
and the selections and sorting is preserved when toggled back (which is pretty awesome).
Is there any trouble to expect if CoinControlDialog::updateView()
would run every time nBestHeight goes up?
What people can do, who can not code, but want to help with a GUI feature, is providing a complete prepared mockup.
Including:
- Screenshots, created with gimp,paint,
Or better: download QT Designer and click the GUI together
- Think the whole thing through, make a list of all features and use cases
Also things like: What should happen if...
- Icons, Pictures
- Helptexts, error-messages, tooltips, descriptions, labels
- write a testplan
This is all very simple but time consuming stuff. A developer who can just pick up from there, and does not have to think about what to implement
has a very easy job.
About the other thing:
You have to understand gavin and why he made such a drama with the testplan. This is not about a core dev having privileges over a community dev,
but a known dev over an unknown one. It was the first pull request I have submitted without any references, so there is nothing wrong in testing and code reviewing this
a little more, than from a developer who you know has delivered stable code for years.
Including:
- Screenshots, created with gimp,paint,
Or better: download QT Designer and click the GUI together
- Think the whole thing through, make a list of all features and use cases
Also things like: What should happen if...
- Icons, Pictures
- Helptexts, error-messages, tooltips, descriptions, labels
- write a testplan
This is all very simple but time consuming stuff. A developer who can just pick up from there, and does not have to think about what to implement
has a very easy job.
About the other thing:
You have to understand gavin and why he made such a drama with the testplan. This is not about a core dev having privileges over a community dev,
but a known dev over an unknown one. It was the first pull request I have submitted without any references, so there is nothing wrong in testing and code reviewing this
a little more, than from a developer who you know has delivered stable code for years.
That might be true. But guess what? You can buy manpower. How about the Foundation pays for more full time devs?
Be careful what you wish for.Two of the most active devs (me and Gavin) are already paid for by the Bitcoin Foundation. Do you really want them to hire an army?
Please see the political difficulties here, the danger of centralization. A nice central point that can be sued and/or threatened in other ways. Please don't fall into this trap of hoping some nice organization will take care of your problems and clean up this decentralized chaos.
We don't need the BF to pay for more devs. We need more devs to organize around the project from their own free will and/or sponsored by independent entities (if possible geographically distributed). The forum community would be a possibility though.
In any case: get involved!
How about the Foundation pays for more full time devs?
They are spending all their money hiring lobbyists, lawyers and PR. Also getting rid of the payment protocol for work should be done on the blockchain. Right now only Peter really works on the blockchain, and this is kinda important, but it takes the back seat to Gavin's ideas.
Pieter does a great job and it is as appreciated as Gavin's work. He doesn't 'take a back seat' in anything. His headers-first work has utmost priority.If anything, it is the wallet code that is in the back seat, not the blockchain/network code. Hardly any of the core devs is interested in wallet changes, and after modularizing bitcoind there's a large chance that it will be split off to another project.
Quote
- How do you think this can be accomplished effectively?
: Be more open.
More open? How can we more open, everything is in the open on github (or on the mailinglist, or on #bitcoin-dev). There is no secret cabal of developers.: Be more open.
Quote
Hence why I use bitcoin-omg. Kinda sad when the litecoin devs are better understanding how the community should drive the development.
Then use bitcoin-omg. If anything, wtogami is doing us a favor by making those releases, because too few people test pull requests. At least the features he backports get some testing this way!Quote
- How could you help accomplish this?
: I actually know C++ and could be just like you programing on the core dev team, I chose not to. I don't agree with Gavin's direction of the codebase. Hence why I don't help the core dev team and use the Bitcoin-omg. Voting with my disk space.
So, help wtogami with the Bitcoin-omg code then? At least review code changes and provide comments to improve them. It's the same code base so it helps the main project too.: I actually know C++ and could be just like you programing on the core dev team, I chose not to. I don't agree with Gavin's direction of the codebase. Hence why I don't help the core dev team and use the Bitcoin-omg. Voting with my disk space.
"Programming on the core" does not involve an oath of loyalty to anyone, certainly not to Gavin. We all scratch our own itches here and trying to improve the source code in our own way.
If you really want to help, you should realize that, and not let your dislike for Gavin or me ruin your motivation to do so.
How am I ranting? I am pointing out logic, you didn't say any logic. If you look at the pull request most the code is for the gui, and button functions. That doesn't complicate the wallet code at all. I only saw him extend two methods, so you are wrong. Also I don't expect you to go against Gavin you pretty much work for him, and if you didn't agree with him I doubt you be working on the client. So I am taking my ranting as you have no facts to prove your points and so you attack.
Ok... ignoring the personal provocation, one last time trying to be constructive:- What are you trying to accomplish?
- How do you think this can be accomplished effectively?
- How could you help accomplish this?
We're in this boat together and fighting will only help sink it.
This will be the third time laying it out. Also who is fighting you are clearly the only one attacking me.
- What are you trying to accomplish?
: Getting community patches in as fast as Core Dev patches. No more favoritism. You claim there are no one willing to test, I am willing to test no one ever post about testing. You claim Gavin used bounties no bounties have ever been posted. Also getting rid of the payment protocol for work should be done on the blockchain. Right now only Peter really works on the blockchain, and this is kinda important, but it takes the back seat to Gavin's ideas.
- How do you think this can be accomplished effectively?
: Be more open. Hence why I use bitcoin-omg. Kinda sad when the litecoin devs are better understanding how the community should drive the development.
- How could you help accomplish this?
: I actually know C++ and could be just like you programing on the core dev team, I chose not to. I don't agree with Gavin's direction of the codebase. Hence why I don't help the core dev team and use the Bitcoin-omg. Voting with my disk space.
How am I ranting? I am pointing out logic, you didn't say any logic. If you look at the pull request most the code is for the gui, and button functions. That doesn't complicate the wallet code at all. I only saw him extend two methods, so you are wrong. Also I don't expect you to go against Gavin you pretty much work for him, and if you didn't agree with him I doubt you be working on the client. So I am taking my ranting as you have no facts to prove your points and so you attack.
Ok... ignoring the personal provocation, one last time trying to be constructive:- What are you trying to accomplish?
- How do you think this can be accomplished effectively?
- How could you help accomplish this?
We're in this boat together and fighting will only help sink it.
Complicates the basic wallet code? He extended one or two methods in the wallet code... Yet Gavin uses foundation money to give out bounties (which no one even knows about, I even googled searched, probably faked it) and that is accepted, even thou a broken protocol is being used... I don't follow this logic.
Ok, it's clear, you seem hell-bent on ranting instead of taking this into constructive territory. Have fun.I hear you. We need actual features in Bitcoin-QT, it doesn't have to be a wallet for idiots only.
We just don't have the manpower to make (and maintain, and test!) a wallet with as much features as some of the others.Coin control did eventually get integrated into master (which will be 0.9). People are very good at screaming that something needs to be integrated but hardly anyone bothers to review or to test a pull request. That's not the developer's fault. You know, when a bug in the wallet suddenly causes people's coins to disappear, we will be blamed. So yes we are careful.
If you think that the pace of wallet development should change, then join in. It's an open source project. Complaining won't do a thing, it only annoys and distracts the current developers, in some cases causing them to give up completely.
He thought of the payment protocol, during the summer, and it is already going to be in a 0.9 release There is something wrong right with that. No Core dev codebase unless it is security related should be implement into clients that fast, when the community can't get something into clients that fast.
Gavin was very effective in getting people to test payment requests. He organized a test plan, I think he even gave out bounties for testing, people followed it and reported on it. Also the payment request code is a layer on top, it doesn't complicate the basic wallet code like coin control does, so it was easier to review.Jump to: