Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A4F5888D for ; Wed, 25 Apr 2018 14:36:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6A5FB42D for ; Wed, 25 Apr 2018 14:36:30 +0000 (UTC) Received: by mail-lf0-f44.google.com with SMTP id u21-v6so24215005lfu.9 for ; Wed, 25 Apr 2018 07:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=6YCKCHyLh+ZRk+eJsnsiepWem6dwiLtwD5I8W0LSsxA=; b=qlMoHjJ0bTdnLaG9XwUYfC70O5CLpMC4z9c/jhakMAWjbd1nreEBnJXQ72wncpA1EH QXihsjZb3qSFpwp/t5mJ2XmiMatXAWlx/4D+FCNiWWv/jMLnWARopNmHT5I0yfLr/6eA /yjU94rfTfFF475iEafpWykL+07bPe744KUlRigSnxr7WDXgJ/j9oHm1Xb2YO/FzM8wP hpraxhseu0moNfCd1oShhxPNpIsaNEkLmYG7wnH4ZVgz8wq+fqNbeYQMIaQZX2uh8rWc x2xN7YAiykdcIDvqS+SEELwJFhu50Frfw0rBSET3c0Wg5JyR3/FqN98SDXh5LbBDBZiz jCMQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=clarkmoody-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=6YCKCHyLh+ZRk+eJsnsiepWem6dwiLtwD5I8W0LSsxA=; b=OQywjZCV4mxxX6wzt4MqW7H5E0iRP/sQeOlN558QiWKWap4Nedk4UovkXgISnn4nEl G9kjsbO7jRz3FGYt6W31Ka5e9+C6JWR8eCSyT6GUOVZhmdKHdC378a0HcGdzJqtTYCLM dD8nucN/LmlayM0c4YGyJkSrARRndc+afOU8PsuRybzrJVcIOc3ySM44oKp0MFQ9s1ie O8jDKdho5vDlmW/28RUwDfCNXyX1l4+DJJ+zfLWcDu/K+L++fLCwPLUwMrAc708r2ygV DjLCkKu0/JyN3pHKPVFqNyEhU6Oc3ZslcAlkalNf5J0/KXTtJPDi9Dqdgj62HDNzRx2I DR3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=6YCKCHyLh+ZRk+eJsnsiepWem6dwiLtwD5I8W0LSsxA=; b=Cgwb0hO+qoZCTTsmoSjyupy1FDZb2fNwjOs90LNSTjDP4huASXllMPYCeY3sjGBKH1 t1mqzUYASGHp+W0GyVe7PGkWc6RTQ+e7A6Cx512BxgMXUJDFSnmsNa3WWkK8nQfFvFtO 4req7GP1ujvPN1mCkZODojeMkUJf4CpI97sslz7uG3F7PmV9z+7/LfZ8VUfqQ1E23Hwt kAy97la44EuK+PUFBStg/A6U/Mzjfk/X8otsDdeJFlpnu25xZree3Ouphf1WoHYqZuur cQAXkoa4T9Ep8yGsg0yuUibthKvt6fcPkd9NGOovrX/rLgvAfU63YuNu8co0AHkmAINh +k9g== X-Gm-Message-State: ALQs6tAMjLjRq3E1sjREnAfD5EwOSK9pS1QyfpITW8rQ/uXoTOBn6qJL K50vfVAhV7baXDhXLxVtmeYVxUlUHrX1m3f+wU5SOOQZ X-Google-Smtp-Source: AB8JxZoEgxxlE9TSfc39GGCzXu4Tw94cuyLVVuGUUKbcqYXkHsADUcbH/gx6PafvzrnSeuZRrm6uOOdI9l/BfuG35ig= X-Received: by 2002:a19:8f82:: with SMTP id s2-v6mr15133094lfk.55.1524666988624; Wed, 25 Apr 2018 07:36:28 -0700 (PDT) MIME-Version: 1.0 Sender: clarkmoody@gmail.com Received: by 10.46.101.8 with HTTP; Wed, 25 Apr 2018 07:35:57 -0700 (PDT) In-Reply-To: References: From: Clark Moody Date: Wed, 25 Apr 2018 09:35:57 -0500 X-Google-Sender-Auth: BoQ2-9dNTwS2yW4DpANo6e7uCPk Message-ID: To: Paul Brown , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000041ff05056aad327d" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 25 Apr 2018 14:40:33 +0000 Subject: Re: [bitcoin-dev] Multi-signature and multi-coin HD wallet in one BIP32 derivation path (new BIP) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 14:36:31 -0000 --00000000000041ff05056aad327d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the proposal, Paul. *> - What address format is expected when discovering balances and creating transactions?* Your solution does not solve your first bullet point, since the xpub encoding looks no different than any other xpub (BIP 44, 45, 49, etc). At the least, you should propose new version bytes to change the "xpub" in the encoding to some other string. Alternatively, I would suggest that you use the xpub serialization format described in SLIP-0032 ( https://github.com/satoshilabs/slips/blob/master/slip-0032.md). It includes the derivation path within the xpub itself and uses Bech32 for encoding. Given a normal xpub with no additional information, a wallet must scan the address space for the various formats. SLIP-0032 solves this bootstrapping problem and avoids the UX nightmare of users being required to know to which BIP number the xpub conforms. Also, @luke-jr will give you a hard time to self-assigning a BIP number ;-) Thanks -Clark On Wed, Apr 25, 2018 at 4:35 AM, Paul Brown via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi > > > > I have written a new BIP describing a BIP32 derivation path that supports > a single or multi-signature and multi-coin wallet from a single master > seed. It combines BIP44 and BIP45 and adds in a self-describing structur= e > in the derivation path for multiple multi-sig combinations within the > single wallet along with an extended public key export file format for > public key distribution between parties. I can particularly see this bei= ng > useful for multiple Lightning Network 2of2 accounts for different payment > channels. > > > > The BIP can be found here: https://github.com/gluexchange/bip/blob/master= / > bip-0046.mediawiki > > > > I appreciate that this might be re-hashing old ground as BIP44 in > particular has been widely adopted, however, BIP44 does leave itself open > to a lot of interpretation from a wallet portability perspective such as: > > > > - What address format is expected when discovering balances and creating > transactions? > > - Does the master seed represent a single-sig or multi-sig wallet? > > - If multi-sig, how many cosigners and what are their extended public key= s > (so that the wallet can generate the correctly formatted redeem script wi= th > public keys in the right order)? > > - If multi-sig, how do you prevent collisions on the same address index > (in a wallet that is occasionally connected)? > > > > BIP45 solves the collision that occurs when the individual parties in a > multi-sig group each give out a new address from a wallet, where the wall= et > hasn=E2=80=99t been able to sync to mark the address as =E2=80=98used=E2= =80=99 (this could happen > if they gave out addresses independently at the same time). It uses a > cosigner index in the derivation path so that each party has their own pa= th > to their addresses. However, BIP45 drops the multi-coin support that BIP= 44 > has. > > > > This is a useful discussion on the problems of a collision and the merits > of separating cosigners in the derivation path: > https://www.mail-archive.com/bitcoin-development@lists. > sourceforge.net/msg05188.html > > > > For the purposes of the BIP text (and the example paths used to generate > keys) I=E2=80=99ve temporarily assigned it the number 46. It looks like = that is > available and seemed somewhat appropriate given that it builds on the goo= d > work of BIP44 and BIP45. > > > > Paul Brown > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --00000000000041ff05056aad327d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the proposal, Paul.<= /div>

>= ;=C2=A0- What address format is expected when discovering balances a= nd creating transactions?

Your solution does not= solve your first bullet point, since the xpub encoding looks no dif= ferent than any other xpub (BIP 44, 45, 49, etc). At the least, you should = propose new version bytes to change the "xpub" in the encoding to= some other string.

Alternatively, I would suggest that you use the xpub s= erialization format described in SLIP-0032 (https://github.com/satoshilabs/s= lips/blob/master/slip-0032.md). It includes the derivation path within = the xpub itself and uses Bech32 for encoding.

Given a normal xpub with no additio= nal information, a wallet must scan the address space for the various forma= ts. SLIP-0032 solves this bootstrapping problem and avoids the UX nightmare= of users being required to know to which BIP number the xpub conforms.

Also, @= luke-jr will give you a hard time to self-assigning a BIP number ;-)
<= div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-siz= e:small;color:rgb(0,0,0)">
Thanks
=



-Clark

On Wed, Apr 25, 2018 at 4:35 AM, Paul Brown = via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org= > wrote:

Hi

=C2=A0

I have written a new BIP describing a BIP32 derivati= on path that supports a single or multi-signature and multi-coin wallet fro= m a single master seed.=C2=A0 It combines BIP44 and BIP45 and adds in a sel= f-describing structure in the derivation path for multiple multi-sig combinations within the single wallet along wi= th an extended public key export file format for public key distribution be= tween parties.=C2=A0 I can particularly see this being useful for multiple = Lightning Network 2of2 accounts for different payment channels.

=C2=A0

The BIP can be found here: https://github.com/gluexchange/bip/blob/master/bip-0046.mediawiki=

=C2=A0

I appreciate that this might be re-hashing old groun= d as BIP44 in particular has been widely adopted, however, BIP44 does leave= itself open to a lot of interpretation from a wallet portability perspecti= ve such as:

=C2=A0

- What address format is expected when discovering b= alances and creating transactions?

- Does the master seed represent a single-sig or mul= ti-sig wallet?

- If multi-sig, how many cosigners and what are thei= r extended public keys (so that the wallet can generate the correctly forma= tted redeem script with public keys in the right order)?

- If multi-sig, how do you prevent collisions on the= same address index (in a wallet that is occasionally connected)?=

=C2=A0

BIP45 solves the collision that occurs when the indi= vidual parties in a multi-sig group each give out a new address from a wall= et, where the wallet hasn=E2=80=99t been able to sync to mark the address a= s =E2=80=98used=E2=80=99 (this could happen if they gave out addresses independently at the same time).=C2=A0 It uses a cosigner index = in the derivation path so that each party has their own path to their addre= sses.=C2=A0 However, BIP45 drops the multi-coin support that BIP44 has.<= /u>

=C2=A0

This is a useful discussion on the problems of a col= lision and the merits of separating cosigners in the derivation path: https://www.mail-archive.com/bitcoin-development@lists.sourceforg= e.net/msg05188.html

=C2=A0

For the purposes of the BIP text (and the example pa= ths used to generate keys) I=E2=80=99ve temporarily assigned it the number = 46.=C2=A0 It looks like that is available and seemed somewhat appropriate g= iven that it builds on the good work of BIP44 and BIP45.=

=C2=A0

Paul Brown

=C2=A0

=C2=A0


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--00000000000041ff05056aad327d--