Topic: Advantage of coin control, response to Mike Hearn - page 2. (Read 4707 times)

Clearly a user might not want UTXOs to be consolidated b/c that could break privacy.  And personally I think that private keys are a great way to make paper wallets so I don't see them disappearing any time soon.  Many articles have been written abt how paper may actually be a more robust long-term storage then electronic formats (try to read that 8" floppy... do you even know that they existed?) so whether you agree w/ this or not it is clear that many people will.

So, how about the wallet by default does UTXO consolidation, etc, and generally allows you to access it exactly as you do today,  but there is an option that allows you to create a new "wallet section" (this sort of gets you into an "expert" mode without forcing the explicit request onto you).  If you create a new section (and name it something else), then private keys, UTXOs, etc do not cross the section.  Also, you can select which wallet section to pay out of.  You might ask why not just pop up 2 copies of the client... but there is the issue then of 2 blockchains on fully validating clients, and also why does firefox give you tabs, why do all doc programs let you open multiples at the same time.  There is clear value.

LOL! NP.

Woah,  quite an extreme there.  How about Granny gets the former and I get the latter. 

Precisely so.


Precisely so.


If granny prefers the elegant simplicity (of looped-back change) to "privacy" at the cost of complexity (figuring out where her change is going), she will buy the former and the latter will rot on the shelf.

No change is not required to go to a different address.  The client does this to preserve privacy of the user.  Bitcoinspinner is an example of a one address wallet.  I think users should remove coins and then get a new address every once and a while to preserve privacy.  I would still keep a backup for fun.

Imagine years from now inspecting all the old wallets and finding 0.01 BTC of a tip or mistake that was sent to you.  That would be fun!

Does change *have* to be sent to a different address from any of the inputs? I see nothing in the protocol that prohibits this. The reference client just happens to send change to a different address for some reason.

In a minimal client that was proposed above, Granny could send money from address A, which she controls, to address B, which she does not control, and then sends change back to address A.

Also, remember that Granny can keep track of her balance(s) with a "watch only" wallet client. She doesn't have to trust anyone but her own full client for that information.

I agree with you Mike that having a smart algorithm that consolidates dust while making payments would be the way to go for the average user.  I personally have no complaint about the current situation as Armory does what I like.  Heck, even blockchain.info has coin control, they just call it custom transactions.  So the current situation is more than sufficient for my purpose.  I wouldn't want to use a wallet that does consolidating transactions with out asking me and requiring a password.  I think the defragmenting could be incorporated into the payments that are sent by normal use by the user.  Such defragmenting may make the advantage of coin control not as great.  Either way I still would want coin control and I have it. 

I really appreciate the hard work of all the developers. 

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

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.

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.

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.

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.

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

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

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.

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.

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.

@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*

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.

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.