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 ) 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 ; 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: References: <5524D347.4040507@maza.club> Date: Wed, 8 Apr 2015 09:41:00 -0700 Message-ID: From: William Swanson To: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 : >> >> 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 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