My (and many others') rant about Bitcoin-QT

[caveden]

Actually I think a "bitcoin for the masses" client should go the other way around: eventually hide all addresses from users, and just let them know they have "wallets".

All you need to know is that you have "wallets" or "accounts". Whenever you want to receive money in one of your wallets, your client generates you an URI, a QR-code or a simple file that contains a master public key for a deterministic key sequence. This master public key could be generated via a another "master-master-key", basically you'd have a grand-master-key for a wallet, which could generate different master keys for each time you want to produce a "bill".
You'd send this file/URL/QR-code to the payer. He'd add it to his payees' list, your name would show. Every time he wants to send you anything, he just chooses your name, and his client generates a new key from the master-key it has.

Users would only see something like an address is if they ever try to read the URI/file/QR-code - what they don't really need to. And once the secure payment protocol is implemented, a payee with a recognized certificate could even use URL shortners instead. A feature rich client could smoothly integrate with some shortner when applicable. And even if you don't want to pay for a recognized certificate, sending a self-signed key once is no less secure than sending a plain address.

My point is that the technical complexity and "weirdness/geekness" of addresses can be hidden, making it much more user friendly IMHO. And at the same time we make sure people would use Bitcoin addresses as recommended: one per transaction.

[justusranvier]

Just by this measure, I would consider bitcoin-qt to be for advanced users.

Advanced users are better served by advanced clients. Bitcoin-Qt is not ideal for any use case.

[charleshoskinson]

That indeed sounds weird.

The old UI (wxbitcoin) used to generate new, unlabaled addresses in some circumstances. With Bitcoin-Qt this should not be happening.

The wallet starts with one receiving address, and all receiving addresses after that should be manually created. If receiving addresses still appear out of the blue with 0.8.x this is a (minor) bug. To be able to fix it I need a way to reproduce it.

Let me see if I could drag out some screenshots and also his configuration. I figured you'd like to know about this one.

[wumpus]

My point is that the technical complexity and "weirdness/geekness" of addresses can be hidden, making it much more user friendly IMHO. And at the same time we make sure people would use Bitcoin addresses as recommended: one per transaction.

Yes we agree on that, that's the plan.
"Receive" tab will be a place to create payment requests (ie a URI or QR code), no longer a list of addresses, as that encourages re-use and is confusing to users.

Advanced users are better served by advanced clients. Bitcoin-Qt is not ideal for any use case.

What people forget is that bitcoin is still beta software. It may sometimes appear that way in retrospect but it is not completely obvious what is the best way to do things. The experimentation that the different clients/frontends do is good. We cannot revamp the interface every version for experimentation and lulz, so when we change it must be an overall improvement (that's validated somewhere else).

[kjj]

C. CASE #3

1. There is / are account(s) in a wallet. There are addresses in accounts - I am correct?

2. When I pay BTC 1 somebody for a service, the remaining BTC 9 are sent to a hidden address. These BTC 9 are sent internally to the same account as the original BTC 10 or to a new account?

1.  Incorrect.  Accounts are a purely local bookkeeping measure.  You can associate one or more addresses with a given account, but that just means that new incoming payments to that address are added to that account balance.

2.  This entire question is based on a faulty premise.  Coins are not owned by accounts.  When you spend, the account you specify is decreased by the amount of the spend.  The coins used for the spend have absolutely no bearing on the account system. 

Start with a new wallet.  Generate a new address, associate it with account "A".  Receive 100 BTC to that address.

Default account: 0 BTC
Account "A": 100 BTC

Now create a new address, associate it with account "B".  Now spend 50 BTC, specifying account "B".

Default account: 0 BTC
Account "A": 100 BTC
Account "B": -50 BTC

At this point, your wallet also has a change address in it, with a 50 BTC UTXO that can be spent.  That address is not associated with any account, but since you'll never see it, you can't give it out to receive coins anyway.

Also note that at each step, the sums of the accounts was equal to the wallet balance.  0 + 100 = 100 and 0 + 100 - 50 = 50

You could use the move RPC command to "transfer" 1,000,000 BTC from acocunt C to account D.

Default account: 0 BTC
Account "A": 100 BTC
Account "B": -50 BTC
Account "C": - 1,000,000 BTC
Account "D": 1,000,000 BTC

And again, the sum works out.

[justusranvier]

What people forget is that bitcoin is still beta software. It may sometimes appear that way in retrospect but it is not completely obvious what is the best way to do things. The experimentation that the different clients/frontends do is good. We cannot revamp the interface every version for experimentation and lulz, so when we change it must be an overall improvement (that's validated somewhere else).

I actually don't think Bitcoin-Qt should exist at all, at least the way it is currently implemented as an all-in-one program. The reference client is built around a user case that doesn't match how people actually use computers.

Most people do most of their computing as part of a trusted LAN with N users, either at home or at work. These users do their computing on M devices each.

If M=N=1 then the design of Bitcoin-Qt would make sense, but actually that's a rare exception.

There is no absolutely no reason for a single LAN to store N*M copies of the blockchain, and attempt to maintain N*M connections to the outside P2P network.

I think bitcoind/Bitcoin-Qt should be split into modular components that better reflect the real-world use case.

You need one component that connects to, and participates in the P2P network. This same component can also be in charge of storing the blockchain. It doesn't need, and shouldn't have, anything to do with wallets. Call  this component "bitcoind" and advise users to install one copy per LAN as an always-on service. (1 copy)

You need a component that keeps track of a user's keypairs and the balances associated with them. Call this component "walletd" and advise users to install it on every device, with a separate instance running in the background for each users on that machine. (N*M copies)

Finally you need end-user applications. These can be command-line based, or graphical (Qt). These need to be installed on every device, but don't need to run all the time - just when the user wants to do something.

If this separation was achieved and Bitcoin-Qt was just a GUI interface with no blockchain management or P2P functionality, then it would be just one of many alternatives that could perform the same task. I question whether or not it would still be needed at this point, but in any case it would be much easier to upgrade and improve since it could have a release schedule independent of the other two modular components.

[wumpus]

I actually don't think Bitcoin-Qt should exist at all

I agree with your post, except that part. You make good points and further modularization, and bootstrapping as SPV client would be good things, and are in the planning. There is some work on a separate blockchain daemon, might make it to 0.10. But how do you get from there to "it shouldn't exist at all"? Are you trying to troll me?

Snotty replies such as yours really take away my motivation to work on this stuff at all. I went back to this forum after a long hiatus to help people, but this gets me annoyed really really fast.

[Terk]

I think bitcoind/Bitcoin-Qt should be split into modular components that better reflect the real-world use case.

You need one component that connects to, and participates in the P2P network. This same component can also be in charge of storing the blockchain. It doesn't need, and shouldn't have, anything to do with wallets. Call  this component "bitcoind" and advise users to install one copy per LAN as an always-on service. (1 copy)

You need a component that keeps track of a user's keypairs and the balances associated with them. Call this component "walletd" and advise users to install it on every device, with a separate instance running in the background for each users on that machine. (N*M copies)

Finally you need end-user applications. These can be command-line based, or graphical (Qt). These need to be installed on every device, but don't need to run all the time - just when the user wants to do something.

Bitcoin is already too complicated for general population. That includes people not understanding how clients, wallets, addresses, change addresses, etc. work. That includes people not knowing how to easily buy BTC for fiat money. And so on. It really needs to become much, much simpler to be usable to most people.

Now you want to introduce another technical barrier and requirement to install a separate server software and have it running on some kind of server machine (last time I checked most normal people didn't have a home server) in order to actually be able using a client software. Good luck with making my parents adopting bitcoin if we'll go in that direction.

[Terk]

That said, I'm all about the client-server architecture for trusted local networks. But it should be a separate product for more advanced users. The default and official client should be as easy to use for non-technical people as possible.

[Loozik]

Why are you (as a newbie) concerned what address the coins are on?

I am not concerned. Just asking questions to find out how the system works and how I can make a practical use of it. Why my interest in ''what address the coins are on''? - if I ever wanted to conclude a contract to purchase a car with an even less Bitcoin-knowledgable user I would put my (the payer's) address in the contract so that the seller could not argue in the court that the address from which he received the money wasn't mine. This is my silly newbie's reasoning. I am not concerned - just asking questions.

This is true if the sender of the address hasn't stored it somewhere, or it didn't get intercepted (privkeys, like any digital data, can be copied arbitrarily in transfer). If you generated it yourself with an offline tool you can assume this is safe.

So: Import only private keys of which you are sure no one else has them. Otherwise, importing addresses can be risky (as the address will be in two wallets, there's no saying what can happen, but the other person can spend them too and your balance can get corrupted).

In this event of two addresses and two privkeys in two different Bitcoin_Qts, I am correct to assume that the winner is the one of the two users / owners  who spends the bitcoins deposited to the address faster? The other guy loses?

For transfers of coins use a transaction, do not ferry around privkeys.

Why not? Because I might lose / damage such privkey or it might get stolen or for yet other reasons?

And whatever you do, never export addresses as a means of sending coins.

What does it mean in practice / real life ''to export addresses as a means of sending coins''. I lack the jargon.

I've never liked the account system much. It is an accounting mechanism and not an isolation mechanism, the addresses give the wrong indication: they are just receiving addresses for that account, they to not necessarily contain all its coins!. It's also not exposed in the UI.
In an upcoming Bitcoin-Qt (either 0.9 or 0.10) we are going to support true multiple wallets, which provide the isolation that you want here.

My first guess (proved false by you) was that Bitcoin accounts could be used like this:
a) you have a wife and a child: from acc #1 you manage your operations, from acc #2 you manage your wife's operations, from acc #3 you manage your offspring's operations, there is also acc #4 for the lady your wife shouldn't know about
b) you run three stores: and you assign each account and addresses within this account to a particular outlet,
c) you travel a lot: you can safely use and report acc #1 in any jurisdiction, acc #2 is a secret one,
d) etc...

Thanks

[wumpus]

That said, I'm all about the client-server architecture for trusted local networks. But it should be a separate product for more advanced users. The default and official client should be as easy to use for non-technical people as possible.

Indeed -- the internal modularization needs to have no impact at all on the interface. At most there will be an advanced option to point it at an external block chain daemon instead of the built-in one, so you can decide to trust someone instead of fetch your own chain.

This has all been discussed many times, is doable, and work is underway, the only limitation really is development and testing time. I sincerely wish more people would join in development instead of ranting on forums. Too many armchair devs here.

Making it user friendly is tough indeed; much of the recent client work is focused on higher-level abstractions, such as the payment protocol, so that it is possible to pay to merchants/people instead of addresses.

[wumpus]

I am not concerned. Just asking questions to find out how the system works and how I can make a practical use of it. Why my interest in ''what address the coins are on''? - if I ever wanted to conclude a contract to purchase a car with an even less Bitcoin-knowledgable user I would put my (the payer's) address in the contract so that the seller could not argue in the court that the address from which he received the money wasn't mine. This is my silly newbie's reasoning. I am not concerned - just asking questions.

OK, then it's fine. Questions are good, certainly better than rants

In this event of two addresses and two privkeys in two different Bitcoin_Qts, I am correct to assume that whoever of the two users / owners of such address, the winner is the one who spends the bitcoins deposited to the address faster? The other guy loses?

Yes. Exactly.

Why not? Because I might lose / damage such privkey or it might get stolen or for yet other reasons?

Because of the reasons I mentioned, such as inadvertent private key sharing. Use transactions to send coins to people.

What does it mean in practice / real life ''to export addresses as a means of sending coins''. I lack the jargon.

It means don't use "dumpprivkey". Ever. (I meant exporting privkeys, not exporting addresses)

My first guess (proved false by you) was that Bitcoin accounts could be used like this:
a) you have a wife and a child: from acc #1 you manage your operations, from acc #2 you manage your wife's operations, from acc #3 you manage your offspring's operations, there is also acc #4 for the lady your wife shouldn't know about
b) you run three stores: and you assign each account and addresses within this account to a particular outlet,
c) you travel a lot: you can safely use and report acc #1 in any jurisdiction, acc #2 is a secret one,
d) etc...

For (a) and (b) you can use them. That's exactly what they're for. They're just a ledger, so you can have say 20 coins in account A and 10 coins in account B. After spending 5 coins from account A there will be 15 coins in the account left... etc..

Apart from spending from them, you can move coins between accounts arbitrarily with the "move" command  (as kjj mentions). This moves the coins in the internal ledger.

You can also receive coins on accounts, so if you create a receiving address for account B, give it to someone, they send coins to it it will be credited to account B.

What I was trying to say is that they have zero association with low-level implementation details such as private keys and inputs, and do not provide any isolation on that level. So if you want to do hiding like in (c) they are not the appropriate choice. You need separate wallets in that case.

[Loozik]

1.  Incorrect. ..........

............And again, the sum works out.

Thank you.

[Loozik]

Bitcoin is already too complicated for general population. That includes people not understanding how clients, wallets, addresses, change addresses, etc. work.

No, it's not. The problem is a lack of easy-to-understand documentation (F1 Help) and lack of video tutorials that would explain:

a) the practicalities and idiosyncrasies of the system (e.g. you can revoke an unconfirmed transaction - how can a non-techie newbie know this if not by accident / luck?) and
b) would explain operation that can be performed with Bitcoin-Qt (change addresses, commands, etc.).

I will spend 1 or 2 weeks to get a basic understanding while searching this forum and asking silly questions (and driving moderators crazy) that had already been asked a thousand times, while I could very well gain the same or better knowledge (i) by watching two or three videos done by someone focused on teaching and not on himself and his excitement and (ii) by reading F1 Help in two hours.

This forum would have been 100 times smaller if there were 3 good videos on how to use Bitcoin-Qt.

I am not complaining though 

[Loozik]

What does it mean in practice / real life ''to export addresses as a means of sending coins''. I lack the jargon.

It means don't use "dumpprivkey". Ever. (I meant exporting privkeys, not exporting addresses)

Now we are getting to the heart of the matter. Many wiki articles and answers in the forum say what to do and what not to do, but rarely back these commandments with easy to understand logical / rational argumentation.

Why shouldn't I be using ''dumpprivkey''?

[wumpus]

Why shouldn't I be using ''dumpprivkey''?

Because after using it, the key will exist in two places 1) in the wallet 2) whereever you copy it.
Were someone else to import that key with "importprivkey" into another wallet, you'd have the "private key shared by two wallets" problem.
Apart from the you and the person you shared it with, as the key has been copied in plaintext, it could be intercepted by a third party, and it would be a race who spends the coins quickest.

[justusranvier]

I actually don't think Bitcoin-Qt should exist at all

I agree with your post, except that part. You make good points and further modularization, and bootstrapping as SPV client would be good things, and are in the planning. There is some work on a separate blockchain daemon, might make it to 0.10. But how do you get from there to "it shouldn't exist at all"? Are you trying to troll me?

Snotty replies such as yours really take away my motivation to work on this stuff at all. I went back to this forum after a long hiatus to help people, but this gets me annoyed really really fast.

I can see how that would be annoying if you truncate the original quote.

I actually don't think Bitcoin-Qt should exist at all, at least the way it is currently implemented as an all-in-one program. The reference client is built around a user case that doesn't match how people actually use computers.

If you wanted to paraphase that, it would be more accurate to truncate it this way:

"I actually don't think Bitcoin-Qt should exist as an all-in-one program."

And then there was this part:

If this separation was achieved and Bitcoin-Qt was just a GUI interface with no blockchain management or P2P functionality, then it would be just one of many alternatives that could perform the same task. I question whether or not it would still be needed at this point, but in any case it would be much easier to upgrade and improve since it could have a release schedule independent of the other two modular components.

If the reference client was split into a stack of applications at the boundaries that make sense, I think Bitcoin-Qt would be redundant, since it would not offer any features that aren't already being provided by other clients and especially since it doesn't offer any kind of offline wallet capability. That's just a guess though, and in my original post I did include a proposal (faster release schedule for bitcoin-qt compared to bitcoind and walletd) that could lead to me changing my mind.

[Loozik]

Why shouldn't I be using ''dumpprivkey''?

Because after using it, the key will exist in two places 1) in the wallet 2) whereever you copy it.
Were someone else to import that key with "importprivkey" into another wallet, you'd have the "private key shared by two wallets" problem.
Apart from the you and the person you shared it with, as the key has been copied in plaintext, it could be intercepted by a third party, and it would be a race who spends the coins quickest.

Thank you.

I noticed here https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list ''dumpprivkey'' command requires unlocked wallet. Should other / all commands requiring unlocked wallet like ''importprivkey'' or ''sendfrom'' be avoided to prevent data interception?

[wumpus]

I noticed here https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list ''dumpprivkey'' command requires unlocked wallet. Should other / all commands requiring unlocked wallet like ''importprivkey'' or ''sendfrom'' be avoided to prevent data interception?

Not necessarily. Even a simple send requires wallet unlocking.
The command is not so much dangerous because it unlocks the wallet, but because the private key leaves the wallet.

[charleshoskinson]

Snotty replies such as yours really take away my motivation to work on this stuff at all. I went back to this forum after a long hiatus to help people, but this gets me annoyed really really fast.

John, I value your work greatly, which is why I am featuring it as one of my lectures in my course. Every community has members who do not appreciate the contributions of others. Do not infer that this is the standard. We, as a whole, deep appreciate your participation and effort and need you to continue with both passion and vigor.