From: Alan Reiner <etotheipi@gmail•com>
To: William Swanson <swansontec@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets
Date: Thu, 09 Apr 2015 22:26:19 -0400 [thread overview]
Message-ID: <552734CB.4070903@gmail.com> (raw)
In-Reply-To: <CABjHNoQUMzUB+Q-dk+C=AzwXkVUC1fJOtVAB4TpXWhg2ONJdBg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3619 bytes --]
The motivation was that I came up with it before BIP 45 existed, but
wasn't vocal enough about it because Armory didn't have BIP32 Multisig
trees implemented yet, so I didn't have a strong mental focus or
determination around it. If there's momentum behind BIP45, we should
use it. I wanted to share the document because it was also created to
be educational on the topic of "multisig address generation collisions"
as being disucussed in this thread.
Though we just put in BIP44 with my modification into our new wallet
format (in the works), and if I was to adopt this I'd like to simply
merge the two.
M / purpose' / coin' / account' / *cosigner* / change*0or1* / address
For reference my proposal (and the way I implemented it before BIP45
existed) is just BIP44 but with 2*N change branches instead of 2:
M / purpose' / coin' / account' / change*2N* / address
Our new code has the goal of being able to easily reconfigure your BIP32
tree for your specific application. But for the default
free-public-download software, it would be nice to have a standard
everyone agrees to. BIP44 vs original-BIP32 doesn't really matter since
you only transfer the account branches, but this particular decision
with how the consigners avoid "collisions" does affect it.
-Alan
On 04/09/2015 10:02 PM, William Swanson wrote:
> Hello Alan,
> Your scheme is basically the same as the BIP45 scheme, except that you
> have collapsed the "cosigner_index" and "change" fields into a single
> field with the formula:
>
> combined = 2*cosigner_index + change
>
> This removes one level from the hierarchy, but ultimately produces the
> same number and type of chains as BIP45 (just addressed differently).
>
> I kinda like the BIP45's approach of giving each field has its own
> dedicated purpose. What is the motivation behind flattening the
> hierarchy?
>
> I ask because the wallet I work on, Airbitz, will be adding multi-sig
> at some point in the future, and we need to figure out what kind of HD
> tree structure we will be using. Our ideal structure would basically
> be BIP 44 plus some "no-collision" logic:
>
> m / purpose' / coin_type' / wallet' / cosigner_index / change /
> address_index
>
> I feel like interoperability with Copay would be worth the extra HD
> branch. Assuming Kefkius adds similar no-collision logic, his proposal
> is pretty close to our ideal:
>
> m / purpose' / wallet' / coin_type / cosigner_index / change / address_index
>
> Of course, I am open to hearing your thoughts on this as well.
>
> -William
>
> On Thu, Apr 9, 2015 at 3:37 PM, Alan Reiner <etotheipi@gmail•com> wrote:
>> BTW, I had originally proposed a "no-collision" scheme for
>> multi-signature wallets, which doesn't require modifying the key tree
>> structure at all, except for adding new internal and external chains
>> (2*N chains). All siblings watch all chains, but only generate
>> receiving and change addresses on their two chains.
>>
>> The original document is here, which might be educational for the
>> purposes of understand precisely the problem that needs a solution (and
>> mine is a different solution than BIP45).
>>
>> https://www.dropbox.com/s/58poxi60d8nfj5w/MultisigWalletNoCollide.pdf
>>
>> I prefer not adding even more levels to the key tree, and (IMO) it makes
>> more sense to add more chains to the wallet instead of adding a new tree
>> level (as it allows for a simpler tree in the event that you don't need
>> separate cosigners). But I suspect that there's a certain momentum
>> behind the cosigner-index method already in BIP45? Just throwing it out
>> there.
[-- Attachment #2: Type: text/html, Size: 4375 bytes --]
next prev parent reply other threads:[~2015-04-10 2:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-08 7:05 Kefkius
2015-04-08 7:46 ` William Swanson
2015-04-08 16:28 ` 木ノ下じょな
2015-04-08 16:41 ` William Swanson
2015-04-09 20:16 ` Kefkius
2015-04-09 22:24 ` William Swanson
2015-04-09 22:37 ` Alan Reiner
2015-04-10 2:02 ` William Swanson
2015-04-10 2:26 ` Alan Reiner [this message]
2015-04-16 13:11 ` Vertoe Qhor
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=552734CB.4070903@gmail.com \
--to=etotheipi@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=swansontec@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