From: Mike Hearn <mike@plan99•net>
To: Tamas Blummer <tamas@bitsofproof•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] New BIP32 structure
Date: Thu, 27 Mar 2014 10:42:19 +0100 [thread overview]
Message-ID: <CANEZrP0t6E5tKk_jcApwa+o4-qBg9uyRnePGarZXeLDxcKS+Rg@mail.gmail.com> (raw)
In-Reply-To: <F2C8C044-EF92-4CCE-9235-28CA7FCE3526@bitsofproof.com>
[-- Attachment #1: Type: text/plain, Size: 4282 bytes --]
At this point I'm not sure how much further work people want to do on this:
I got the impression that Trezor will ship soon, and Thomas V seemed
satisfied too. I'm not sure we can get all wallets to be fully
interoperable given the flexibility inherent in BIP32 and people's
differing use cases.
Andreas: good point but I really hope nobody ever deletes a seed after all
this work we put in to make backups so easy! I'm not sure we can really
stop it anyway: not unless we make the seed a full blown data structure
with hints to other apps that they should refuse to load it. And it's a bit
late for that now.
On Thu, Mar 27, 2014 at 8:09 AM, Tamas Blummer <tamas@bitsofproof•com>wrote:
> We had a similar meeting with Andreas Schildbach (Android Bitcoin Wallet),
> Jan Moller, Andreas Petersson (Mycelium), Thomas V (Electrum), Tamas
> Blummer, Tamas Bartfai (Bits of Proof)
> at the Inside Bitcoin Conference in Berlin.
>
> I remember that there were different opinions on how to use a hierarchy
> and it did seem to me they could eventually be "standardized" for the
> retail customer but definitelly not for corporate use,
> where hierarchy will certainly map to organisational hierarchy or cost
> centres.
>
> A notable suggestion was to instead of building a directory of magic
> numbers (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word
> "Bitcoin", "Litecoin", "Dogecoin", so collosion is unlikely and
> cetral directory is not needed.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 26.03.2014, at 21:49, Mike Hearn <mike@plan99•net> wrote:
>
> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
> our BIP32 wallet structures would be compatible - and I discovered that
> only I was planning to use the default structure.
>
> Because I'm hopeful that we can get a lot of interoperability between
> wallets with regards to importing 12-words paper wallets, we brainstormed
> to find a structure acceptable to everyone and ended up with:
>
> /m/cointype/reserved'/account'/change/n
>
> The extra levels require some explanation:
>
> - cointype: This is zero for Bitcoin. This is here to support two
> things, one is supporting alt coins based off the same root seed. Right now
> nobody seemed very bothered about alt coins but sometimes feature requests
> do come in for this. Arguably there is no need and alt coins could just use
> the same keys as Bitcoin, but it may help avoid confusion if they don't.
>
> More usefully, cointype can distinguish between keys intended for
> things like multisig outputs, e.g. for watchdog services. This means if
> your wallet does not know about the extra protocol layers involved in this,
> it can still import the "raw" money and it will just ignore/not see the
> keys used in more complex transactions.
>
> - reserved is for "other stuff". I actually don't recall why we ended
> up with this. It may have been intended to split out multisig outputs etc
> from cointype. Marek, Thomas?
>
> - account is for keeping essentially wallets-within-a-wallet to avoid
> mixing of coins. If you want that.
>
> - change is 0 for receiving addresses, 1 for change addresses.
>
> - n is the actual key index
>
> For bitcoinj we're targeting a deliberately limited feature set for hdw v1
> so I would just set the first three values all to zero and that is a
> perfectly fine way to be compatible.
>
> The goal here is that the same seed can be written down once, and meet all
> the users needs, whilst still allowing some drift between what wallets
> support.
>
> Pieter made the I think valid point that you can't really encode how keys
> are meant to be used into just an HDW hierarchy and normally you'd need
> some metadata as well. However, I feel interop between wallets is more
> important than arriving at the most perfect possible arrangement, which
> feels a little like bikeshedding, so I'm happy to just go with the flow on
> this one.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
[-- Attachment #2: Type: text/html, Size: 7747 bytes --]
next prev parent reply other threads:[~2014-03-27 9:42 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 [this message]
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
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=CANEZrP0t6E5tKk_jcApwa+o4-qBg9uyRnePGarZXeLDxcKS+Rg@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=tamas@bitsofproof$(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