Address changes should be visible to the user

IndieRobert commented at 7:28 am on December 5, 2017: none

Hi,

I lost a significant amount of bitcoin because bitcoinqt made transactions I never gave permission to: address changes. I assumed this software was unix-like, that basically it was good software. But because of the address changes, which are not signalled to the user, it is not.

Issue:

Bitcoin private keys are artefacts of the bitcoin network. This is what the user own and is entitled too when he gets bitcoin. Bitcoin wallets are NOT artefacts of the network, they are not part of the network at all. From the point of view of the network, they are artefact of a 3rd party software. The user may use them, but he doesnt own bitcoin because he owns a wallet, the user owns bitcoins because he owns private keys.

Therefore, when bitcoinqt makes transaction - address changes - without warning the user, it is a clear breach of unix-like trust - for a lack of better terms.

Bitcoinqt should be unix-like. It should be fully transparent to the user, and not try to appeal to the mass. It should not be up to another software to fulfill that role.

Solution:

Just make the address changes visible.

Conclusion:

I can understand the mistake has been made at the beginning of bitcoin. Bitcoin was supposed to appeal to the mass in order to be used in mass consumption. It is still a mistake, but it is understandable. Today, we know it will never be used to buy a macdonald meal (beside the use of 3rd party software which make you think you do).

achow101 commented at 4:16 pm on December 5, 2017: member

Bitcoin Core (bitcoin-qt and bitcoind) will never make transactions that you do not give permission to. There is no “the address”; your wallet does not have one singular address that it uses. The wallet contains multiple addresses (thousands, in fact, and constantly generates more). When you make a transaction, there will usually be change, and the change will be sent to a change address. That change address is part of your wallet. It is not a new transaction, it is another output of the transaction that you were making.

There are no address changes; no addresses ever change or are removed from your wallet. Again, there is no “the address” in your wallet that changes. You can see all of the addresses that you use in your wallet by going to File > Receiving Addresses.

That the wallet uses new addresses for every time you need an address is well known and documented.

In what way did you lose coins?

IndieRobert commented at 7:38 pm on December 5, 2017: none

When you make a transaction, there will usually be change, and the change will be sent to a change address. That change address is part of your wallet. It is not a new transaction, it is another output of the transaction that you were making.

Oh I didnt know that. I was indeed very surprised that the software would make transactions without my consent. I understand now that it’s not a new transaction but the result of the initial transaction, it makes sense.

In what way did you lose coins?

Ive imported a private key, sent part of the bitcoins it contained and then deleted the wallet thinking that the change would be at the same address.

andrelam commented at 8:18 pm on December 5, 2017: none

If the private key you (still) have was for a HD (Hierarchical Deterministic) wallet, if you create a new wallet with the same private key it should give you access to the change address as well.

MarcoFalke commented at 8:20 pm on December 5, 2017: member

There are plenty of reasons not to “send back” the change to “the same address”. Just to mention a few:

Addresses shouldn’t be reused. Especially if they were generated from an imported private key, they should be considered compromised. I’d assume, it is expected that you’d want to sweep the funds if you import a private key.
Also note, that unlike your bank account, addresses don’t have a balance. And in the general case where a transaction uses multiple coins as inputs, it will be impossible to determine the address where the funds came from.
Finally, for privacy reasons, you shouldn’t reveal what is the change output. Instead, send the change to a fresh change address.

MarcoFalke added the label Questions and Help on Dec 5, 2017

MarcoFalke added the label Wallet on Dec 5, 2017

MarcoFalke added the label GUI on Dec 5, 2017

MarcoFalke removed the label Wallet on Dec 5, 2017

MarcoFalke commented at 8:59 pm on December 5, 2017: member

One solution could be to indicate that change is sent to a change address in the final transaction confirm dialog in the gui, assuming that @IndieRobert used the gui. Otherwise, maybe extending the documentation for importprivkey?

IndieRobert commented at 5:19 am on December 6, 2017: none

One solution could be to indicate that change is sent to a change address in the final transaction confirm dialog in the gui, assuming that @IndieRobert used the gui. Otherwise, maybe extending the documentation for importprivkey?

Please dont waste your time because of my ignorance :)

That being said, I think I’ve found that it is missing a unix-an doc that answers question like: “how do you own bitcoins?”. In that case, when I look at a wallet, it awfully looks like a 3rd-party software artefact, whereas private keys looks like the thing I should only worry about. I now understand that you own bitcoins by owning a wallet and thats because, actually, of those change addresses. Correct me if Im wrong but if you “remove” the change addresses, you “remove” the wallets. Im not suggesting you should actually remove change addresses which makes no sense, I understand now the tech works like this; all Im saying is that wallets are here because change address are here, the whole thing being rooted in the tech. That defines wallets (how many users, particularly the tech savvy ones, could tell what wallets are really for?). A unix-an want to learn that quickly, during his user experience. Also, I think it’s missing some unix-an hints of whats happening during bitcoin core execution: I would expect to literally see the change address mechanism for each transactions, importprivkey included. Right now, importprivkey output things on the console (a “null”) but doesnt output anything on the app. The app should log visibly everything that’s happening, I think. When you grep or curl or whatever, you get to see everything right? :)

Anyway, ultimately, Im sure those information are available somewhere, therefore the mistake is on me.

achow101 commented at 5:49 am on December 6, 2017: member

Correct me if Im wrong but if you “remove” the change addresses, you “remove” the wallets. Im not suggesting you should actually remove change addresses which makes no sense, I understand now the tech works like this; all Im saying is that wallets are here because change address are here, the whole thing being rooted in the tech. That defines wallets (how many users, particularly the tech savvy ones, could tell what wallets are really for?).

The wallet is not just change addresses, and there is more than one address in a wallet that you use to receive Bitcoin with. Most modern wallets (including Bitcoin Core) will generate a new address for every time you want to receive Bitcoin. It will also generate new change addresses whenever a change address is required. All a wallet is is a collection of private keys, and your Bitcoin can be associated with any of the private keys in a wallet. So once you import a private key into a wallet, that wallet as a whole contains your Bitcoin, not just the singular private key you imported.

A unix-an want to learn that quickly, during his user experience.

All of this information is documented on multiple websites. Bitcoin.org is a good resource for this type of stuff. There really is no need for any unix documentation, especially since the vast majority of users are not using any form of unix.

The app should log visibly everything that’s happening, I think. When you grep or curl or whatever, you get to see everything right? :)

Most of the things you are asking for are logged in the debug.log file. There is no need to print that out to the console as it is kind of useless and will add extra information that may confuse the user. It will especially make it more difficult to understand what is just logging output and what is the actual result of the command.

rromanchuk commented at 8:14 am on December 15, 2017: none

pre-hd wallets, this was indeed, a horrible design choice. A bitcoin user in 2012, who backed up their wallet after receiving a single transfer, is completely unprotected after making a single transaction after that backup. Fast forward 6 years of holding/forgetting, throw in a SSD failure, and that wallet.dat backup is now worthless. With electrum, at least a user with a strong foundation can understand that his unspents that make up his balance have nothing to do with his last receiving address. https://bitzuma.com/posts/five-ways-to-lose-money-with-bitcoin-change-addresses/

MarcoFalke added the label good first issue on Mar 22, 2018

jnewbery commented at 4:23 pm on April 2, 2018: member

@MarcoFalke - you’ve tagged this as a good first issue. What action do you think this issue is tracking which would be a good first issue for a new contributor?

MarcoFalke commented at 4:47 pm on April 2, 2018: member

Pretty much my comment in #11827 (comment)

One solution could be to indicate that change is sent to a change address in the final transaction confirm dialog in the gui, assuming that OP used the gui. Otherwise, maybe extending the documentation for importprivkey?

jnewbery commented at 5:11 pm on April 2, 2018: member

If you think it’s worth tracking, I suggest opening an issue to track just that. This issue has lots of historical baggage and should be closed.

laanwj removed the label good first issue on Dec 15, 2019

laanwj commented at 9:26 am on December 15, 2019: member

Agree with @jnewbery here @MarcoFalke Please open a clear issue that proposes the change, preferably use the “good first issue template”.

laanwj closed this on Dec 15, 2019

MarcoFalke locked this on Dec 16, 2021

Address changes should be visible to the user #11827