From: Mike Hearn <mike@plan99•net>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] New BIP32 structure
Date: Thu, 24 Apr 2014 10:09:26 +0200 [thread overview]
Message-ID: <CANEZrP19rdDmsCM17-GADyWajxXy8_AeBY-6et0nzG_EMXe2jg@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBj68d5ZBDZ4uWvQYHMeq=bwTCaMNbwxfWGVL5MPh=7g2g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4585 bytes --]
Right. So part of this is my fault, I'm afraid, because I do not intend to
implement any kind of subwallet/account support in bitcoinj. My reasons are:
1. The bitcoinj API already lets you create and use multiple wallets.
What's more, because of the desire to do key rotation (think rotating a
previously unencrypted wallet to an encrypted one that is stored on SSD's
that cannot reliably erase data), a bitcoinj wallet can actually contain
multiple BIP32 seeds and hierarchies at once, although only the last one
will be used for vending addresses. So adding subwallet support onto this
makes it even more complicated.
2. If there was a much better user experience to be enabled by this, it
may be worth it, but I believe many people will find subwallets rather
confusing. They don't match the analogy of bank accounts in several ways.
For instance, transferring money across them leaks private data and costs
miners fees, neither of which are true with banks.
Also it differs in a more important way. People have different bank
accounts because those accounts implement different policies. Current
accounts may pay a lower interest rate than savings accounts, but have
different features, and accounts can be used as security boundaries i.e. no
card withdrawals from savings. But "subwallets" are not like this. The only
justification for their existence is to avoid outputs being merged together
to make payments - a subtle technical detail of the protocol that users are
ill equipped to understand. If someone asked me "why should I create a
second account" I would be unable to give them a satisfying answer without
first teaching them about how the Bitcoin protocol works and the privacy
implications of that, which is practically a lecture sized topic.
3. MultiBit did support multiple wallets for a long time (just by
creating multiple wallet files and using the support in bitcoinj for
running them in parallel), but they decided to remove this feature in
MultiBit HD because it caused support headaches. People would stash money
in one wallet or the other, close the wallet and then forget and think they
had lost it, etc. It may be that TREZOR type subwallets don't suffer this
confusion because they can't be moved around or "closed" in the same way a
file can be, but still, this is a data point against multiple simultaneous
wallets. At least for products targeting entry level consumers.
Whilst I can well believe there are TREZOR users who are asking for this
feature today, currently the costs feel a bit higher than the benefits.
It would be rather nice to be able to type in a mnemonic code that myTREZOR
was initialised with and duplicate that wallet into a bitcoinj based wallet
app. But if I have to implement subwallets and expose this in the API, and
if all wallet authors that want to be able to share a wallet with myTREZOR
have to expose subwallets in their GUIs too, even though the concept may
prove confusing and hard to explain, then it might be more tempting to just
tell users that want to switch wallet apps to send the money via the block
chain instead.
On Thu, Apr 24, 2014 at 9:10 AM, Pieter Wuille <pieter.wuille@gmail•com>wrote:
> On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin <thomasv1@gmx•de> wrote:
> >> Why do clients need to use the features in BIP 64? If Electrum doesn't
> want to
> >> use accounts, [...]
> >
> > To clarify:
> > Electrum plans to have bip32 accounts; Multibit will not, afaik.
>
> To clarify:
> BIP64 has a much stricter definition for accounts than BIP32.
>
> In BIP32, it is not well specified what accounts are used for. They
> can be used for "subwallets", "receive accounts" (as in bitcoind's
> account feature), "recurring payments", part of a chain used as
> multisig addresses, ... determined individually for each index.
>
> In BIP64, they are strictly used for subwallets, and can't be used by
> anything else.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 5519 bytes --]
next prev parent reply other threads:[~2014-04-24 8:09 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-26 20:49 Mike Hearn
2014-03-26 23:37 ` Andreas Schildbach
2014-03-27 1:01 ` Alan Reiner
2014-03-27 6:15 ` Mike Belshe
2014-03-27 10:57 ` Thomas Voegtlin
2014-03-27 11:39 ` Mike Hearn
2014-03-27 13:30 ` Thomas Voegtlin
2014-03-27 13:38 ` Mike Hearn
2014-03-27 1:13 ` Allen Piscitello
2014-03-27 5:34 ` Troy Benjegerdes
2014-03-27 7:09 ` Tamas Blummer
2014-03-27 9:42 ` Mike Hearn
2014-03-27 11:35 ` Pavol Rusnak
2014-03-27 15:43 ` Jeff Garzik
2014-03-27 15:57 ` Allen Piscitello
2014-03-27 16:06 ` Pavol Rusnak
2014-03-27 16:13 ` Allen Piscitello
2014-03-27 16:07 ` Tamas Blummer
2014-03-27 16:14 ` Pieter Wuille
2014-03-27 16:21 ` Pavol Rusnak
2014-03-27 16:28 ` Pieter Wuille
2014-03-27 17:49 ` Allen Piscitello
2014-03-28 14:59 ` slush
2014-04-08 12:43 ` slush
2014-04-08 13:18 ` Pieter Wuille
2014-04-08 13:40 ` slush
2014-04-08 13:43 ` slush
2014-04-08 13:53 ` Pieter Wuille
2014-04-08 13:59 ` Thomas Voegtlin
2014-04-08 14:00 ` Tamas Blummer
2014-04-08 14:35 ` Pavol Rusnak
2014-04-08 15:41 ` slush
2014-04-23 17:42 ` Pieter Wuille
2014-04-23 18:01 ` slush
2014-04-23 18:18 ` slush
2014-04-23 18:39 ` Tier Nolan
2014-04-23 18:46 ` Pavol Rusnak
2014-04-23 19:00 ` Tier Nolan
2014-04-23 19:06 ` slush
2014-04-23 19:36 ` Tamas Blummer
2014-04-23 19:46 ` slush
2014-04-23 19:07 ` Tamas Blummer
2014-04-23 19:29 ` Pavol Rusnak
2014-04-23 19:44 ` Luke-Jr
2014-04-23 19:49 ` Pavol Rusnak
2014-04-23 19:55 ` Luke-Jr
2014-04-23 19:57 ` slush
2014-04-23 20:01 ` Luke-Jr
2014-04-23 20:04 ` Pavol Rusnak
2014-04-23 20:09 ` Luke-Jr
2014-04-23 20:16 ` Pavol Rusnak
2014-04-23 20:32 ` Luke-Jr
2014-04-23 20:35 ` Pavol Rusnak
2014-04-23 20:41 ` Luke-Jr
2014-04-23 20:43 ` Pavol Rusnak
2014-04-23 20:54 ` Pieter Wuille
2014-04-23 21:06 ` Pavol Rusnak
2014-04-23 21:18 ` Luke-Jr
2014-04-23 21:22 ` Gregory Maxwell
2014-04-23 21:33 ` Pavol Rusnak
2014-04-23 21:42 ` Pieter Wuille
2014-04-23 21:44 ` Pavol Rusnak
2014-04-23 21:48 ` Gregory Maxwell
2014-04-23 21:53 ` Luke-Jr
2014-04-23 21:24 ` Pavol Rusnak
2014-04-23 21:07 ` slush
2014-04-23 20:59 ` Luke-Jr
2014-04-23 20:17 ` Tamas Blummer
2014-04-23 20:12 ` Pieter Wuille
2014-04-23 20:08 ` Pieter Wuille
2014-04-23 20:01 ` Tamas Blummer
2014-04-23 20:02 ` Luke-Jr
2014-04-23 20:04 ` Tamas Blummer
2014-04-24 6:54 ` Thomas Voegtlin
2014-04-24 7:10 ` Pieter Wuille
2014-04-24 7:21 ` Gregory Maxwell
2014-04-24 8:15 ` Thomas Voegtlin
2014-04-24 7:42 ` Thomas Voegtlin
2014-04-24 8:09 ` Mike Hearn [this message]
2014-04-23 18:48 ` Tamas Blummer
2014-04-08 14:49 ` Andreas Schildbach
2014-04-08 15:46 ` slush
2014-04-08 15:58 ` Andreas Schildbach
2014-04-08 16:24 ` slush
2014-03-27 11:20 ` Thomas Voegtlin
[not found] ` <CAJna-HhmFya+3W67qQt0wMhW=B4vJvwdkr-5WnU+KEaKq7uaUA@mail.gmail.com>
2014-03-27 12:06 ` Thomas Voegtlin
2014-03-27 12:28 ` Mike Hearn
2014-03-27 12:49 ` Mike Hearn
2014-03-27 13:12 ` Thomas Kerin
2014-03-27 13:19 ` Mike Hearn
2014-03-27 13:49 ` Thomas Voegtlin
2014-03-27 13:58 ` Jim
2014-03-27 14:20 ` Mike Hearn
2014-03-27 15:17 ` Troy Benjegerdes
2014-03-27 13:07 ` Matias Alejo Garcia
2014-03-27 13:44 ` Pavol Rusnak
2014-03-27 13:53 ` Thomas Voegtlin
2014-03-27 14:03 ` Pavol Rusnak
[not found] ` <CAJna-HitjJbL9TnfxTY=+TvfaeNvZM6aPWmNYmHUCwmw6V8PUg@mail.gmail.com>
2014-03-27 15:04 ` Thomas Voegtlin
2014-03-27 11:36 ` Pavol Rusnak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANEZrP19rdDmsCM17-GADyWajxXy8_AeBY-6et0nzG_EMXe2jg@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox