Bitcoin Forum

Here's some good news for all coin control fans:

I was going to merge the old coin control code, making a few changes to the crappy GUI form, but ended up in a complete rewrite of coin control:)
I have been testing this for a week now, works great for me, so I guess, I can throw this out to the public now.

What is coin control?
When you send bitcoins to someone else, the bitcoin client chooses kinda randomly which of your addresses will send the coins. With coin control you can exactly choose, which of your addresses will be the sending addresses. And even more specific which of your unspent outputs will be the sending inputs.
  
What is an unspent output?
Lets say your bitcoin address is 111. Now someone sends 1 BTC to this address. Now address 111 has one unspent output. Now someone else sends 2 BTC to this address. Now address 111 has two unspent outputs and a balance of 3 BTC in total. Now lets say you want to send someone 0.1 BTC. One could say "ok, simply subtract 0.1 BTC from the first unspent output and send it". But this is not possible, because the bitcoin protocol works different. You always have to spent the whole output. This means in this case the bitcoin client would take the first unspent output, send 0.1 BTC to the other person and 0.9 BTC back to yourself. For this the client creates a new change address in the background and adds this address to your wallet. This address would then have one unspent output of 0.9 BTC. This means every wallet has kinda "hidden" change addresses. For example if you now would loose your wallet, but still know the private key of 111, you would be only able to get the 2 BTC back. The 0.9 BTC from the change address are gone, because you would have to know the private key of the change address.
  
Why coin control?
The first version of coin control was called "Patching The Bitcoin Client To Make It More Anonymous". Sometimes when you receive bitcoins, the sender or even the public knows that it is you who owns the bitcoin address. Now if you later want to make a real anonymous payment, you shouldnt use those coins. Also you get full control over your unspent outputs and can do things like choosing which address actually owns the coins, clean them up or send all change back to the origin address etc. You can also prevent the bitcoin client from creating a change address by exactly sending the amount of selected unspent outputs minus the fee. Also you get a better impression of whats going on in your wallet and get a better understanding of the bitcoin protocol.

Changes to the GUI

Screenshots
screenshot1.png (https://a.fsdn.com/con/app/proj/bitcoincoincont/screenshots/screen_shot1.png)
screenshot2.png (https://a.fsdn.com/con/app/proj/bitcoincoincont/screenshots/screen_shot2.png)
screenshot3.png (https://a.fsdn.com/con/app/proj/bitcoincoincont/screenshots/screen_shot6.png)
screenshot4.png (https://a.fsdn.com/con/app/proj/bitcoincoincont/screenshots/screen_shot7.png)
screenshot5.png (https://a.fsdn.com/con/app/proj/bitcoincoincont/screenshots/screen_shot5.png)

Main

• Settings checkbox "Display coin control features (experts only!)" (default=no)

Tab Send coins

• Button Inputs
  
  • click on this button opens actual coin control dialog. If no Inputs are selected "automatically selected" is shown.
• Change Checkbox
  
  • checked -> provide custom change address

Coin Control Dialog

• Shows a list of all unspent outputs with two view modes
  
  • tree mode: outputs including change are grouped by wallet address
    tree can be opened showing the actual outputs for this wallet address including change
    if change, the change bitcoin address is shown in column "address", otherwise the column "address" is empty, because its a direct output of the wallet address having the bitcoin address already shown in the parent node (same with label)
    
  • list mode: simple list of all unspent outputs
• select outputs by checkbox -> only the checked outputs are used when sending a transaction
  if none are selected -> coin control inactive (just as normal)
  
• check/uncheck all by clicking on "(Un)select all"
• sort colums
• tooltip available in column list mode in column label for the change (shows from which address the change came from)
• Context menu
  Copy to clipboard (amount,label,address,transaction id,lock,unlock)
  
• Labels at the top
  Quantity: number of selected outputs
  Amount: sum of selected unspent outputs
  Fee:   see "Calculation of fee and transaction size" below
  minus fee: simply the amount shown is "Selected" minus the amount shown in "Fee"
  Bytes: see "Calculation of fee and transaction size" below
  Priority: priority = coinage / transactionsize. coinage = value * confirmations.  miners order transactions by priority when selecting which go into a block
  Low Output: "yes" if any recipient receives an amount < 0.01BTC
  Change: shows the change you get back
  
• direct right click the labels for copy amount to clipboard

   


Selection
In this version of coin control, all selected outputs are going into the transaction for sure!!
Of course, if you select more than you actually send, the bitcoin core will send the rest back to you as change, just as normal.
And of course, if you select less than you send you will get "The amount exceeds your balance".
And as already mentioned, if none are selected, coin control is inactive, this means everything is just the same as without coin control.
  
Fee
If the sum of selected outputs minus the amount you are going to send is smaller than the required fee, you will probably get
"The total exceeds your balance when the transaction fee is included"
This is because you didnt select enough outputs to pay the fee.
You always must select enough outputs, so that those outputs can pay the fee.
  
Calculation of fee and transaction size
The fee is calculated according to the fee set in the Settings menu.
The calculation assumes 2 outputs in total. One for the destination address and one for the change.
The formula is nBytesOutputs + (2 * 34) + 10. nBytesOutputs is the sum of selected outputs, 148 or 180 bytes per output, depending if compressed public key.
Due to the inner workings of bitcoin the size per output is actually +/- 1 byte. Meaning the shown calculation is not always 100% correct.
If you send exactly "selected minus fee" then you will not have change (1 output only). The transaction will then be 34 bytes smaller as what was calculated before.

Free Transactions
In order to be able to send a free transaction, you need to follow the rules:
     - transaction size must be < 10000 bytes
     - priority must be at least "medium"
     - any recipient must receive at least 0.01BTC
     - change must be either zero or at least 0.01BTC
  If you violate one rule you will see a min-fee and also the labels turn red:
  Bytes.Priority,Low Output,Change. Depending which rule you violated.
  Those 4 labels also have tool tips explaining this.
  Also remember that violating one of the first 2 rules means 0.0005 PER kilobyte min-fee,
  while violating one of the last 2 means 0.0005 min-fee only.

Links
Source code (http://sourceforge.net/projects/bitcoincoincont/files/bitcoin-0.8.5-win32.zip/download)
Pull Request (https://github.com/bitcoin/bitcoin/pull/2343)
Binaries including this patch available here
Bitcoin OMG (https://bitcointalk.org/index.php?topic=320695.0)

Can this be verified? My understanding was that each address within a given wallet was simply another hash function of the same private key. That is, there is only a single private key for all of the addresses in a given wallet. If the quoted portion is correct then there is a private key for each address and I have a lot of remedial work to do.

If the wallet used deterministic key generation (such as Electrum) then all the private keys could be derived from the single seed used for the deterministic algorithm. As of 0.7.2 Bitcoin-Qt uses a random key generation.  So the description in the OP is correct.  I'm not sure if this is changed in 0.8.0 (I haven't looked at that release yet).  I know there is work being done towards making Bitcoin-Qt deterministic, so the spirit of your statement may be true eventually in the future (even if the specifics aren't quite right).

I'm not sure that this means that you "have a lot of remedial work to do", but it certainly means that given the current 0.7.2 version of Bitcoin-Qt it is important to create backups on a regular basis. It also means that storing private keys from Bitcoin-Qt is only useful if you are not spending the bitcoin associated with those keys at all.

This.
While I have electronic backups I also have paper backups and the paper backups consist of a single private key which is, apparently, insufficient.

Version 0.7.2 and later include the raw transaction API (JSON-RPC), which permits full coin control.

The upcoming release 0.8 includes contrib/spendfrom/ utility, which illustrates how easily an external utility may provide coin control capability.  No GUI patching required.

Assuming that you are using Bitcoin-Qt, and unless you are using a special "coin control" release that allows you to specify where the change goes, you are correct.  A paper backup with a single private key is insufficient.  Fortunately you've discovered this before it was a problem.

I'm don't know how old your electronic backups are, nor do I know how many transactions you create per month, but if the sum of all the bitcoin addresses you've created in "Receive Coins" and the total number of transactions you've created since your last electronic backup is more than 100, and you haven't modified your configuration to increase the size of the address pool, then you don't have a recent enough electronic backup either.

See the 'spendfrom' script in contrib/ of version 0.8.0.

Because basically no one was interested in doing even the most basic maintenance on the GUI and the code that was submitted wasn't really mergable without work. We added the bare minimum for a sufficiently technical user to do it on their own (or for someone to roll an external GUI for it).

The screenshots look pretty interesting! This seems like a MAJOR improvement over the old stuff.  I'm more inclined to merge something like this than Jeff is sounding, assuming that the author is willing to endure the requisite hoop jumping and shed painting... not just because it's useful, but because its a feature that can help increase technical understanding of the Bitcoin system.

Ideal for those who want a UI is simply to write an add-on utility or plugin that uses the RPC API.

Please open a pullreq for this after rebasing to 0.8. :)

It feels like individual coins in the wallet now, each with it's own history
instead of just a number.

Bonus points for improved privacy, improved control over fees, and being
educational for noobs about how bitcoin works.

Please include it in 0.8.1 *exactly like this* :)

IMO, this is definitely a 0.9 feature at the earliest. Way too big a change for 0.8.x :)

update v0.8.0

Changes:
- GUI: removed tab coin control, it is now integrated in send coins dialog as popup
- REMOVAL: removed trace back feature completely, because it is no more possible with pruned txindex
- FEATURE: control of change address (auto,back to input,custom)
- rebased to current master, using the new lockCoin methods
- updated screenshots
- submitted pull request

@cozz:

This is soooo awesome.

I want to express my gratitude for your hard work on this. Is your donation address valid ?

+1

Nice work!

Fantastic! Thank you! I shall be using this now in preference to the standard bitcoin-qt project. Do you have a reference to where the source is on github please? Also, I'd quite like to compile this myself on Windows - so if you'd be willing to include info on how you compiled the windows binary, this would be fantastic.

Thank you again!

Anyone know PyQt?  That could provide the same functions, without patching bitcoind / Bitcoin-Qt, for coin control via python-bitcoinrpc.

These python releases would be much more useful to most of us if they were integrated with python included and gui'ed in windows/LINUX/mac

PyQt is a GUI API for python, so it would definitely be a GUI coin control app.  Integrated releases should be easily possible with py2exe and similar tools, for those platforms that need it.

Cozz, you are awesome.  Used your own feature to send you a tip. :)  Hope this gets merged upstream.

I would like to try this.  I don't want to take the time to figure out if it is a Trojan.  Will it steal my bitcoins?  Has anybody checked this?

Sam

Highly unlikely.

Such things are almost trivial to spot by an experienced developer or even better: code audit - oriented developer/specialist (when you have the source code).

Shut up luke. In this instance, your opinion goes against the collective voices of the bitcoin userbase.

... Not only do plenty of people want this feature, the idea has even been tried, and tested for long enough, and it even works well for other bitcoin clients, etc. etc. etc. Even if this feature causes the next version of 0.8.x to wait an extra month or even longer in release candidate status while the features are getting debugged, fine by me. That's perfectly acceptable.

The OP on this thread even explicitly says this feature is disabled by default:


So let's please just finally add this feature. We've already waited long enough while GBT was implemented and blockchain data was switched over to being stored with LevelDB, etc. etc. etc.

UPDATE:

first of all, thank you to the 2 people who donated.

gmaxwell from the devs gave me some pointers, so I implemented them:

- removed send change "back to input", because this might confuse people
- address-label is shown, if you enter a change address, also warning if change address is not in wallet or invalid address
- you can now lock/unlock per right-click in the GUI (same as the new cli method "lockunspent")
- (un)select all is now a button to be easier recognizable
- confirmations is now a number, no more icons
- the calculation labels are now on top and also shown in send coins dialog (see screenshots)
- "priority" added (very low - very high): miners order transactions by priority when selecting which go into a block
   priority = coinage / transactionsize
   coinage = value * confirmations
- fee is now calculated for real (before it did not take min-fee into account)
  In order to be able to send a free transaction, you need to follow the rules:
     - transaction size must be < 10000 bytes
     - priority must be at least "medium"
     - any recipient must receive at least 0.01BTC
     - change must be either zero or at least 0.01BTC
  If you violate one rule you will see a min-fee and also the labels turn red:
  Bytes.Priority,Low Output,Change. Depending which rule you violated.
  Those 4 labels also have tool tips explaining this.
  Also remember that violating one of the first 2 rules means 0.0005 PER kilobyte min-fee,
  while violating one of the last 2 means 0.0005 min-fee only.
(Just for the record, I did not make those rules, if you dont like them complain to satoshi:)

That's a good reason why some sort of outboard "coin control utility" isn't a substitute for upstreaming this functionality.

IMHO encouraging end-users to get in the habit of downloading and using third-party "wallet plugins" is probably not a good idea security-wise.

YA, RLY.

Trying to hide code is trivial to spot because such code immediately fails readibility/understanding tests.

Unreadable or not understable code = suspicious code.

UPDATE: v0.8.1

The bottleneck for getting this pulled is testing.

It needs a thorough test plan that tries to test edge cases where things might break, and then it needs people to carry out that test plan to make sure it is solid. "It works for me" isn't good enough for wallet-touching code.

See https://github.com/bitcoin/QA  for a suggested process.

I've downloaded it, will check it out. Functionality like this is badly needed. Let's get some testing set up so people feel comfortable putting it into 0.9.

It is simply extremely difficult to write a program which will do some "Complex Evil Thing(tm)" (like turning your comp into a botnet zombie or stealing your bitcoins) without the code looking suspicious.

It is possible, however highly unlikely.

great work :)

long loong awaited feature for Bitcoin-qt. Thanks for this wonderful piece of addition!
Let us all hope it finally makes it officially into v0.9. Please dont give up!
Donated you to finish the testing plan for gavin  :) :)

FYI, this is included in next-test 2013-04-12 (https://bitcointalk.org/index.php?topic=175026.0).

Thank you very much, this is highly appreciated & anticipated by many people.

So now ur telling me an unspent output is really a sig script from a previous tx to that receiving address. So 2 txs to an address: 2 sig scripts controlling the movement of coins there.  But 111 would list 3 BTC in the UTXO correct?  UTXO doesn't list the address twice.  Once with 1 btc, and again with 2 btc.  That's all kinds of database fail.  (unless your goal is to allow for every coin balance in UTXO to reference the blockchain txs that created it.  Then its dbase overkill.)  I still can't understand why Satoshi didn't build pruning in from day one.


Why on God's green earth did Satoshi choose to do this.   I;ve seen txns on blockexplorer  that only move a portion of a balance to a new address.  No, 2 output address to move the "change" of the unspent input.  Or is it that i'm just seeing a full unspent input being moved?

Why don't tx's just track the net movement from one address to another(s), and have the client alter the UTXO table (which i think just contains the output addresses and their total balances).  Then every 10 blocks or so, hash this UTXO and include it in the header (say stuff it in the merkle root as if it were a tx hash).    This means a new client could just d/l the last X number of blocks & headers till it felt confident it had enough. DL then most recent UTXO, and then check then UTXO it received by walking it back by all the txns in the X blocks it d/led and checking the UTXO hashes in the header?   Could allow new clients to d/l and catch up to the current chain in minutes instead of days. Then it will be like Star Terk II, where days become hours.

Wouldn't this be the most elegant way to prune?   It might of course require a new data field added to the header (UTXO hash), but maybe this can be stuffed into the merkle root instead, as if it were a tx hash.   Thus, the UTXO hash data would be seeded into the header via the merkle root w/o having to add a new header field which would be a hard fork. 

Of course how to get the UTXO hash to look like a tx is key.  Aren't there unused data fields in the coinbase.  Does coinbase go into the merkle roots?  Does the unused field get hashed into that?   thus that would be the best place to stick the utxo hash.

+1 for adding those feature in the main client
I would really like to have them on it.

Let me see if I'm understanding this...

Suppose you received 10 BTC for services or whatever.

If you want to spend 1 BTC, your wallet sends all 10 BTC as a complete lump, then sends the remaining 9 BTC back to you?

So in that sense it's very much like handing over a $10 note to buy a $1 item and getting $9 change, right?

But while receiving your change your wallet locks that money with a new key, and doesn't tell you the key? So at that point you CAN still spend those 9 BTC, but if you lose your wallet you lose those 9 BTC because you don't have the key for them?

So even if you do an up-to-date backup, you're just backing up your private key again - which hasn't changed, so you STILL don't have the key for the 9 BTC change and you'd still lose those 9 BTC (at today's price, over $1000)?

If that's correct then that's nutz.


What if you did 'export private keys' or whatever, would you then have the keys for the change?


 :o

Depending on the backup process you are using, the key is most likely in your backup.


If you are running dumpprivkey to get your keys and you fail to run it for the change addresses, then yes, you will be missing the private keys for the change.  On the other hand, if you use the backup menu option, or you make a backup copy of your wallet.dat file, then the private keys for your change addresses (as well as the next 100 addresses that you will use in the future) are all included in your backup.

OK, that's not so bad.

Do you happen to know if the 'export private keys' thing in Multibit would also export the new, added keys?




Thanks



A.

Each wallet has its own way of dealing with change.  Some create new "change" addresses, some let you choose a "change" address, some use one of the addresses you previously created.  The information provided in this thread about how change is handled is all specifically about the Bitcoin-Qt reference wallet.  I'm not certain how MultiBit handles change, and I'm not sure what methods are available for backup or what private keys are included in those various methods.

Perhaps if you create a post in the  MultiBit sub-forum, someone there can help you understand how that wallet works?

https://bitcointalk.org/index.php?board=99.0

Bitcoin Forum > Bitcoin > Development & Technical Discussion > Alternative clients > MultiBit


EDIT:  Apparently different versions of MultiBit handle the change in different ways.  It appears that the most recent version sends the change to whatever the second address is in your wallet (I assume if you only have one address, then it just sends it to that address?):

Which would bypass the need for all this? Cool  8)

Thanks

+1

Love this Addon!

Looking very nice - hope to see it appearing in the next major release (although you can do this and more with raw tx's it is going to be helpful to have something so easy to use in the GUI itself).

Jea if we find it in the next official release it would be great :D

+1 love the add-on!

Just reading this discussion has taught me a lot more about how bitcoin works. Looking forward to learning more.

As for backing up my wallet.dat, it always seemed easiest to just make a copy of that file, then encrypt and store the backup. In reading this thread, that also sounds like the most reliable backup.  Is it?  Does bitcoin-qt's wallet transfer across wallet clients?  When I upgrade to 0.9, will it be as straightforward as dropping my saved wallet.dat into the usual place?

It only seems to work for a limited number of upgrades. I tried pulling a v0.3 wallet out of storage with v0.8.1 and it puked. It looked like I could download every intermediate version of bitcoin and run them one at a time with it or just extract the keys with pywallet (my choice). I don't really know why previous wallet files aren't supported, there can't be that many changes in the file structure in that length of time.

wallets should always be forward compatible, but backwards compatibility is tricky because there has been various updates to the wallet format since 0.3.x.

The only cases I am aware of people having trouble "upgrading" wallets, is really because their wallet got corrupted somewhere along the lines.

If Bitcoin-Qt (or any other Satoshi-based client) does not cleanly exit, your wallet.dat is not intact!
It will depend on the database/ subdirectory until you resolve it with a clean shutdown.
If that directory disappears on it (or is replaced, etc), you may be losing money.

0.8.2 final has been released. (of the main bitcoin-qt reference client.)

But it does not contain CoinControl.

Yes :/

Not yet. I just bumped this thread in the hopes that whoever made the previous version will make an updated version with Coin Control.

Coin Control is crucial!

Sipa has an up-to date branch for coincontrol (https://github.com/sipa/bitcoin/tree/coincontrol). I have built it using gitian in my build VM. (VMWare Ubuntu guest, Windows 7 x64 host).

My Windows build¹: bitcoin-0.8.2-sipa-coincontrol-win32.zip (https://mega.co.nz/#!0p8CHaBJ!VY8hREczx4CMzQKCvVcZC3P5ME1o8StqyyVNZbLqUBw) (SHA b7bc93cdaacbe24b42bff6714d59a9fcc49e85dc)
linux users: do it yourself. you probably know how to do it and you don't have to trust me.
mac users: sipa's build script doesn't build mac (I think). sucks to be you, I guess.
https://i.minus.com/ib2JuNvqjGZpv4.png



summary of my build instructions:
http://bitcoin.sipa.be/builds/bitcoin-build.sh.txt

¹Standard disclaimer: While I'm confident my host system is virus free, and the probability of a virus infecting VM guests is low, I can not guarantee the build is clean. Hashes of the output files are generated within the VM, and are verified at the time of upload, so the risk of tampering in transit is low. However, audits of my build are always welcome.

Sweet.

update:

• v0.8.2
• Updates to the new dust logic
  
  • if you enter dust as recipient amount the label Low Ouput shows "DUST"
  • fee is calculated correctly according to dust, this is when change would be dust, its added to the fee
  • actual dust threshold is 5460 satoshis

Question: Why is not coincontrol idea/code implemented in the bitcoin-qt client?

How to proceed if one wants to help with testing?

grue, cozz, what's the difference between your builds? cozz is smaller (probably compressed) and doesn't include the warning message. But otherwise, are they the same?

grues doesnt include the Updates to the new dust logic. Also grues is based on some development snapshot, while mine is based on the latest stable version 0.8.2.

mine is based on sipa's branch, but it's otherwise the same as 0.8.2. The warning about not being a release version is there because I was too lazy to edit it out. Also, cozz's build is packed with UPX, hence why it's so small.

Is this stable enough for everyday usage ?

I'm considering installing it.

I've been using Cozz's build for awhile. I don't seem to have a problem. Not yet anyway. I'm only holding less than 100 BTC though.

you can copy to clipboard. simply direct right click.

I'm not sure about your particular transaction, but on main net with real bitcoins it works like this:

1. select inputs or rather, select unspent outputs. Only those selected will be used. Everything in those outputs will be used.
2. pay to 1bitcoinaddress. If there is change, you can send it back to a custom change address which can be the same as any of the addresses used by an unspent output.
3. add more recipients as you need, or spend everything so you don't have change.

I have no experience with newly mined coins with coin control, but I believe new coins can only be used after several blocks or confirmations, like 144 or 150 or something, I forgot exactly.

What do you mean by change? What is change? What change? What kind of change? What is a change address? I feel like I should know what this is, but I don't.

The change input field overflows to the right without being dynamic, as well as the change coin information when using the smallest default size for the client. I'm sure there's enough room to fit it all compactly.

Where is this info? I can't seem to find it on the wiki. Maybe it's in the source code? Anyway, that just means you need to wait a little bit less than a day to use newly mined bitcoins, or about 20 hours.

Hi. Thanks for the coin control.
Waiting for coin control in 0.8.3

update: v0.8.3

Great!
Thank you very much for your work :)

Yeah, Thank you very much

It works for me. Thanks!

You are welcome to vote for Coin Control as Bitcoin Project of the Quarter:
https://bitcointalk.org/index.php?topic=251087.0

I would like to build on Windows myself (using EasyWinBuilder;)). Unfortunately the github link is not working any more and the linux source archive seems to be missing the Qt project file.

Trying Sipa's branch...

Here: https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages

Rule 12. For each input, if the referenced output transaction is coinbase (i.e. only 1 input, with hash=0, n=-1), it must have at least COINBASE_MATURITY (100) confirmations; else reject this transaction.

The bitcoin client might decide to wait longer, but below 100 confirmations the network would reject the transaction.

I updated the source code link now

Thanks!

Before I dump my time into it... do you also have a hint on this one?

looks like you are using the original bitcoin-qt.pro, not the new one. I have tested the code I gave you again, it sure compiles for me.

My bad.  ::)  Compiles like a charm (tip sent).

Just wanted to point out this is available for testing on a more recent "next-test" build:

Bitcoin-Qt next-test 2013-07-21 (https://bitcointalk.org/index.php?topic=260749.0)

this might be of interested to you cozz: https://bitcointalk.org/index.php?topic=227287.msg3005468#msg3005468

thanks again (as i already used it for a long time @ btc) for your work!
is your signature address still valid (ie, no lost privkey) so i can send you a little donation?

greetings

https://bitcointalk.org/index.php?topic=287351.0
Version 0.8.4 of the standard QT client released.

update: v0.8.4

Wow, Thanks for the very fast update!

https://bitcointalk.org/index.php?topic=293307.0
Bitcoin-Qt / bitcoind version 0.8.5 released

Cozz, also, your previous version, 0.8.4 had the wrong dates, or you dated it all 2011. Don't forget to use the current date when you update this. Thanks!

update: v0.8.5

@Dabs: changed date in my build script this time

Thank you :3

Can someone please work on creating a test plan and working through it so we can merge this? :(

cross post fyi
[my emphasis]

Maybe it's not even so bad: https://github.com/bitcoin/QA/

I would be happy to help testing.

edit: had not even seen gmaxwell's post above  ::)

edit2: This might be helpful: https://github.com/dserrano5/QA/blob/0ad3091599c71bcca602926adf7d6ac180e21d36/SpendFrom.md

edit3: I had expected a test plan to cover at least the majority of possible cases including lots of edge cases...  what I see is more like a well documented sanity test. The above SpendFrom.md test plan with some additions should do the job.

it's not a matter of whether it's been behavior-tested enough in the field, it's a matter of ongoing test support, thus the request for a plan.

a test plan matters and it is not "bureaucratic nonsense". if you distribute software that breaks or has bugs creep in, especially with financial software, it reflects poorly on the developers.

also many ppls (including me) are using CC since it was available (both versions, first coderrr's, now cozz's).

I haven't tried to break it. But it hasn't failed me yet.

Greetings!

Thank you for developing such a great plug-in/add-on to bitcoin-Qt.

IMHO I think it should be available as default to official client.

I heartily agree!

Kaj ankaŭ, kun nomon tiel vian kaj vian verdstelon, mi vetas, ke vi povas legi ĉi tion sen tro malfacileco.

... then volunteer to run through the test plan (https://github.com/cozz/bitcoin/blob/cozz1/cctestplan.md) and help shake out any bugs. Code that touches the wallet is particularly sensitive, because an obscure bug might cause lots of people to lose lots of money.

Edit: sorry, it actually reduces the amount sent, which is the safer thing to do.  I tried this twice (once exhausting the inputs, once not) and mixed up the transactions when I viewed them.

It looks like the fee source depends on the structure of the sending wallet -- apparently it will take the fee above-and-beyond the amount sent if it can, and otherwise it reduces the amount sent.  It might be nice to mention this behavior to the user…

I found a small bug, although I'm running a somewhat outdated version of coin control so this might be fixed.

Select inputs for a transaction such that the inputs are just enough to fund the transaction and its fee "under ordinary circumstances".  If the resulting transaction winds up being "over the size limit" the client will ask the user if they want to pay the extra 0.0005BTC but won't ask where to take the fee from the chosen inputs (since they're exhausted).  Instead it appears the fee is simply taken from some other random input in the wallet, potentially compromising privacy.

FWIW, the privacy provided by the coin control client in the presence of this bug is still strictly superior to the legacy client, so this report should not in any way delay the integration of coin control into the legacy client.

Are you saying that if I run through that test plan and confirm that it doesn't turn up bugs you'll upstream the patches?

Because if that's what you're saying, I'll do it.  Please bitmessage me, I read the forum infrequently.

But if this is just another excuse/double-standard I have better things to do.

cozz, would you be willing to do this for an alt-coin? I have one in mind.

How do I use the command-line client?

I am not asking how to use it in general -- I have been using the standard bitcoind command line client (bitcoind) for a while. I am trying to figure out how to use this one to one key thing... send many from a specific bitcoind ADDRESS (not account) to one or more addresses, each with varying amounts, and as a bonus, specify the change to a certain address.

I thought this was the point of this release, right? What am I missing here? I need to use the command line interface.

The point is to let you micromanage what coins (UTXO entries) you consume in a given transaction.
There is no such thing as a "from address".

Well I am trying to control what coins are being consumed in a given transaction... as in which unspent inputs... but how would I do this?

by selecting the outputs you want to use...

Correction. But yes. I want to choose which of the unspent transaction outputs to "consume" in a new outgoing transaction.

On another note, electrum has a payto command (and a paytomany) that allows you to specify the from address. I am assuming this is essentially doing what I am talking about here, right?

This is a bug. There is no from address.

electrum help payto
Create and broadcast a transaction.
Syntax: payto <recipient> <amount> [label]
<recipient> can be a bitcoin address or a label
options:
 --fee, -f: set transaction fee
 --fromaddr, -F: send from address -
 --changeaddr, -c: send change to address

Are you saying that the "feature" where I specify the fromaddr above is misnamed, or something else? I assumed that by specifying the from addr, it simply would only use unspent transaction outputs that were going to that specified address, as the inputs for the new outgoing transaction.

Is this incorrect?

It's not a feature, it's a bug. There is no use case for selecting UTXO entries based on the transaction they were created by.

Hmm.

So what does this in fact do? I realize you said it is a bug. From how I saw it when I used it, I specified the "from" address to source funds from, and the resulting new transaction showed that unspent outputs to that from address ALONE were used to source the new transaction. Maybe I am just missing something fundamental here.

Doesn't look like a bug to me.

Using all of (and ONLY) what's at one address in each transaction is by far the best way to prevent people from being able to infer that UTXO 1 and UTXO 2 are held by the same wallet (which is you).  Meaning they can't link you to other transactions besides those that created UTXOs having that address.  Which were already linked, if you dealt with someone who was such an idiot as to pay more than once to the same address.

So, yes, I have a use case for "micromanagement" of the from addresses.  It's called privacy.  Coin control ought to have a setting that lets me make it automatic, or at least warns me if I can't make a transaction that follows that rule and lets me *PICK* which UTXOs I don't mind someone linking.

Call it a feature that you find useless then. That's all but the definition of a bug.

I would have to agree that Luke-Jr seems to be a bit confused about what a "bug" is.

Perhaps he is just getting a bit overzealous about his dislike of this "feature".  ;)

Frankly it seems to work as advertised. That's why I am puzzled why it is being called a bug.

Bugs are supposed to be behaviour that do not reflect what is expected behaviour.

I just tried out CoinControl build from the OP. The thing that I noticed was that it downloaded? and checked the whole chain again. This tool very long. But the GUI now makes sense to anyone, what Bitcoin-QT did not. 20 BTC in there, 1 spent, 0 remaining.

I think in sense of acceptance the CoinControl stuff should get into the 'official' release ASAP.

One question is still open for me, however: the CC stuff uses the 100 addesses generated when the wallet was created, right? Will it - when the 100 addresses for change are used - generate 100 new ones or one-by-one with any transaction? So, I unsure about the backup strategy for the wallet...

It is already merged into what will become 0.9.

Bitcoin-Qt will create a new address every transaction, to ensure you always have 100 unused.
So I recommend backing up every 90 transactions.
Note this is entirely unrelated to coincontrol...

Well that is something I think we can all agree will be a great additional feature for bitcoin-qt!

It is a good idea to have multiple backups created at different times, just in case something happens that makes your most recent backup unusable.

I generally recommend keeping an approximate count of addresses generated with the "New Address" button, and of transactions sent.

Create a new backup when the sum of those two counts is about 25, and store the 3 most recent backups in different locations (in case of fire, flood, tornado, earthquake, etc).

That way you'll always have 3 backups that can be used to recover the entire balance of your wallet.

I think I'm paranoid. I create 3 backups of my wallet.dat prior to every start of the app - so actually on a daily basis. These files are than backed up to a second HDD in my laptop and both HDDs will be synced to an external drive from time to time. I have about 3 (per backup un) x 400 files x 3 HDDs.

just use git then ;)

Well, I could give it a try to keep my backups in there, sure....

I do a backup every other transaction or when I remember. I could easily set it up so there is a daily backup which goes to another computer, or encrypted in the cloud or something. The wallet.dat file is relatively small compared to all other things that I work on, although it is already about 4 MB. (all those transactions take up space.)

What I like to do is take a simple dump of the private keys once in awhile, using pywallet, print it, stuff that in an envelope and lock it in my office where it's protected by armed guards.

But even at 4 MB, I can just copy that file every week to a few of my USB flash drives.

The way I use Coin Control, I usually either spend it all, or specify a particular change address (sometimes back to itself) so I don't think that generates a new private key in the key pool. Besides, you can see all the keys that have unspent inputs.

0.8.6 released.

https://bitcointalk.org/index.php?topic=364353.0

While we wait for 0.9.0 with built in coin control.

https://bitcointalk.org/index.php?topic=320695.0
Bitcoin OMG10 (0.8.5 with all of 0.8.6's bug fixes) already has Coin Control.

I like Cozz's version. Good to have alternatives, but I will also give bitcoin OMG a try.

Bitcoin OMG *is* Cozz's version.

Yes, please use wtogamis binaries, this patch is included there.

Okay. Thanks! I like Coin Control. The OMG binary isn't compressed though, so I thought someone else was working on it. (but that's just executable compression, so not a big deal.)

I feel like OMG is not thought of as an addition or bleading edge thing, but tries to get people away from the official reference client?

Dia

You see it upside down.
The official reference client tries to get people away from itself.
Pretty effectively, in fact.

Please do not feel alarmed.  This is merely a decentralized variation of the reference client that is intended to help improve the 0.8.x and master branches.  OMG testing has directly contributed to the selection of patches that went into 0.8.6.  OMG was also very helpful in testing various candidate patches for the MacOS leveldb corruption issue (https://bitcointalk.org/index.php?topic=337294.0) as shipped in 0.8.6.  wumpus also points out that we caught the deleteLater issue with Coin Control thanks to OMG.

Bitcoin OMG was published because a ton of work was put into testing the backport patches shipped in Litecoin 0.8.x and it was not much more effort to repackage those patches into a Bitcoin client.  Users want features like Coin Control and through many months of testing and some of feedback to cozz it has improved to a point where I personally feel comfortable using it in these 0.8 backports.

As far as client security goes, OMG has its own gitian.sigs (https://github.com/litecoin-project/gitian.sigs.omg) where random members of the public are invited to help verify with their own GPG-signed gitian sigs.

Please be respectful to the Bitcoin devs.  We are all in this together.

I think the reference client is conservatively stable. It should be that way. The source is open, so anyone who wants new features can add to it, just like what we are seeing with Coin Control and OMG and no wallets.

Those additional features can possibly have bugs. In any case, both the reference client and the modified versions are not recommended for new users.

I do recommend people to study it, and if you're going to have any amount of bitcoins or litecoins, you might as well learn how the whole thing works, and QT is a good place to start. Also, another full node is good for the network(s).

What you should have said is "Bitcoin OMG is just backporting patches from Bitcoin 0.9, I'm not actually writing these things." because it seems some people think otherwise!

Sounds like you're jealous that your super-team (aka the bitcoin elite) cannot manage to make it before him.

My advise: less patronizing - more work... and maybe one day you will become equally efficient in pulling patches. Doubtfully, but maybe... :)

People.  Calm down.  Litecoin and Bitcoin OMG regularly backports bug fixes and features for the purpose of testing.  Various bug fixes in 0.8.3 through 0.8.6 and master were directly or indirectly influenced by our work.  Much of it was not directly written by us but was the result of a collaborative effort.  Most of the credit goes to the Bitcoin devs.

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.

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.

Ok, it's clear, you seem hell-bent on ranting instead of taking this into constructive territory. Have fun.

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.

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.

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.

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!

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.

"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.

They are spending all their money hiring lobbyists, lawyers and PR.

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!

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.

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?

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.

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/

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.

@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

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

Still a bug.  ;D


Done already, no responses yet.

https://github.com/bitcoin/bitcoin/issues/3840

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.