Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <swansontec@gmail.com>) id 1Yft2J-0003v4-I3
	for bitcoin-development@lists.sourceforge.net;
	Wed, 08 Apr 2015 16:41:07 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.178 as permitted sender)
	client-ip=209.85.216.178; envelope-from=swansontec@gmail.com;
	helo=mail-qc0-f178.google.com; 
Received: from mail-qc0-f178.google.com ([209.85.216.178])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Yft2I-0000nG-EQ
	for bitcoin-development@lists.sourceforge.net;
	Wed, 08 Apr 2015 16:41:07 +0000
Received: by qcrf4 with SMTP id f4so31872519qcr.0
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 08 Apr 2015 09:41:01 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.82.176 with SMTP id h45mr30197676qgd.75.1428511260972;
	Wed, 08 Apr 2015 09:41:00 -0700 (PDT)
Received: by 10.140.149.23 with HTTP; Wed, 8 Apr 2015 09:41:00 -0700 (PDT)
In-Reply-To: <CACvEmnE6jgeRmTbyoOfW+jf=EB_EmPN4FdBXz-anm4tfKJscqw@mail.gmail.com>
References: <5524D347.4040507@maza.club>
	<CABjHNoTbLz+dCPkctk95jPkdnagQQxOintYgswKCE6wB=TS9xg@mail.gmail.com>
	<CACvEmnE6jgeRmTbyoOfW+jf=EB_EmPN4FdBXz-anm4tfKJscqw@mail.gmail.com>
Date: Wed, 8 Apr 2015 09:41:00 -0700
Message-ID: <CABjHNoR_Tg6bq3mJ8vkFAOPNHz8RS-FKAEx9APMZAVhct5H0SA@mail.gmail.com>
From: William Swanson <swansontec@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(swansontec[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Yft2I-0000nG-EQ
Subject: Re: [Bitcoin-development] Request For Discussion / BIP number -
 Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 08 Apr 2015 16:41:07 -0000

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, =E6=9C=A8=E3=83=8E=E4=B8=8B=E3=81=98=E3=82=
=87=E3=81=AA <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 ea=
ch
> coin."
>
> BIP44 has a coin level, but it's a private derived level, so cosigners wo=
uld
> not be able to generate multiple crypto currencies of each others' withou=
t
> giving each other n xpubs where n is the number of currencies shared. Thi=
s
> new proposal basically sticks coin type on the public derivation side of
> things so that I could generate litecoin or darkcoin multisigs without yo=
ur
> permission...
>
> Kefkius,
>
> This BIP seems like a good fit for multi-currency wallets based on multis=
ig.
> 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 definiti=
on
> 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