Yet another Coin Control Release [CLOSED]

[sgravina]

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

[ShadowOfHarbringer]

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?

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

[kuzetsa]

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

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:

Main

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

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.

[cozz]

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:)

[eldentyrell]

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?

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.

[ShadowOfHarbringer]

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?

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

Oh, really? http://underhanded.xcott.com/

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.

[cozz]

UPDATE: v0.8.1

[Gavin Andresen]

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.

[BitcoinAshley]

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.

[ShadowOfHarbringer]

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?

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

Oh, really? http://underhanded.xcott.com/

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.

I don't think you understood the contest. The point was to write a short, simple, readable program that hid underhanded behavior. Even experienced programmers can miss that there should be a semicolon somewhere, and there isn't, for example.

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.

[kwukduck]

great work

[joeybean]

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 

[Luke-Jr]

FYI, this is included in next-test 2013-04-12.

[ShadowOfHarbringer]

FYI, this is included in next-test 2013-04-12.

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

[doobadoo]

What is an unspent output?[/b]
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.

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.

Now lets say you want to send someone 0.1 ...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. 

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.

[Birdy]

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

[WilderedB]

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?


 

[DannyHamilton]

- snip -
but if you lose your wallet you lose those 9 BTC because you don't have the key for them?

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

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.

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.

[WilderedB]

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.

[DannyHamilton]

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?

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?):

I have altered which address is used for your transaction's change address.

Previously change always went to the first address in your wallet. (It is not a very sophisticated algorithm admittedly).

Recently there have been a number of people importing their blockchain.info backups into MultiBit. I think this is a combination that it is now doable (it takes about 30 minutes on wifi) and the recent blockchain.info DDOS attacks.

With change going to the first address in a wallet change was always going to the initially created address, not one of the blockchain.info imported keys. This is a bit confusing.

With the change address the second address (where it exists) the change will go into one of the imported key addresses. You will see your bitcoin in both MultiBit and blockchain.info.

For regular transactions it should not make much difference.
It will appear in the next live release.