{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-24\n📝 Original message:Right. So part of this is my fault, I'm afraid, because I do not intend to\nimplement any kind of subwallet/account support in bitcoinj. My reasons are:\n\n   1. The bitcoinj API already lets you create and use multiple wallets.\n   What's more, because of the desire to do key rotation (think rotating a\n   previously unencrypted wallet to an encrypted one that is stored on SSD's\n   that cannot reliably erase data), a bitcoinj wallet can actually contain\n   multiple BIP32 seeds and hierarchies at once, although only the last one\n   will be used for vending addresses. So adding subwallet support onto this\n   makes it even more complicated.\n\n   2. If there was a much better user experience to be enabled by this, it\n   may be worth it, but I believe many people will find subwallets rather\n   confusing. They don't match the analogy of bank accounts in several ways.\n   For instance, transferring money across them leaks private data and costs\n   miners fees, neither of which are true with banks.\n\n   Also it differs in a more important way. People have different bank\n   accounts because those accounts implement different policies. Current\n   accounts may pay a lower interest rate than savings accounts, but have\n   different features, and accounts can be used as security boundaries i.e. no\n   card withdrawals from savings. But \"subwallets\" are not like this. The only\n   justification for their existence is to avoid outputs being merged together\n   to make payments - a subtle technical detail of the protocol that users are\n   ill equipped to understand. If someone asked me \"why should I create a\n   second account\" I would be unable to give them a satisfying answer without\n   first teaching them about how the Bitcoin protocol works and the privacy\n   implications of that, which is practically a lecture sized topic.\n\n   3. MultiBit did support multiple wallets for a long time (just by\n   creating multiple wallet files and using the support in bitcoinj for\n   running them in parallel), but they decided to remove this feature in\n   MultiBit HD because it caused support headaches. People would stash money\n   in one wallet or the other, close the wallet and then forget and think they\n   had lost it, etc. It may be that TREZOR type subwallets don't suffer this\n   confusion because they can't be moved around or \"closed\" in the same way a\n   file can be, but still, this is a data point against multiple simultaneous\n   wallets. At least for products targeting entry level consumers.\n\nWhilst I can well believe there are TREZOR users who are asking for this\nfeature today, currently the costs feel a bit higher than the benefits.\n\nIt would be rather nice to be able to type in a mnemonic code that myTREZOR\nwas initialised with and duplicate that wallet into a bitcoinj based wallet\napp. But if I have to implement subwallets and expose this in the API, and\nif all wallet authors that want to be able to share a wallet with myTREZOR\nhave to expose subwallets in their GUIs too, even though the concept may\nprove confusing and hard to explain, then it might be more tempting to just\ntell users that want to switch wallet apps to send the money via the block\nchain instead.\n\n\n\n\nOn Thu, Apr 24, 2014 at 9:10 AM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003ewrote:\n\n\u003e On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin \u003cthomasv1 at gmx.de\u003e wrote:\n\u003e \u003e\u003e Why do clients need to use the features in BIP 64? If Electrum doesn't\n\u003e want to\n\u003e \u003e\u003e use accounts, [...]\n\u003e \u003e\n\u003e \u003e To clarify:\n\u003e \u003e Electrum plans to have bip32 accounts; Multibit will not, afaik.\n\u003e\n\u003e To clarify:\n\u003e BIP64 has a much stricter definition for accounts than BIP32.\n\u003e\n\u003e In BIP32, it is not well specified what accounts are used for. They\n\u003e can be used for \"subwallets\", \"receive accounts\" (as in bitcoind's\n\u003e account feature), \"recurring payments\", part of a chain used as\n\u003e multisig addresses, ... determined individually for each index.\n\u003e\n\u003e In BIP64, they are strictly used for subwallets, and can't be used by\n\u003e anything else.\n\u003e\n\u003e --\n\u003e Pieter\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Start Your Social Network Today - Download eXo Platform\n\u003e Build your Enterprise Intranet with eXo Platform Software\n\u003e Java Based Open Source Intranet - Social, Extensible, Cloud Ready\n\u003e Get Started Now And Turn Your Intranet Into A Collaboration Platform\n\u003e http://p.sf.net/sfu/ExoPlatform\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140424/095c0435/attachment.html\u003e"}