[Bitcoin-development] Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets

[Bitcoin-development] Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets

[Kefkius]

I have a potential BIP, "Multi-Currency Hierarchy For Use In
Multisignature Deterministic Wallets." I'm requesting discussion on it,
and possibly assignment of a BIP number.

It's located in this github gist:
https://gist.github.com/Kefkius/1aa02945e532f8739023

Re: [Bitcoin-development] Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets

[William Swanson]

It's not really clear why this is better than BIP 44 as it already
stands. You have the same fields, but they are just in a different
order. Couldn't you just use the existing BIP 44 hierarchy, but add
the convention that "wallet/account N" is the same wallet in each
supported currency?

For example, if I have a wallet called "business expenses", which
happens to be wallet m / 44' / 0' / 5', for Bitcoin, then the same
wallet would be m / 44' / 3' / 5' for Dogecoin, and m / 44' / 2' / 5'
for Litecoin.

I am trying to think of examples where your proposal is better than
BIP 44, but I can't think of any. Even backup recovery works fine. I
assume that your idea is to continue iterating over the different
wallet indices as long as you are finding funds in *any* currency.
Well, you can still do that with BIP 44. The fields are in a different
order, but that doesn't affect the algorithm in any way.

Maybe you have some deeper insight I'm not seeing, but if so, you need
to clearly explain that in your motivation section. The current
explanation, "This limits the possible implementations of
multi-currency, multisignature wallets," is pretty vauge. Also, there
is nothing in this spec that addresses the multisignature use-case.
The BIP 45 spec does a lot of extra work to make multisignature work
smoothly.

I'm not trying to criticize your proposal. I'm just trying to
understand what it's trying to accomplish.

-William Swanson


On Wed, Apr 8, 2015 at 12:05 AM, Kefkius <kefkius@maza.club> wrote:
> I have a potential BIP, "Multi-Currency Hierarchy For Use In
> Multisignature Deterministic Wallets." I'm requesting discussion on it,
> and possibly assignment of a BIP number.
>
> It's located in this github gist:
> https://gist.github.com/Kefkius/1aa02945e532f8739023
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets

[木ノ下じょな]

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

William,

I believe the reasoning for this is stated in the Coin Type section.

"Public derivation is used so that cosigners need only know one of each
other's public keys, rather than needing to distribute public keys for each
coin."

BIP44 has a coin level, but it's a private derived level, so cosigners
would not be able to generate multiple crypto currencies of each others'
without giving each other n xpubs where n is the number of currencies
shared. This new proposal basically sticks coin type on the public
derivation side of things so that I could generate litecoin or darkcoin
multisigs without your permission...

Kefkius,

This BIP seems like a good fit for multi-currency wallets based on
multisig. So kudos for putting it in writing.

However, I don't know if this is really a BIP thing. It's not improving
Bitcoin (Bitcoin Improvement Proposal... remember?), in fact, by definition
it is improving altcoin usability.

For that reason alone I will say I disagree for a BIP for this.
- Jona


2015-04-08 16:46 GMT+09:00 William Swanson <swansontec@gmail.com>:
>
> It's not really clear why this is better than BIP 44 as it already
> stands. You have the same fields, but they are just in a different
> order. Couldn't you just use the existing BIP 44 hierarchy, but add
> the convention that "wallet/account N" is the same wallet in each
> supported currency?
>
> For example, if I have a wallet called "business expenses", which
> happens to be wallet m / 44' / 0' / 5', for Bitcoin, then the same
> wallet would be m / 44' / 3' / 5' for Dogecoin, and m / 44' / 2' / 5'
> for Litecoin.
>
> I am trying to think of examples where your proposal is better than
> BIP 44, but I can't think of any. Even backup recovery works fine. I
> assume that your idea is to continue iterating over the different
> wallet indices as long as you are finding funds in *any* currency.
> Well, you can still do that with BIP 44. The fields are in a different
> order, but that doesn't affect the algorithm in any way.
>
> Maybe you have some deeper insight I'm not seeing, but if so, you need
> to clearly explain that in your motivation section. The current
> explanation, "This limits the possible implementations of
> multi-currency, multisignature wallets," is pretty vauge. Also, there
> is nothing in this spec that addresses the multisignature use-case.
> The BIP 45 spec does a lot of extra work to make multisignature work
> smoothly.
>
> I'm not trying to criticize your proposal. I'm just trying to
> understand what it's trying to accomplish.
>
> -William Swanson
>
>
> On Wed, Apr 8, 2015 at 12:05 AM, Kefkius <kefkius@maza.club> wrote:
> > I have a potential BIP, "Multi-Currency Hierarchy For Use In
> > Multisignature Deterministic Wallets." I'm requesting discussion on it,
> > and possibly assignment of a BIP number.
> >
> > It's located in this github gist:
> > https://gist.github.com/Kefkius/1aa02945e532f8739023
> >
> >
------------------------------------------------------------------------------
> > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> > Develop your own process in accordance with the BPMN 2 standard
> > Learn Process modeling best practices with Bonita BPM through live
exercises
> > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
> > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: http://openpgpjs.org

xsBNBFTmJ8oBB/9rd+7XLxZG/x/KnhkVK2WBG8ySx91fs+qQfHIK1JrakSV3
x6x0cK3XLClASLLDomm7Od3Q/fMFzdwCEqj6z60T8wgKxsjWYSGL3mq8ucdv
iBjC3wGauk5dQKtT7tkCFyQQbX/uMsBM4ccGBICoDmIJlwJIj7fAZVqGxGOM
bO1RhYb4dbQA2qxYP7wSsHJ6/ZNAXyEphOj6blUzdqO0exAbCOZWWF+E/1SC
EuKO4RmL7Imdep7uc2Qze1UpJCZx7ASHl2IZ4UD0G3Qr3pI6/jvNlaqCTa3U
3/YeJwEubFsd0AVy0zs809RcKKgX3W1q+hVDTeWinem9RiOG/vT+Eec/ABEB
AAHNI2tpbm9zaGl0YSA8a2lub3NoaXRham9uYUBnbWFpbC5jb20+wsByBBAB
CAAmBQJU5ifRBgsJCAcDAgkQRB9iZ30dlisEFQgCCgMWAgECGwMCHgEAAC6Z
B/9otobf0ASHYdlUBeIPXdDopyjQhR2RiZGYaS0VZ5zzHYLDDMW6ZIYm5CjO
Fc09ETLGKFxH2RcCOK2dzwz+KRU4xqOrt/l5gyd50cFE1nOhUN9+/XaPgrou
WhyT9xLeGit7Xqhht93z2+VanTtJAG6lWbAZLIZAMGMuLX6sJDCO0GiO5zxa
02Q2D3kh5GL57A5+oVOna12JBRaIA5eBGKVCp3KToT/z48pxBe3WAmLo0zXr
hEgTSzssfb2zTwtB3Ogoedj+cU2bHJvJ8upS/jMr3TcdguySmxJlGpocVC/e
qxq12Njv+LiETOrD8atGmXCnA+nFNljBkz+l6ADl93jHzsBNBFTmJ9EBCACu
Qq9ZnP+aLU/Rt6clAfiHfTFBsJvLKsdIKeE6qHzsU1E7A7bGQKTtLEnhCCQE
W+OQP+sgbOWowIdH9PpwLJ3Op+NhvLlMxRvbT36LwCmBL0yD7bMqxxmmVj8n
vlMMRSe4wDSIG19Oy7701imnHZPm/pnPlneg/Meu/UffpcDWYBbAFX8nrXPY
vkVULcI/qTcCxW/+S9fwoXjQhWHaiJJ6y3cYOSitN31W9zgcMvLwLX3JgDxE
flkwq/M+ZkfCYnS3GAPEt8GkVKy2eHtCJuNkGFlCAmKMX0yWzHRAkqOMN5KP
LFbkKY2GQl13ztWp82QYJZpj5af6dmyUosurn6AZABEBAAHCwF8EGAEIABMF
AlTmJ9QJEEQfYmd9HZYrAhsMAABKbgf/Ulu5JAk4fXgH0DtkMmdkFiKEFdkW
0Wkw7Vhd5eZ4NzeP9kOkD01OGweT9hqzwhfT2CNXCGxh4UnvEM1ZMFypIKdq
0XpLLJMrDOQO021UjAa56vHZPAVmAM01z5VzHJ7ekjgwrgMLmVkm0jWKEKaO
n/MW7CyphG7QcZ6cJX2f6uJcekBlZRw9TNYRnojMjkutlOVhYJ3J78nc/k0p
kcgV63GB6D7wHRF4TVe4xIBqKpbBhhN+ISwFN1z+gx3lfyRMSmiTSrGdKEQe
XSIQKG8XZQZUDhLNkqPS+7EMV1g7+lOfT4GhLL68dUXDa1e9YxGH6zkpVECw
Spe3vsHZr6CqFg==
=/vUJ
-----END PGP PUBLIC KEY BLOCK-----

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

Re: [Bitcoin-development] Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets

[William Swanson]

Oops, sorry I missed that.

Since that's the reason this proposal exists, I would consider putting
it right up top where people can see it. Also, since this proposal is
specifically designed for multi-sig, I would look at what BIP45 is
doing and maybe incorporate a "cosigner_index" branch. Otherwise, this
idea seems like a reasonable way to organize a wallet.

-William

On Wed, Apr 8, 2015 at 9:28 AM, 木ノ下じょな <kinoshitajona@gmail.com> wrote:
> William,
>
> I believe the reasoning for this is stated in the Coin Type section.
>
> "Public derivation is used so that cosigners need only know one of each
> other's public keys, rather than needing to distribute public keys for each
> coin."
>
> BIP44 has a coin level, but it's a private derived level, so cosigners would
> not be able to generate multiple crypto currencies of each others' without
> giving each other n xpubs where n is the number of currencies shared. This
> new proposal basically sticks coin type on the public derivation side of
> things so that I could generate litecoin or darkcoin multisigs without your
> permission...
>
> Kefkius,
>
> This BIP seems like a good fit for multi-currency wallets based on multisig.
> So kudos for putting it in writing.
>
> However, I don't know if this is really a BIP thing. It's not improving
> Bitcoin (Bitcoin Improvement Proposal... remember?), in fact, by definition
> it is improving altcoin usability.
>
> For that reason alone I will say I disagree for a BIP for this.
> - Jona
>
>
> 2015-04-08 16:46 GMT+09:00 William Swanson <swansontec@gmail.com>:
>>
>> It's not really clear why this is better than BIP 44 as it already
>> stands. You have the same fields, but they are just in a different
>> order. Couldn't you just use the existing BIP 44 hierarchy, but add
>> the convention that "wallet/account N" is the same wallet in each
>> supported currency?
>>
>> For example, if I have a wallet called "business expenses", which
>> happens to be wallet m / 44' / 0' / 5', for Bitcoin, then the same
>> wallet would be m / 44' / 3' / 5' for Dogecoin, and m / 44' / 2' / 5'
>> for Litecoin.
>>
>> I am trying to think of examples where your proposal is better than
>> BIP 44, but I can't think of any. Even backup recovery works fine. I
>> assume that your idea is to continue iterating over the different
>> wallet indices as long as you are finding funds in *any* currency.
>> Well, you can still do that with BIP 44. The fields are in a different
>> order, but that doesn't affect the algorithm in any way.
>>
>> Maybe you have some deeper insight I'm not seeing, but if so, you need
>> to clearly explain that in your motivation section. The current
>> explanation, "This limits the possible implementations of
>> multi-currency, multisignature wallets," is pretty vauge. Also, there
>> is nothing in this spec that addresses the multisignature use-case.
>> The BIP 45 spec does a lot of extra work to make multisignature work
>> smoothly.
>>
>> I'm not trying to criticize your proposal. I'm just trying to
>> understand what it's trying to accomplish.
>>
>> -William Swanson
>>
>>
>> On Wed, Apr 8, 2015 at 12:05 AM, Kefkius <kefkius@maza.club> wrote:
>> > I have a potential BIP, "Multi-Currency Hierarchy For Use In
>> > Multisignature Deterministic Wallets." I'm requesting discussion on it,
>> > and possibly assignment of a BIP number.
>> >
>> > It's located in this github gist:
>> > https://gist.github.com/Kefkius/1aa02945e532f8739023

Re: [Bitcoin-development] Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets

[Kefkius]

William,

I've amended the proposal's "Motivation" section slightly for
clarification. I'm not sure how a "cosigner_index" branch would benefit
this proposal. Granted, I don't fully understand the benefits of the
"cosigner_index" branch in BIP-0045. From what I understand, the
"wallet" branch of my proposal seems to accomplish a similar goal.

Jona,

Your explanation is correct. As for this being appropriate as a BIP, I
agree that it's an arguable point to say it improves Bitcoin. However,
this proposal exists because of BIP-0044, which also describes a
multi-currency hierarchy. For that reason, I think this is an
appropriate proposal.

Thank you both for your feedback.

On 04/08/2015 12:41 PM, William Swanson wrote:
> Oops, sorry I missed that.
>
> Since that's the reason this proposal exists, I would consider putting
> it right up top where people can see it. Also, since this proposal is
> specifically designed for multi-sig, I would look at what BIP45 is
> doing and maybe incorporate a "cosigner_index" branch. Otherwise, this
> idea seems like a reasonable way to organize a wallet.
>
> -William
>
> On Wed, Apr 8, 2015 at 9:28 AM, 木ノ下じょな <kinoshitajona@gmail.com> wrote:
>> William,
>>
>> I believe the reasoning for this is stated in the Coin Type section.
>>
>> "Public derivation is used so that cosigners need only know one of each
>> other's public keys, rather than needing to distribute public keys for each
>> coin."
>>
>> BIP44 has a coin level, but it's a private derived level, so cosigners would
>> not be able to generate multiple crypto currencies of each others' without
>> giving each other n xpubs where n is the number of currencies shared. This
>> new proposal basically sticks coin type on the public derivation side of
>> things so that I could generate litecoin or darkcoin multisigs without your
>> permission...
>>
>> Kefkius,
>>
>> This BIP seems like a good fit for multi-currency wallets based on multisig.
>> So kudos for putting it in writing.
>>
>> However, I don't know if this is really a BIP thing. It's not improving
>> Bitcoin (Bitcoin Improvement Proposal... remember?), in fact, by definition
>> it is improving altcoin usability.
>>
>> For that reason alone I will say I disagree for a BIP for this.
>> - Jona
>>
>>
>> 2015-04-08 16:46 GMT+09:00 William Swanson <swansontec@gmail.com>:
>>> It's not really clear why this is better than BIP 44 as it already
>>> stands. You have the same fields, but they are just in a different
>>> order. Couldn't you just use the existing BIP 44 hierarchy, but add
>>> the convention that "wallet/account N" is the same wallet in each
>>> supported currency?
>>>
>>> For example, if I have a wallet called "business expenses", which
>>> happens to be wallet m / 44' / 0' / 5', for Bitcoin, then the same
>>> wallet would be m / 44' / 3' / 5' for Dogecoin, and m / 44' / 2' / 5'
>>> for Litecoin.
>>>
>>> I am trying to think of examples where your proposal is better than
>>> BIP 44, but I can't think of any. Even backup recovery works fine. I
>>> assume that your idea is to continue iterating over the different
>>> wallet indices as long as you are finding funds in *any* currency.
>>> Well, you can still do that with BIP 44. The fields are in a different
>>> order, but that doesn't affect the algorithm in any way.
>>>
>>> Maybe you have some deeper insight I'm not seeing, but if so, you need
>>> to clearly explain that in your motivation section. The current
>>> explanation, "This limits the possible implementations of
>>> multi-currency, multisignature wallets," is pretty vauge. Also, there
>>> is nothing in this spec that addresses the multisignature use-case.
>>> The BIP 45 spec does a lot of extra work to make multisignature work
>>> smoothly.
>>>
>>> I'm not trying to criticize your proposal. I'm just trying to
>>> understand what it's trying to accomplish.
>>>
>>> -William Swanson
>>>
>>>
>>> On Wed, Apr 8, 2015 at 12:05 AM, Kefkius <kefkius@maza.club> wrote:
>>>> I have a potential BIP, "Multi-Currency Hierarchy For Use In
>>>> Multisignature Deterministic Wallets." I'm requesting discussion on it,
>>>> and possibly assignment of a BIP number.
>>>>
>>>> It's located in this github gist:
>>>> https://gist.github.com/Kefkius/1aa02945e532f8739023
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets

[William Swanson]

On Thu, Apr 9, 2015 at 1:16 PM, Kefkius <kefkius@maza.club> wrote:
> I've amended the proposal's "Motivation" section slightly for
> clarification. I'm not sure how a "cosigner_index" branch would benefit
> this proposal. Granted, I don't fully understand the benefits of the
> "cosigner_index" branch in BIP-0045. From what I understand, the
> "wallet" branch of my proposal seems to accomplish a similar goal.

Suppose Alice and Bob share a multi-sig wallet. Alice would like to
accept payment from Mallory, and Bob would like to accept payment from
Maude. So, they would each like to create a separate payment address.
If Alice and Bob both generate the same address, the incoming funds
would be mixed together (bad), and Mallory and Maude might learn about
the relationship between Alice and Bob (also bad).

Unfortunately, Alice and Bob are in a place where they can't
communicate (maybe Bob has no cell service). There is no way for Bob
to send a message like "I'm making a request on address_index N,
Alice, please use a different index for your request."

The cosigner_index solves this. When they set up the wallet, Alice and
Bob agree to always use a different value for the cosigner_index. That
way, addresses from Alice will never overlap with addresses from Bob,
since they are on different branches. Doing it this way adds privacy
and doesn't cost anything.

With this added in, your path would be:

m / purpose' / wallet' / coin_type / cosigner_index / change / address_index

XPUB's generated from your wallet would then be compatible with XPUB's
generated by other multi-sig wallets like CoPay, since the
(cosigner_index / change / address_index) structure stays the same.

-William Swanson

Re: [Bitcoin-development] Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets

[Alan Reiner]

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.

-Alan



On 04/09/2015 06:24 PM, William Swanson wrote:
> On Thu, Apr 9, 2015 at 1:16 PM, Kefkius <kefkius@maza.club> wrote:
>> I've amended the proposal's "Motivation" section slightly for
>> clarification. I'm not sure how a "cosigner_index" branch would benefit
>> this proposal. Granted, I don't fully understand the benefits of the
>> "cosigner_index" branch in BIP-0045. From what I understand, the
>> "wallet" branch of my proposal seems to accomplish a similar goal.
> Suppose Alice and Bob share a multi-sig wallet. Alice would like to
> accept payment from Mallory, and Bob would like to accept payment from
> Maude. So, they would each like to create a separate payment address.
> If Alice and Bob both generate the same address, the incoming funds
> would be mixed together (bad), and Mallory and Maude might learn about
> the relationship between Alice and Bob (also bad).
>
> Unfortunately, Alice and Bob are in a place where they can't
> communicate (maybe Bob has no cell service). There is no way for Bob
> to send a message like "I'm making a request on address_index N,
> Alice, please use a different index for your request."
>
> The cosigner_index solves this. When they set up the wallet, Alice and
> Bob agree to always use a different value for the cosigner_index. That
> way, addresses from Alice will never overlap with addresses from Bob,
> since they are on different branches. Doing it this way adds privacy
> and doesn't cost anything.
>
> With this added in, your path would be:
>
> m / purpose' / wallet' / coin_type / cosigner_index / change / address_index
>
> XPUB's generated from your wallet would then be compatible with XPUB's
> generated by other multi-sig wallets like CoPay, since the
> (cosigner_index / change / address_index) structure stays the same.
>
> -William Swanson
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets

[William Swanson]

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.

Re: [Bitcoin-development] Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets

[Alan Reiner]

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

Re: [Bitcoin-development] Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets

[Vertoe Qhor]

I'm supporting this proposal and since I'm already using the Encompass
wallet software I would like to highlight that this use case is not only
practical but has already a working reference implementation.

The only donwside I see is that it means we get yet another HD wallet
definition.

Is there anything else what would speak against assigning a BIP number
to this proposal? This would allow kefkius and his team to use the
standard in Encompass and share it with other software packages which
might be interested in using deterministic cross-currency wallets.

On 04/09/2015 10:16 PM, Kefkius wrote:
> William,
>
> I've amended the proposal's "Motivation" section slightly for
> clarification. I'm not sure how a "cosigner_index" branch would benefit
> this proposal. Granted, I don't fully understand the benefits of the
> "cosigner_index" branch in BIP-0045. From what I understand, the
> "wallet" branch of my proposal seems to accomplish a similar goal.
>
> Jona,
>
> Your explanation is correct. As for this being appropriate as a BIP, I
> agree that it's an arguable point to say it improves Bitcoin. However,
> this proposal exists because of BIP-0044, which also describes a
> multi-currency hierarchy. For that reason, I think this is an
> appropriate proposal.
>
> Thank you both for your feedback.
>
> On 04/08/2015 12:41 PM, William Swanson wrote:
>> Oops, sorry I missed that.
>>
>> Since that's the reason this proposal exists, I would consider putting
>> it right up top where people can see it. Also, since this proposal is
>> specifically designed for multi-sig, I would look at what BIP45 is
>> doing and maybe incorporate a "cosigner_index" branch. Otherwise, this
>> idea seems like a reasonable way to organize a wallet.
>>
>> -William
>>
>> On Wed, Apr 8, 2015 at 9:28 AM, 木ノ下じょな <kinoshitajona@gmail.com> wrote:
>>> William,
>>>
>>> I believe the reasoning for this is stated in the Coin Type section.
>>>
>>> "Public derivation is used so that cosigners need only know one of each
>>> other's public keys, rather than needing to distribute public keys for each
>>> coin."
>>>
>>> BIP44 has a coin level, but it's a private derived level, so cosigners would
>>> not be able to generate multiple crypto currencies of each others' without
>>> giving each other n xpubs where n is the number of currencies shared. This
>>> new proposal basically sticks coin type on the public derivation side of
>>> things so that I could generate litecoin or darkcoin multisigs without your
>>> permission...
>>>
>>> Kefkius,
>>>
>>> This BIP seems like a good fit for multi-currency wallets based on multisig.
>>> So kudos for putting it in writing.
>>>
>>> However, I don't know if this is really a BIP thing. It's not improving
>>> Bitcoin (Bitcoin Improvement Proposal... remember?), in fact, by definition
>>> it is improving altcoin usability.
>>>
>>> For that reason alone I will say I disagree for a BIP for this.
>>> - Jona
>>>
>>>
>>> 2015-04-08 16:46 GMT+09:00 William Swanson <swansontec@gmail.com>:
>>>> It's not really clear why this is better than BIP 44 as it already
>>>> stands. You have the same fields, but they are just in a different
>>>> order. Couldn't you just use the existing BIP 44 hierarchy, but add
>>>> the convention that "wallet/account N" is the same wallet in each
>>>> supported currency?
>>>>
>>>> For example, if I have a wallet called "business expenses", which
>>>> happens to be wallet m / 44' / 0' / 5', for Bitcoin, then the same
>>>> wallet would be m / 44' / 3' / 5' for Dogecoin, and m / 44' / 2' / 5'
>>>> for Litecoin.
>>>>
>>>> I am trying to think of examples where your proposal is better than
>>>> BIP 44, but I can't think of any. Even backup recovery works fine. I
>>>> assume that your idea is to continue iterating over the different
>>>> wallet indices as long as you are finding funds in *any* currency.
>>>> Well, you can still do that with BIP 44. The fields are in a different
>>>> order, but that doesn't affect the algorithm in any way.
>>>>
>>>> Maybe you have some deeper insight I'm not seeing, but if so, you need
>>>> to clearly explain that in your motivation section. The current
>>>> explanation, "This limits the possible implementations of
>>>> multi-currency, multisignature wallets," is pretty vauge. Also, there
>>>> is nothing in this spec that addresses the multisignature use-case.
>>>> The BIP 45 spec does a lot of extra work to make multisignature work
>>>> smoothly.
>>>>
>>>> I'm not trying to criticize your proposal. I'm just trying to
>>>> understand what it's trying to accomplish.
>>>>
>>>> -William Swanson
>>>>
>>>>
>>>> On Wed, Apr 8, 2015 at 12:05 AM, Kefkius <kefkius@maza.club> wrote:
>>>>> I have a potential BIP, "Multi-Currency Hierarchy For Use In
>>>>> Multisignature Deterministic Wallets." I'm requesting discussion on it,
>>>>> and possibly assignment of a BIP number.
>>>>>
>>>>> It's located in this github gist:
>>>>> https://gist.github.com/Kefkius/1aa02945e532f8739023
>> ------------------------------------------------------------------------------
>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
>> Develop your own process in accordance with the BPMN 2 standard
>> Learn Process modeling best practices with Bonita BPM through live exercises
>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development