Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WSysl-0006a6-H3 for bitcoin-development@lists.sourceforge.net; Thu, 27 Mar 2014 01:13:23 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.172 as permitted sender) client-ip=209.85.160.172; envelope-from=allen.piscitello@gmail.com; helo=mail-yk0-f172.google.com; Received: from mail-yk0-f172.google.com ([209.85.160.172]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WSysk-0006Dn-Bd for bitcoin-development@lists.sourceforge.net; Thu, 27 Mar 2014 01:13:23 +0000 Received: by mail-yk0-f172.google.com with SMTP id 200so1619315ykr.31 for ; Wed, 26 Mar 2014 18:13:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.54.198 with SMTP id i46mr54302213yhc.13.1395882796860; Wed, 26 Mar 2014 18:13:16 -0700 (PDT) Received: by 10.170.88.10 with HTTP; Wed, 26 Mar 2014 18:13:16 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Mar 2014 20:13:16 -0500 Message-ID: From: Allen Piscitello To: Mike Hearn Content-Type: multipart/alternative; boundary=bcaec50b4aae414aeb04f58c4a55 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (allen.piscitello[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WSysk-0006Dn-Bd Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] New BIP32 structure X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 01:13:23 -0000 --bcaec50b4aae414aeb04f58c4a55 Content-Type: text/plain; charset=ISO-8859-1 For every branch (say multiple accounts), how would a new wallet be able to know how many sequence items to scan? It seems like not only do you need to have standard rules for the hierarchy, but how the usage can be detected. The other scanning seems pretty straightforward. For accounts, it seems like you could have a situation where you want to initially set up 10 different accounts, but only account #10 gets any transactions. If a new wallet was trying to scan with this seed, it would have to know to keep scanning each account until it found the account. The user would have to be responsible for knowing how many accounts there are, or some rules would need to be in place to not allow creating accounts until earlier accounts can be proven to have existed in the blockchain. Or I am missing something. -Allen On Wed, Mar 26, 2014 at 3:49 PM, Mike Hearn 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 > > --bcaec50b4aae414aeb04f58c4a55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For every branch (say multiple = accounts), how would a new wallet be able to know how many sequence items t= o scan? =A0It seems like not only do you need to have standard rules for th= e hierarchy, but how the usage can be detected. =A0The other scanning seems= pretty straightforward. =A0For accounts, it seems like you could have a si= tuation where you want to initially set up 10 different accounts, but only = account #10 gets any transactions. =A0If a new wallet was trying to scan wi= th this seed, it would have to know to keep scanning each account until it = found the account. =A0The user would have to be responsible for knowing how= many accounts there are, or some rules would need to be in place to not al= low creating accounts until earlier accounts can be proven to have existed = in the blockchain. =A0Or I am missing something.

-Allen

On Wed, Mar 26, = 2014 at 3:49 PM, Mike Hearn <mike@plan99.net> wrote:
Myself, Thomas V (Electrum)= and Marek (Trezor) got together to make sure our BIP32 wallet structures w= ould be compatible - and I discovered that only I was planning to use the d= efault structure.

Because I'm hopeful that we can get a lot of interoperability betw= een wallets with regards to importing 12-words paper wallets, we brainstorm= ed to find a structure acceptable to everyone and ended up with:

= =A0 /m/cointype/reserved'/account'/change/n

The extra levels require some explanation:
  • cointype: =A0This 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 somet= imes feature requests do come in for this. Arguably there is no need and al= t coins could just use the same keys as Bitcoin, but it may help avoid conf= usion if they don't.

    More usefully, cointype can distinguish between keys intended for thing= s like multisig outputs, e.g. for watchdog services. This means if your wal= let 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. I= t may have been intended to split out multisig outputs etc from cointype. M= arek, Thomas?

  • account is for keeping= essentially wallets-within-a-wallet to avoid mixing of coins. If you want = that.

  • change is 0 f= or receiving addresses, 1 for change addresses.

  • n is the actual key in= dex
For bitcoinj we&#= 39;re targeting a deliberately limited feature set for hdw v1 so I would ju= st 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 b= etween what wallets support.

Pieter made the I think valid point that you can't re= ally encode how keys are meant to be used into just an HDW hierarchy and no= rmally you'd need some metadata as well. However, I feel interop betwee= n wallets is more important than arriving at the most perfect possible arra= ngement, which feels a little like bikeshedding, so I'm happy to just g= o with the flow on this one.


-----------------------------------------------------------------------= -------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--bcaec50b4aae414aeb04f58c4a55--