public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Alan Reiner <etotheipi@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] New BIP32 structure
Date: Wed, 26 Mar 2014 21:01:40 -0400	[thread overview]
Message-ID: <53337874.7010300@gmail.com> (raw)
In-Reply-To: <lgvobr$q44$1@ger.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 4868 bytes --]

This might be tangential, but the comment about "refund" chains reminded
me.  Armory will be implementing multi-sig/linked wallets where a each
device has a parallel HDW branch and produces P2SH addresses.  For those
types of wallets, I plan to allocate two chains /per signing
authority/.  If you have a shared 2-of-2 wallet split between your phone
and your spouse's phone, your phone would distribute addresses on P2SH
chain 0 and generate change addresses on P2SH chain 1.  Your spouse's
phone would use chains 2 and 3.

So if you and your spouse switch to a new app that supports M-of-N
linked wallets, it should search for coin history along the first 2*N
chains.
-Alan



On 03/26/2014 07:37 PM, Andreas Schildbach wrote:
> Thanks for starting the discussion on finding a better structure.
>
> For me, the most important thing is either we're 100% interoperable or
> 0%. There should not be anything inbetween, as users will delete seeds
> without knowing there is still money in them on another implementation.
> I heard from multiple sources that using this standard some wallets will
> only see a subset of the addresses/keys of some other wallets.
> Implementation differences can always happen (and should addresses as
> bugs), but I think its unacceptable that this source of issues is by design.
>
> I suggest we agree on an even simpler least common denominator and
> wallets that want to implement some feature on top of that can do but
> are encouraged to pick a totally different "cointype". I guess that
> would mean removing reserved and account.
>
> I'm still thinking it might be a good idea to have a separate chain for
> "refunds". Refunds will be rarely used and thus need a much slower
> moving window than receiving addresses or change.
>
>
> On 03/26/2014 09: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
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[-- Attachment #2: Type: text/html, Size: 5632 bytes --]

  reply	other threads:[~2014-03-27  1:01 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-26 20:49 [Bitcoin-development] New BIP32 structure Mike Hearn
2014-03-26 23:37 ` Andreas Schildbach
2014-03-27  1:01   ` Alan Reiner [this message]
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
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=53337874.7010300@gmail.com \
    --to=etotheipi@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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