No need to implement full support for BIP0032, but key generation using the private derivation should be the default.
I'm sick and tired of worrying about backup up after enough keys have been used (and reading stories about people that lose their coins because of that), and the consensus seems to be against #2841 (noautofillkeypool), so let's do this.
If it's going to be in the mainline client, why not follow the same implementation of BIP0032 as Electrum or Armory? Interoperability between a very lightweight client (Electrum) and the heavy reference client would specifically be of a great advantage to users. There's both a python and a javascript implementation of Electrum's system with which to refer to when porting.
We already have the implementation (merged with #2829), we're just not using it yet.
BIP0032 is a standard, so in principle it should be inter-operable. HOWEVER it's very much discouraged to have the same keys in multiple wallets in different programs (bitcoin-qt copes with double spends very badly at the moment).
A short term measure would be to just insert a BIP32 master key into the wallet, and whenever one is there— unless disabled, use it to derive new keys to fill the keypool. We should also split the keypool into change and non-change.
Just curious: why is this high priority? @laanwj said bitcoin-qt copes with double spends very badly yet, so handle double spends better isn't more important than this? Thank you.
@felipelalli Because lack of deterministic wallets is causing a lot of suffering, due to people being lax with renewing backups. Lots and lots of sob stories.
On the other hand double spends are a solved issue in Bitcoin if you wait for confirmations. If you don't wait for confirmations, they are a risk you're taking. No amount of "coping" will save you from that.
Understood. Thank you for the explanation @laanwj .
Laanwj is right with regards to backup: Anyone who has worked at IT support will know that the absolute majority of people does not do any backup at all. Further, I would like to add the aspect of security: Most computers of average users are infected by malware, if not almost all. This has not yet become a huge threat for Bitcoin, but it will because by nature, Bitcoin is easy to steal. In fact Bitcoin might even become the primary target of the whole botnet market: Without Bitcoin, to earn money you needed to find someone shady to buy all the computing power which you were stealing with your malware - probably rather difficult to find someone who pays for something this illegal. Now you can monetize directly by stealing Bitcoins and using the machines for mining. Bitcoin is as promising for malware authors as it is for honorable use :( And deterministic wallets are the foundation for watch-only / paper wallets, so they will help security very much. Therefore, if I'm allowed to I would also vote for this being high priority.
Happy birthday!
Thanks. Priorities have changed since last year - the built-in wallet in Bitcoin Core is no longer important, so I'm removing the high priority tag.
Agree with "less important" Disagree with "no longer important"
There is active competition in the wallet arena, with several, more featureful wallets in the field. However, we do have existing users, and giving them HD wallets remains valuable... assuming that someone contributes the work to implement and test it.
Sure, I would be happy if someone were to contribute a HD wallet implementation!
That said, the purpose of Bitcoin Core is maintaining the consensus and infrastructure, and I think it is important to focus on that. Things have changed a lot since 2010. The market of wallets is very well catered to.
We 'owe' users only that the wallet keeps working, and in time that there is a realistic migration path to a split-off project.
the built-in wallet in Bitcoin Core is no longer important, so I'm removing the high priority tag.
I would like to disagree very much. Third-party wallets are nice for daily use of small change. But anyone who wants to go for secure long-term storage of coins will not decide to use a non-popular, third-party software. The official / first / most popular / primary implementation and because of its most users most tested software usually is usually the choice of people who want to go down the secure path.
And with Bitcoin, security is something which has much higher demand than with other software, so its even more important to have a nice primary implementation.
Bitcoin Core is /not/ a "primary implementation" of a wallet. It is the only implementation of Bitcoin consensus rules...especially as the wallet code is not being very actively maintained except for bug fixes (as indicated by this bug).
Bitcoin Core is /not/ a "primary implementation" of a wallet. It is the only implementation of Bitcoin consensus rules...especially as the wallet code is not being very actively maintained except for bug fixes (as indicated by this bug).
I was trying to discuss user behavior, so please try to look at this from a user's perspective. Users will not know what your internal considerations are. Users will know "it's called Bitcoin", that the official site is "bitcoin.org", and that "Bitcoin Core" is developed by bitcoin.org. Users will assume what the official site publishes is the most well-tested, stable software.
Or to explain it from a different point of view: I have over 3000 packages on my system. If I want the most rock-solid, stable experience, why on earth would I decide not to go for the most widespread, seeming-to-be-official version of each? It's impossible to randomly determine for 3000 packages whether a third party re-implementation is deemed to be more stable.
Please don't give up providing a trustworthy reference implementation. AFAIK, there isn't even a Bitcoin wallet with deterministic builds other than Bitcoin core yet. The only other thing which people say to be high security is Bitcoin Armory, and for over 1 year they failed to process my bug report about their source code compilation instructions providing completely broken GnuPG validation https://github.com/etotheipi/BitcoinArmory/issues/91 (the issue still applies: https://bitcoinarmory.com/building-from-source/)
You're still the best :)
I presume there's still no-one working on this? Looking at tackling this later in the year, if anyone is working on HD wallets in Core please let me know so we're not duplicating effort. I'm aware a fair chunk of the code is already in place.
Some weeks ago i pushed a PR for the current master that enables HD for the existing wallet: #6265
I'm also completely rewriting the wallet and soon also the UI level: https://github.com/jonasschnelli/bitcoin
Corewallet aims to be a counterweight against the current wallet movement towards "SPV" and "Web-Centralized" solutions. If we can download 6GB movies over iTunes and play CPU/GPU intensive 3D games we can also run a full node (pruned) on a standard computer. It's just a matter of user-friendliness (by throttling bandwidth and cpu usage).
At the moment it's experimental, thought, you can use it in parallel to the existing wallet. Main features:
@jonasschnelli Great - I'll take a more in depth look when I have time (soon, TM)
Probably solved by #8035.
Yes, thank you!