Re: [Bitcoin-development] New BIP32 structure

[Alan Reiner <etotheipi@gmail.com>]

[-- 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 --]