Get rid of using the change address "feature" as default in the official bitcoin clients #3371

issue fresheneesz opened this issue on December 8, 2013
  1. fresheneesz commented at 11:47 PM on December 8, 2013: none

    Using change addresses cause a lot of problems, and don't have much benefit. The problems:

    • High learning curve - newbies don't know where their money is going. When they make a payment, they see their entire address drained of money on the blockchain.
    • Backing up your bitcoins becomes almost impossible. This is really the biggest problem with using change addresses, and it is a HUGE problem. How do you back up your money if your addresses are drained every time you use them? If you want to back up an address, you can do that easily. Just encrypt your wallet and copy it to various devices (your phone, external HD, USB drive, paper wallet, etc). If change addresses are used tho, you must copy to all your backups (as painful as printing out a new paper wallet) every time you make a transactions. That is intractable.

    That intractability I think is a HUGE problem for bitcoins. People need a simple, understandable secure way of being "their own bank" and change addresses make bitcoins broken for most people.

    You can use seeded address generators, and back up the seed. But there are no standard algorithms for doing that. If you find your seed in 30 years, how will you know what algorithm to use to use the seed on? You'd have to back up the algorithm with your seed. That's really hard on paper.

    Its in the best interests of bitcoin and bitcoins users to have a simple way to back up their money. It doesn't make sense to make backing up bitcoins far more complicated just to gain a little bit of privacy, especially when the technique probably doesn't even work. Don't gear this currency toward power user - let power users use advanced features when they understand them.

  2. luke-jr commented at 11:51 PM on December 8, 2013: member

    Bitcoin becomes unusable without change addresses. Are you going to explain to people why they can only send bitcoin amounts totalling the exact size their coins are? Please keep in mind that reusing addresses is broken behaviour/misuse.

    HD wallets solve the backup issue without breaking the user experience.

  3. gmaxwell commented at 12:13 AM on December 9, 2013: contributor

    You can use seeded address generators, and back up the seed. But there are no standard algorithms for doing that.

    There absolutely is, BIP 32. https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki

    Considering this we will not be making the proposed change.

  4. gmaxwell closed this on Dec 9, 2013

  5. fresheneesz commented at 12:46 AM on December 9, 2013: none

    Wow. Way to completely misunderstand what I'm saying luke. I'm saying make the outputs of a transaction your receiver and the origin address by default. I.E. don't use new change addresses. Reusing addresses is not misuse - please justify that.

    gmaxwell, would you mind please reopening this issue? I don't mind my issue being closed once a consensus has been reached, but 30 minutes is not long enough for that to happen. Please indulge me with the knowledge that if my idea isn't reasonable it will be very clear within a week.

    Also, I think you misunderstood me when I said there is no "standard". You have clearly done excellent work in creating an algorithm for doing this, but that doesn't make it a standard. The fact that it is a proposal at the moment means it is definitely nowhere near a standard. The importance of a standard is that people will be able to easily find ways of restoring their wallets in the future. By contrast, an encryption standard like AES would be all that's needed to safely store a bitcoin private key, and by proxy a user's money if change addresses weren't used. Your BIP is nowhere near the level of standard that AES is.

    I would appreciate some justification for the use of change addresses here. Please don't just dismiss this issue without some discussion. I'd also appreciate links to this type of discussion if you're aware of where it has taken place before.

  6. gmaxwell commented at 1:04 AM on December 9, 2013: contributor

    This has been discussed previously, at length, and I suspect that people are exhausted about talking about it but I don't mind reopening for you. I closed it on the basis of the belief that you were unaware of BIP 32 and would have withdrawn your request after being informed of it.

    I think you're thoroughly confused wrt the "standard". BIP 32 is more clearly defined than Bitcoin itself as a standard, and more clearly defined than any other existing method of actually encoding Bitcoin key material, etc. AFAIK all widely used wallet programs plan on moving to it in their next or next few versions, also establishing it as the defacto standard. It has several complete independent software implementations.

    With the BIP process I'd been tending to model after the IETF process, so don't be confused by the language. Actual standards are just proposals until long enshrined by common practice— something that nothing in Bitcoin really is today.

  7. gmaxwell reopened this on Dec 9, 2013

  8. fresheneesz commented at 5:49 AM on December 9, 2013: none

    Thanks.

    I'd actually consider the Bitcoin protocol itself a well-established standard at this point, with hundreds of thousands of nodes and constrained by the strength of the current blockchain - no one can simply start using another algorithm because it wouldn't be bitcoins anymore.

    By contrast, these proposals have very little keeping them around. It may well be the case that HD wallets will have staying power for a few decades, but there's nothing to ensure that - especially when (it sounds like) no program has actually implemented it yet.

    Learning about the proposal though, it sounds pretty nice and solves most of the problems I've been worried about. I still think that bitcoin needs to have a well established way to keep coins safe in the long run without any monitoring. A person should be able to back up a wallet, throw it in a time capsule, and someone in 50 years should be able to open it up and use the wallet. To me, this means that whatever algorithm is used to generate the right private keys should be identifiable and findable 50 years later just by looking at the backup.

    I know for a fact that if you stored a plain bitcoin address private key and threw it in a time capsul that labeled it "bitcoin address" - someone in 50 years could open it and use it. Is this true for your proposal? It would feel really sucky for people if they back up their stuff, and 5 years from now open it up and can't figure out how generate the right addresses from it. I don't want bitcoin to erode away because its too easy for people to lose their coins.

    Would you mind pointing me to somewhere where the efficacy of change addresses has been discussed?

  9. gavinandresen commented at 7:24 AM on December 9, 2013: contributor

    Closing as a duplicate of #3250

  10. gavinandresen closed this on Dec 9, 2013

  11. laanwj commented at 7:24 AM on December 9, 2013: member

    With coin control (which is merged for 0.9.0) you'll be able to set your own change address, so you can avoid any issues with it.

    Apart from that -- at this point I'd recommend using another wallet program that does support BIP0032 deterministic wallets. The keypool system that is used now in the reference client is indeed dangerous as you aren't even notified when you have to make a new backup. Such notifications could be added to the GUI, and there is "keypoololdest" in RPC "getinfo", but for for all practical purposes deterministic wallets would be better.

    (I'm also working on a feature that lists the change addresses in "Used receiving addresses", this may help a bit too)

  12. fresheneesz commented at 10:03 PM on December 9, 2013: none

    @laanwj Being able to see what change address will be used (and modify it if you want and/or set default behavior) would definitely be very helpful. Thanks!

  13. Bushstar referenced this in commit 3c90da86b3 on Apr 8, 2020
  14. DrahtBot locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-22 18:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me