Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets
10 messages, 8 to 16 Apr 2015. Started by Kefkius.
William Swanson (4), Kefkius (2), Alan Reiner (2), 木ノ下じょな, Vertoe Qhor
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
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:
Quoted text (17 lines)
> 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
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>:
Quoted text (42 lines)
> > 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 > > > >
------------------------------------------------------------------------------
Quoted text (3 lines)
> > 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
Quoted text (1 line)
> > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
Quoted text (7 lines)
> > 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 > >
------------------------------------------------------------------------------
Quoted text (3 lines)
> 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
Quoted text (1 line)
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
Quoted text (5 lines)
> 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
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:
Quoted text (69 lines)
> 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
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:
Quoted text (89 lines)
> 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
On Thu, Apr 9, 2015 at 1:16 PM, Kefkius <kefkius@maza•club> wrote:
Quoted text (5 lines)
> 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
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:
Quoted text (44 lines)
> 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
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:
Quoted text (18 lines)
> 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.
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:
Quoted text (51 lines)
> 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.
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:
Quoted text (119 lines)
> 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