Bitcoin Forum

TLDR: Bitcoin-QT needs to make addresses and their uses clearer if it wants to be widely adopted.

How many panic posts do we get on here with a person confused with addresses thinking "they've been hacked!!!!111!!"? Quite a lot. Bitcoin-QT's "keypool" was not a good idea, and it should either be disabled by default, removed, or given a way to be managed easily, as this leads to the question: "I thought 1whiskrpGeZVd5ormX2ihifc9uB2YSz82 was my bitcoin address, but I sent BTC to it and it's gone! Why?" Bitcoin-QT does not let me see (if I wanted to) ALL my bitcoin addresses (+ keys) plus every other address I ever received BTC to or sent BTC from. More control is needed, and this leaves me firmly in the hands of Electrum and blockchain info (plus every other easy-to-manage wallet out there.)

[/rant]

Bitcoin-qt requires you to download the blockchain.

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

To be concrete: what are you trying to do?

How do you get from "I cannot list all addresses" to "I've been hacked!!!"?

Unless keys disappear from your wallet, which is impossible with the Satoshi client as it doesn't support deleting private keys, none of the things you mention should result in losing coins.

Anyway, if the address stuff confuses you, there is good news: The eventual goal is to abstract addresses (which are indeed a confusing concept, in retrospect "one-time paying codes" would have been better) away completely through the payment protocol, so you can pay to persons/merchants instead of random codes.

Showing addresses (both receiving and sending) encourages re-use, which is bad enough, and showing 100's of them isn't going to make it any better, I'm afraid it's only going to make people more confused (why do I have so many addresses?).

Well keypool is a great idea, otherwise the first time you send a tx any backup would become obsolete.  Without a keypool (or deterministic wallet) to avoid fund loss would require continually backing up after every single transaction.

The issue isn't the keypool, the "issue" is that the QT wallet shows users some of their addresses and then (for their own good?) hides some of them.  A user seeing they have 100 addresses and seeing their coins sent to one of their 100 addresses is going to be less confused then a user seing they only have 10 addresses (because the QT wallet "helps" by hiding the other 100) and then seeing their funds go to an address "not" in their wallet.

Abstracting information from users is a good design choice.  Even if the unused keys in the keypool are hidden ONCE AN ADDRESS HAS FUNDS it shouldn't be hidden from the user.

i.e. user sends 1 BTC using 10 BTC output, 9 BTC is sent to unused keypool address 123.  As soon as the tx is created address 123 should be added to the list of addresses.  If the developers wants to it could have the word "change" next to it with a "?" for more info.  Hiding addresses which have been sent funds is just a recipe for fund loss.

Sounds like a good idea, maybe with a checkbox "show change addresses", or a separate debug window that can show it all to nosy users.
I've already proposed that before, but never got around to making it.
If someone is bored and feels like implementing it, be my guest :)

Bitcoin-qt is for services, not for users.

Can anyone tell me if I get this right? What if I have a bunch of offline cold wallets. If I were to spend all the coins one of these wallets, don't I just put the corresponding wallet.dat file in the right directly and let BitcoinQT do its thing (with -rescan)? Or do I have to do something else to make sure I don't lose the coins?

I too have a few questions. I am a non-techie newbie. I will appreciate answering.

A. CASE #1

1. At the moment I can see 2 addresses in my Bitcoin-Qt. Let's assume the balance in my Bitcoin-Qt is BTC 10.

2. When I send BTC 1 to a friend of mine, the remaining  BTC 9 is sent to another address of mine (the one I can't see within a pool of about 100 addresses sitting hidden in wallet.dat) - am I correct?

3. Is blockchain.info the only place I can check to which address BTC 9 were sent? What if blockchain.info is down? Is there a way to check from within Bitcoin-Qt to which address BTC 9 were sent?

--------------------------------------------------------------------------------------

B. CASE #2

1. I am given a present, a print-out from bitaddress.org - an address with BTC 5 in it and a private key to this address.

2. The moment I import the private key from the print-out in my Bitcoin-Qt:
a) BTC 5 is added to the balance in my Bitcoin-Qt, and also
b) the address from the print-out is added to a pool of addresses in my wallet and no-one else can use this address but me - I am correct?

--------------------------------------------------------------------------------------

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?

Thank you.

I'm making a lecture tonight on bitcoin-QT and I'd love to include a structured criticism section in the lecture. What would you guys say are the five biggest weaknesses of bitcoin-QT:

https://www.udemy.com/bitcoin-or-how-i-learned-to-stop-worrying-and-love-crypto/

There are no weakness, there are inconveniences but weakness would suggest it can be hacked and it really can't be hack.

This reminds me of a quote from one of the devs of internet explorer saying that if IE 6 is used properly it is almost unhackable. There is a world of difference between proper use and actual use. I'm discussing weaknesses in terms of useability or encouraging potentially unsafe behavior.

The key pool purge after encryption is an example on a weakness in my opinion for those backing up their wallet. 

That is an inconvenience, not a weakness. This is why newbies shouldn't be making classes, now your going to spread false information to people who will think your an expert. Thank you for spreading misinformation.

Gweedo my goal is to help people understand how Bitcoin works. Maybe one day, i'll be as knowledgeable and wonderful as you, but until then I'm simply going to continue working hard and answering as many questions as I can. You may have also noticed that I have reached out to many experts within the community including Wladimir J. van der Laan to help me edit and refine my content.

In all the software projects I've worked on, weaknesses are not just considered security flaws. If I build a system that requires my users to do something cumbersome to be safe, then most users will not do it. I am truly sorry such a concept is lost to you. I am also sorry that I have offended you in some way by building a free course with members of this community.

No I was very happy you changed it from that greedy $9 to free, and even gave it to some friends. But now your just saying the software has weaknesses it clearly doesn't have a weakness, if it did I be the first one on a soapbox screaming about it. Weakness in software development means that it can be hacked. This is an inconvenience that is necessary so a hacker couldn't take advantage. So I think you need more refinement and more information before making insane comments, that discredit you and your course.

Also your failing at your goal as in to help people if your going start saying misinformation.

Also I am sorry but since I work for my self and I been working with bitcoin for the last 2 years, I doubt you be as knowledgable as me, but you can try. I am probably more than 3/4 to the 15,000 hours to be an expert on bitcoin.

You know you're right. How about I explain the formal definition as described by CWE -[http://cwe.mitre.org/] for a mainstream course designed for average everyday people. Let's spend hours using highly technical language and very precise definitions so everyone can be an armchair software engineer by the end of the course. Yes you are correct about your use of weakness. I fundamentally disagree with weaknesses being used in this sense and some members of the software development community agree with a broader notion. If I engineer my UI in a way that encourages the user to do something that could result in a hacker exploiting the software, then it is a weakness. It is not in a technical sense you are correct. But the end result is the same, the user gets screwed. Look at windows vista and UAC. Go ahead and google it. This is a the very first result: http://www.petri.co.il/disable_uac_in_windows_vista.htm. UAC was meant to correct issues windows xp had and it was so poorly designed that users turned it off. All that code was wasted.

I will not use the term nor did I intend to do so in a technical sense here. I was merely trying to collect people's frustrations with bitcoin-qt so I could make sure new users don't experience the same problems you had. Get off your damn high horse and stop being an ass. I'm trying to help this community.

Why are you (as a newbie) concerned what address the coins are on? I'm sorry to say this, and I'm willing to explain how it works, but to normal users the wallet should be an opaque abstraction. Usually when people want to work with individual addresses, they're doing something dangerous or wrong.
You can be assured that the change will go to a private key under your control, otherwise you would no longer see it in your balance.

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

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

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

I don't know this. TBH, 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.

Warning users against some bad practices with Bitcoin-qt is good. For example, please warn them that messing around with importing/exporting private keys is dangerous (see above) and a recipe for coin loss or theft.

It's also perfectly fine to recommend another client to newbies, as long as you also warn of their respective risks (for example, theft with online wallets) as well.

John could you help answer this question on stackexchange?

http://bitcoin.stackexchange.com/questions/10117/are-change-addresses-visible-from-the-gui-in-the-bitcoin-qt-client/10140?noredirect=1#comment13366_10140

Sipa is correct there.

This is the weird part

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.

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.

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

That indeed sounds weird.

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

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.

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

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.

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.

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.

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.

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.

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.


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?


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


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


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

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.

OK, then it's fine. Questions are good, certainly better than rants :)
Yes. Exactly.
Because of the reasons I mentioned, such as inadvertent private key sharing. Use transactions to send coins to people.
It means don't use "dumpprivkey". Ever. (I meant exporting privkeys, not exporting addresses)
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.

Thank you.

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

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''?

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.

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

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

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?

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.

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.

Wow, did not expect this level of discourse :)
Personally, I use blockchain.info not Electrum - I was implying "anything but Bitcoin-QT".
We even got the dev in here ;D
Just please add an option to see ALL addresses in my wallet.dat file.

Thanks for this thread. I thought I'd lost about 6 btc based on the difference between what the blockchain says my address has and what bitcoin-qt says. I'm now *kinda* thinking everything is OK, but will investigate getting the keys out of my wallet just to be sure (I'll think I'll do it offline, too :) )

I would appreciate if developers add a new command that sends bitcoins from exact address to another two addresses (payee's and own address to get change back ). Like this:


I really miss this command because every time I want to send private transaction I have to do stupid manipulations extracting the address and adding it to a new wallet.