Advantage of coin control, response to Mike Hearn

[Rothgar]

For something like coin control, parts were merged already, but the GUI wasn't. Well, honestly, if I was maintaining a wallet (I'm not) I wouldn't merge it either. We should be trying to make Bitcoin easier to use and less nerdy, not exposing the guts of the protocol in the UI. Rather I'd want to figure out a list of what people are using the coin control gui for - find a list of use cases then encourage people to implement them in a more direct way. Is this a privacy thing? Is it an accounting thing? Both? Neither? There's probably a better way to solve those problems.

This post is intended to be factual, and answer for what people use coin control for.  Yes it can help a privacy.  But it can make micro-payments (dust) more profitable for the user.

Say a user has 1.02 BTC at one address and .00012381 at another.  When the user wants to pay .2 BTC to another a transaction can be made that draws both inputs and yields the .2 payment output and a .82012381 change output.  This allows a user to merge micro-payments into spendable outputs.  Do this several times and much BTC in fees could be saved making the .00012381 payment worthwhile. 

[1714022105]

1714022105

[1714022105]

1714022105

[1714022105]

1714022105

[1714022105]

1714022105

[1714022105]

1714022105

[etotheipi]

For something like coin control, parts were merged already, but the GUI wasn't. Well, honestly, if I was maintaining a wallet (I'm not) I wouldn't merge it either. We should be trying to make Bitcoin easier to use and less nerdy, not exposing the guts of the protocol in the UI. Rather I'd want to figure out a list of what people are using the coin control gui for - find a list of use cases then encourage people to implement them in a more direct way. Is this a privacy thing? Is it an accounting thing? Both? Neither? There's probably a better way to solve those problems.

This post is intended to be factual, and answer for what people use coin control for.  Yes it can help a privacy.  But it can make micro-payments (dust) more profitable for the user.

Say a user has 1.02 BTC at one address and .00012381 at another.  When the user wants to pay .2 BTC to another a transaction can be made that draws both inputs and yields the .2 payment output and a .82012381 change output.  This allows a user to merge micro-payments into spendable outputs.  Do this several times and much BTC in fees could be saved making the .00012381 payment worthwhile. 

As far as I'm concerned, the answer is splitting the interface into usermodes.  That's why Armory has a "Standard", "Advanced" and "Expert" usermode.  Custom change addresses and coin-control only appear if the user explicitly changes the mode to "Expert."  It's a very elegant solution to making these "manual-transmission" features available while still giving most users the automatic transmission.

Although it's easiest if the windows are laid out in code.   Then in the code you say: 

Code:

layout = QVBoxLayout
layout.addWidget(button1)
layout.addWidget(button2)  
if usermode=="Expert":
   layout.addWidget(button3)

[wumpus]

As far as I'm concerned, the answer is splitting the interface into usermodes.  

Isn't this already the case with the current coin control pull? I haven't tested it myself yet, but I was told that it's disabled by default:

https://github.com/bitcoin/bitcoin/pull/2343

[Mike Hearn]

That is indeed a useful thing, but coin control is the wrong way to do it (which is what I've been getting at all along).

Automatically defragmenting wallets are something that has been discussed, at least on IRC, quite a few times.  As long as miners are willing to bias their priority calculations towards transactions that reduce the size of the UTXO set it can make sense. Not only when you create new payments, but for example at night time if your wallet is open (or on an always-on device like an android).

My point about coin control is that whatever problem you're solving with it, you can usually see a better solution that works for more people.

[etotheipi]

That is indeed a useful thing, but coin control is the wrong way to do it (which is what I've been getting at all along).

Automatically defragmenting wallets are something that has been discussed, at least on IRC, quite a few times.  As long as miners are willing to bias their priority calculations towards transactions that reduce the size of the UTXO set it can make sense. Not only when you create new payments, but for example at night time if your wallet is open (or on an always-on device like an android).

My point about coin control is that whatever problem you're solving with it, you can usually see a better solution that works for more people.

And my point, based on experience, taking feature requests from hundreds of users and trying to negotiate things in designing Armory... some users just want control.  I agree with you that the fee logic could be updated to favor cleaning up dust.  But that's not the only reason people use it (though, it might be the base for the OP, here).  The advanced folks who understand how it works under the hood *want control".  It's the same reason I will always drive a manual-transmission even though automatic technically does the same thing for me.

[etotheipi]

Maybe I am missing something.  Does Armory have this already?  Why do you want a change to the Bitcoin software if this be done by a wallet or plugin that sits on top of the main software? 

Armory lets you control the source addresses, not the individual coins (but still called "Coin Control").  People requested "Coin control", I gave them that, and I haven't really heard any complaints.  So I left it alone.

[2112]

That is indeed a useful thing, but coin control is the wrong way to do it (which is what I've been getting at all along).

Automatically defragmenting wallets are something that has been discussed, at least on IRC, quite a few times.  As long as miners are willing to bias their priority calculations towards transactions that reduce the size of the UTXO set it can make sense. Not only when you create new payments, but for example at night time if your wallet is open (or on an always-on device like an android).

My point about coin control is that whatever problem you're solving with it, you can usually see a better solution that works for more people.

You aren't going to get anywhere on this line of thinking, except simply digging a deeper foxhole for yourself.

The benefit of the so called "coin control" for nearly every user is in allowing him/her to see the how the protocol operates "under the hood". This is a great learning tool both for the beginning users and for the developers that begin to work with Bitcoin.

Even if the significant portion of the "coin control" users wont use it for the "control" but just as a magnifying glass to see whats inside their wallet, it will be a great upgrade to the reference client.

Maybe just rename it from "coin control" to "coin loupe & tweezers"?

[coqui33]

Some of you guys are missing the point. If you make and sell ice cream, it is pointless to argue that nobody really needs pistachio flavor, that other flavors are just as tasty. You may be absolutely right. But the public (the buyers) could care less what you think, even if you are right. They want pistachio flavor.

The public wants to be able to import privkeys in order to send money out of them, to choose the privkey from which the money will be spent, and to delete privkeys when done.

Etotheipi "gets" this. He provides what customers want, rather than what he thinks they should have. He will succeed and, when btc softare is sold for money, he will become rich. Those who try to dictate what the customer needs, not so much.

[ShadowOfHarbringer]

That is indeed a useful thing, but coin control is the wrong way to do it (which is what I've been getting at all along).

Automatically defragmenting wallets are something that has been discussed, at least on IRC, quite a few times.  As long as miners are willing to bias their priority calculations towards transactions that reduce the size of the UTXO set it can make sense. Not only when you create new payments, but for example at night time if your wallet is open (or on an always-on device like an android).

My point about coin control is that whatever problem you're solving with it, you can usually see a better solution that works for more people.

You aren't going to get anywhere on this line of thinking, except simply digging a deeper foxhole for yourself.

The benefit of the so called "coin control" for nearly every user is in allowing him/her to see the how the protocol operates "under the hood". This is a great learning tool both for the beginning users and for the developers that begin to work with Bitcoin.

Even if the significant portion of the "coin control" users wont use it for the "control" but just as a magnifying glass to see whats inside their wallet, it will be a great upgrade to the reference client.

This x 100.

There should always be an EXPERT mode, perhaps even unlockable using INI FILE SETTING to satisfy Mike Hearn as he is so afraid of complicating things for "dumb end users" (stupid people are usually afraid to touch configuration files).

Actually this is the reason i created my fork, because Gavin didn't want to give me control over if i want more risk or not. Why not just make a stupid configuration setting in *.ini file ? This is very little work.

[ShadowOfHarbringer]

@Mike

Look how mozilla solved your "dumb user" problem. Show a big warning, and if the user proceeds, that is his responsibility if he breaks something or loses money.



*Learn from the best*

[etotheipi]

@Mike

Look how mozilla solved your "dumb user" problem. Show a big warning, and if the user proceeds, that is his responsibility if he breaks something or loses money.

(img)

*Learn from the best*

Let's not bash on Mike too much.  I sympathize with his position -- also coming from the development side, I know how hard/frustrating it is to meet the demands of users for features that may be transient requests, for functionality that seems like it can provided in other ways (spend a week implementing it, then a month later it's obsolete by the other features you put in that serve the same purpose, or the original users don't find it that exciting after all).  It's part of the reason I didn't do coin control for so long -- I didn't even know how to design it because I didn't understand what users wanted or why they wanted it.  How is it supposed to be on my priority list when it has such little value to myself?

In this case, the OP made a specific argument, and I agree with Mike that the specific request by OP is "addressed" by other solutions.  But I think OP, like so many other users, just want the level of control they understand is possible, and he tried to justify it with that particular example that Mike disagrees with.  Everyone is "right" here:  the fee logic should be updated to favor reducing UTXO set size, clients will adapt to the new rules by favoring reducing UTXOs, and users should have control over the source addresses/coins anyway, because some of them prefer to use their knowledge to optimize coin selection for their specific needs on a per-transaction basis, better than the default logic included in the app, and such advanced features should be hidden in the default installation of the app.

[CIYAM]

Having an *expert* mode is the right approach - there are many reasons why expert users might want/need "Coin Control" - to stop them having it to "protect the newbies" doesn't make any sense at all.

[Mike Hearn]

It'll ultimately be up to Gavin. Having specialist wallets like Armory that cater to people who have a deep knowledge of the protocol and tolerance for screwing with fiddly details isn't inherently a bad thing, but should Bitcoin-Qt be that wallet? Well, if we're going to start pushing users towards MultiBit then maybe it doesn't matter if the UI of Bitcoin-Qt is intimidating and full of features only useful for a small number of people. Because not many people will use Bitcoin-Qt any more.

Whatever wallets end up being in the recommended default set, I don't think they should be targeted at the sort of people who want coin control. Sorry. If Bitcoin is going to scale up and become widely used, it has to be drop dead simple, and not have any sharp edges. There's a reason Satoshi released Bitcoin 0.1 with a friendly Windows GUI and not as a command line tool, even though the latter would have been less work.

[wumpus]

He will succeed and, when btc softare is sold for money, he will become rich.

You're joking right? Hmm maybe we should sell the "expert mode" powerup for money :-)

[coqui33]

You're joking right? Hmm maybe we should sell the "expert mode" powerup for money :-)

Great idea! I would definitely pay good money for a simple, single-purpose bc spender that enables:

(1) import a privkey
(2) spend from it
(3) delete the privkey

Nothing more. Everything else is superfluous complication that stops my granny from using bc. It need not even show the balances in my privkeys, since I can easily get this information on the web.

Three functions: import, spend, delete.

The only reason you call this utter simplicity "expert mode" is because you cannot resist throwing in many other functions that few uninterested-in-bitcoins end-users care about. Again, import, spend, delete. Do that--and nothing but that--and you can charge $30 a copy (especially if you make Android, Mac, and Windows versions.)

[justusranvier]

You're joking right? Hmm maybe we should sell the "expert mode" powerup for money :-)

Great idea! I would definitely pay good money for a simple, single-purpose bc spender that enables:

(1) import a privkey
(2) spend from it
(3) delete the privkey

Nothing more. Everything else is superfluous complication that stops my granny from using bc. It need not even show the balances in my privkeys, since I can easily get this information on the web.

Three functions: import, spend, delete.

The only reason you call this utter simplicity "expert mode" is because you cannot resist throwing in many other functions that few uninterested-in-bitcoins end-users care about. Again, import, spend, delete. Do that--and nothing but that--and you can charge $30 a copy (especially if you make Android, Mac, and Windows versions.)

I understand (1) and (2), and I can understand hiding private keys with empty balances, but deleting them seems like a disaster waiting to happen.

[etotheipi]

You're joking right? Hmm maybe we should sell the "expert mode" powerup for money :-)

Great idea! I would definitely pay good money for a simple, single-purpose bc spender that enables:

(1) import a privkey
(2) spend from it
(3) delete the privkey

Nothing more. Everything else is superfluous complication that stops my granny from using bc. It need not even show the balances in my privkeys, since I can easily get this information on the web.

Three functions: import, spend, delete.

The only reason you call this utter simplicity "expert mode" is because you cannot resist throwing in many other functions that few uninterested-in-bitcoins end-users care about. Again, import, spend, delete. Do that--and nothing but that--and you can charge $30 a copy (especially if you make Android, Mac, and Windows versions.)

I'm not sure this embodies simplicity.  It embodies simplicity once you understand private keys, but I'd like to hide user-handling-private-key-data entirely (because they're likely to not realize it's different the addresses which are okay to send to your friends).  They should make a backup of their wallet and told to keep it secure, but that's it.  Beyond that, the way forward is "Wallets" and "Balances".  I'd almost be in favor of referring to addresses as "one-time payment codes", to even hide the "addresses" concept to users that only care about how many BTC they have.  A user has a wallet, and balances on each of those wallets.  Combined with "wait 2+ conf for small payments, 6+ confirmations for huge payments", this is enough for users new to Bitcoin to actually be functional.  This is what I want to see in the Satoshi client.  And eventually in the "Standard" usermode in Armory.  

For now, it sounds like Bitcoin-Qt and Multibit and Electrum are going to work on that user-frieindliness aspect.  Armory, bitcoind, and electrum-CLI are going to work on that advanced user aspect.

[wumpus]

 I'd almost be in favor of referring to addresses as "one-time payment codes", to even hide the "addresses" concept to users that only care about how many BTC they have.  

Agreed. By calling the public keys an address an storing it in an 'address book' encourages re-use, which should be prevented. The aim is that the payment protocol is going to make it possible to move the whole 'address' thing to a background role.

[coqui33]

I understand (1) and (2), and I can understand hiding private keys with empty balances, but deleting them seems like a disaster waiting to happen.

Then let me explain. You are coming at it from the bitcoind or bitcoin-qt direction: What added features are needed? I am coming at it from the opposite direction: What is the minimum functionality needed for my granny to spend her money?

You are assuming that all of granny's privkeys reside in the software "wallet". I am assuming that the software is stateless, non-persistent, and contains no privkeys at all. It is empty. No addy/privkey pairs. None. When granny wants to spend some money, she chooses one of her privkeys from her secret hiding place, imports the privkey into the software, spends whatever money she wants to spend, and quits. Again, the software retains no persistent memory of her privkey. None. If she wants to track confirmations and/or balances, she can do it on the web.

You ask: "Well then, where is her secret hiding place where she keeps her privkeys?"

Granny answers: "Hah! You are the last person whom I would tell, young feller! They are hidden the same place where my other secret stuff is hidden. (Cackle!)"

In short, you assume that granny (who jealously guards the numbers to her offshore bank accounts) is too naive to guard her privkeys. Granny is not stupid. She is very smart indeed. She may be ignorant (uninformed) regarding bc, but she automatically relates her privkeys to her offshore account numbers or her safe-deposit vaults. You envision the user as an irresponsible teenager. I envision the user as someone living off a million-dollar nest egg that is being devoured by inflation.

[etotheipi]

I understand (1) and (2), and I can understand hiding private keys with empty balances, but deleting them seems like a disaster waiting to happen.

Then let me explain. You are coming at it from the bitcoind or bitcoin-qt direction: What added features are needed? I am coming at it from the opposite direction: What is the minimum functionality needed for my granny to spend her money?

You are assuming that all of granny's privkeys reside in the software "wallet". I am assuming that the software is stateless, non-persistent, and contains no privkeys at all. It is empty. No addy/privkey pairs. None. When granny wants to spend some money, she chooses one of her privkeys from her secret hiding place, imports the privkey into the software, spends whatever money she wants to spend, and quits. Again, the software retains no persistent memory of her privkey. None. If she wants to track confirmations and/or balances, she can do it on the web.

You ask: "Well then, where is her secret hiding place where she keeps her privkeys?"

Granny answers: "Hah! You are the last person whom I would tell, young feller! They are hidden the same place where my other secret stuff is hidden. (Cackle!)"

Have fun explaining change addresses to granny.  And reminding her to take note of how much change was created, so she can manually update her documentation to make sure she knows how much each key has.

Also, at least until something like Ultimate Blockchain Compression is implemented, "importing" a private key is a disaster.  You either trust someone to tell you how much each address has, or wait 30 minutes for a blockchain scan to complete.  (right now, there is no way other than to do a blockchain scan).