From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F38337A8 for ; Fri, 4 May 2018 00:10:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 55E88F8 for ; Fri, 4 May 2018 00:10:06 +0000 (UTC) Received: by mail-lf0-f41.google.com with SMTP id w8-v6so28519589lfe.3 for ; Thu, 03 May 2018 17:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=clarkmoody-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PGLP8Ggve77an7B+/3UJs8G3FM9O47KEWUjVdatcjPQ=; b=eYAyMAH+GQJgo0UBwgRCvyN1B07MKzcgrwVw22yALSkBPiGHrUkgyH4ipUOgmkPAD7 Ix2HazPIowwMzVNEyaTJjscWceTZOhBUe6t2+/ATfGJT7DA5MiHHzl2k7g3zGXB7/egW J/zBLbV5ZQx7HHEmffJ1RL9wjhqlu58W1KggwVu4PakoxjmN3lEkwY6uKOmevppxyaqZ D1uA8rjCnglx2KGFb7TITVRXY/EsBtXTtlXeUUegGlW6izcyhvglMJgYa2t3RDltLSUO bUc7YemtaXNfg4V1pGBdYbvLN2vzT26i94o/vr9o6PsMM5cKVOJ9bHh/Y3YThffbZRxQ +emw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PGLP8Ggve77an7B+/3UJs8G3FM9O47KEWUjVdatcjPQ=; b=LUIqCqNrA+dwZ4lWMBdYg3i0vvJBbMUjiLhRJh3YPVfRYxn5NTaVVwlebl//Rg2g5Z 0gszaxv09rpzqRBjgnUy/L9CMBjmFqAB6E8U1VY8K91HvVQdv6YX7yN16KiFX2ziynyY LiCDYue8HnSmhb0ZM0qBxMfR+58zLWPMkpSMBYwqn/jjMSEQYCfcJ6dX4QDufLiQFjrw TnNEMpcbBh9y71/jX8mFwmxePHM0v/YKpdpc2iOd6NeF3tQuUOxEK4THGJldbTftUgwf YY/w4coKPXZGWDftKzqM8cVmIj5gGSOdSNg7uShe0M20PlULoHUycZMx/VK1cB5FGG1Z AUgQ== X-Gm-Message-State: ALQs6tAj5SRuUEzmyxGMqYrEWXdT8QQgqkWNJTjjEJ5r+xQQdbEeSBzS fTp53Kymb3FMph258dyXbWsGcs7YeiYIqrAyjtQ= X-Google-Smtp-Source: AB8JxZrAQASlLkHUBlfFJInEQv09IbAQVK7+VQs8jRXlphf8Fzcd0eliZ+m+Ccpwmsb6aME+vZquYF876g8aB8SlJF0= X-Received: by 2002:a2e:2c01:: with SMTP id s1-v6mr3466626ljs.120.1525392604551; Thu, 03 May 2018 17:10:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Clark Moody Date: Fri, 04 May 2018 00:09:38 +0000 Message-ID: To: Paul Brown Content-Type: multipart/alternative; boundary="000000000000565e2e056b562464" 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: Fri, 04 May 2018 11:37:07 +0000 Cc: Bitcoin Protocol Discussion 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: Fri, 04 May 2018 00:10:08 -0000 --000000000000565e2e056b562464 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Paul, The current BIP-49 / 84 use the purpose field of the derivation path to spe= cify the address format. =E2=80=8BI think sticking with the one-BIP-one-format method works. Otherwi= se, you would need to modify this proposed BIP each time a new format comes along. In that case, existing wallets that claim BIP-XXXX compliance will be incomplete. -Clark On Thu, Apr 26, 2018 at 9:05 AM, Paul Brown wrote: > Hi > > I realised after I sent my previous response that the encoding was wrong > and that my smiley face at the end of the BIP number comment got turned > into a ? and the tongue in cheek context was lost :-( > > Anyway, back onto subject. I've been thinking some more on the SLIP-0032 > adoption in this proposal and specifically the address format to use when > generating addresses. > > My proposal states bech32 serialized addresses (P2WPKH or P2WSH), however= , > I wonder whether there is some merit in extending the derivation path wit= h > an additional level below coin type to represent the address format, with > the value determined by the context of the coin type value in the > derivation path (0x00 for P2WPKH bech32, 0x01 for P2PKH base58 if coin ty= pe > is Bitcoin, 0x00 for Ethereum account format if coin type is Ether, etc). > A separate spec similar to SLIP-0044 could be created that defines the li= st > of address formats and the derivation path values. > > When importing root master seeds or distributing the xpub's for each > cosigner to each party the discovery process in the proposal would need > extending to try each address format in turn to determine whether there i= s > a 'hit' when checking balances. It does mean that the import process is > slower however the additional flexibility of supporting multiple address > formats possibly outweighs this. I'm just thinking that having a rule to > follow during discovery, particularly where non-Bitcoin coins are > concerned, is more explicit than leaving it open to the wallet implemente= r > to figure out (for altcoins, what address format to use?). > > It also means that future address formats are supported as they are simpl= y > added to the new spec list for the coin type (can be done by anyone, > similar to the way SLIP-0044 works now) - it doesn't require a new BIP to > support. For example, if address format was a derivation level in BIP44, > would BIP49 and BIP84 be needed? > > I'm somewhat musing out loud here, but I like the idea of being able to > mostly self-discover as much as possible and reducing or eliminating the > need for proprietary metadata attached to the wallet. > > Cheers > Paul > > From: clarkmoody@gmail.com On Behalf Of Clark Mood= y > Sent: 25 April 2018 15:36 > To: Paul Brown ; Bitcoin Protocol Discussion < > bitcoin-dev@lists.linuxfoundation.org> > Subject: Re: [bitcoin-dev] Multi-signature and multi-coin HD wallet in on= e > BIP32 derivation path (new BIP) > > Thanks for the proposal, Paul. > > > - What address format is expected when discovering balances and creatin= g > 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 t= he > 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 th= e > address space for the various formats. SLIP-0032 solves this bootstrappin= g > 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/ms= g05188.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 > mailto:bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --000000000000565e2e056b562464 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Paul,

The current BIP-49 / 84 use the purpose = field of the derivation path to=C2=A0specify the ad= dress format.

=E2=80=8BI think sticking with= the one-BIP-one-format method works. Otherwise, you would need to modify t= his proposed BIP each time a new format comes along. In that case, existing= wallets that claim BIP-XXXX compliance will be incomplete.

=

-Clark

On Thu, Apr 26, 2018 at 9:05 AM, Paul Brown = <paul@345.systems> wrote:
H= i

I realised after I sent my previous response that the encoding was wrong an= d that my smiley face at the end of the BIP number comment got turned into = a ? and the tongue in cheek context was lost :-(

Anyway, back onto subject.=C2=A0 I've been thinking some more on the SL= IP-0032 adoption in this proposal and specifically the address format to us= e when generating addresses.

My proposal states bech32 serialized addresses (P2WPKH or P2WSH), however, = I wonder whether there is some merit in extending the derivation path with = an additional level below coin type to represent the address format, with t= he value determined by the context of the coin type value in the derivation= path (0x00 for P2WPKH bech32, 0x01 for P2PKH base58 if coin type is Bitcoi= n, 0x00 for Ethereum account format if coin type is Ether, etc).=C2=A0 A se= parate spec similar to SLIP-0044 could be created that defines the list of = address formats and the derivation path values.

When importing root master seeds or distributing the xpub's for each co= signer to each party the discovery process in the proposal would need exten= ding to try each address format in turn to determine whether there is a = 9;hit' when checking balances.=C2=A0 It does mean that the import proce= ss is slower however the additional flexibility of supporting multiple addr= ess formats possibly outweighs this.=C2=A0 I'm just thinking that havin= g a rule to follow during discovery, particularly where non-Bitcoin coins a= re concerned, is more explicit than leaving it open to the wallet implement= er to figure out (for altcoins, what address format to use?).

It also means that future address formats are supported as they are simply = added to the new spec list for the coin type (can be done by anyone, simila= r to the way SLIP-0044 works now) - it doesn't require a new BIP to sup= port.=C2=A0 For example, if address format was a derivation level in BIP44,= would BIP49 and BIP84 be needed?

I'm somewhat musing out loud here, but I like the idea of being able to= mostly self-discover as much as possible and reducing or eliminating the n= eed for proprietary metadata attached to the wallet.

Cheers
Paul

From: clarkmoody@= gmail.com <clarkmoody@gmail.com> On Behalf Of Clark Moody
Sent: 25 April 2018 15:36
To: Paul Brown <paul@345.systems>; Bitcoin Protocol Discussion <bi= tcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Multi-signature and multi-coin HD wallet in one = BIP32 derivation path (new BIP)

Thanks for the proposal, Paul.

>=C2=A0- What address format is expected when discovering balances and c= reating transactions?

Your solution does not solve your first bullet point, since the xpub encodi= ng looks no different than any other xpub (BIP 44, 45, 49, etc). At the lea= st, 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 d= escribed in SLIP-0032 (https://github.c= om/satoshilabs/slips/blob/master/slip-0032.md). It includes the derivat= ion 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 whic= h 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 &l= t;mailto:bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi
=C2=A0
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.= =C2=A0 It combines BIP44 and BIP45 and adds in a self-describing structure = in the derivation path for multiple multi-sig combinations within the singl= e wallet along with an extended public key export file format for public ke= y distribution between parties.=C2=A0 I can particularly see this being use= ful for multiple Lightning Network 2of2 accounts for different payment chan= nels.
=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 ground as BIP44 in particula= r has been widely adopted, however, BIP44 does leave itself open to a lot o= f interpretation from a wallet portability perspective such as:
=C2=A0
- What address format is expected when discovering balances and creating tr= ansactions?
- Does the master seed represent a single-sig or multi-sig wallet?
- If multi-sig, how many cosigners and what are their extended public keys = (so that the wallet can generate the correctly formatted 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 individual parties in a mul= ti-sig group each give out a new address from a wallet, where the wallet ha= sn=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).=C2=A0 It uses a cosigner index in the derivation path so that each = party has their own path to their addresses.=C2=A0 However, BIP45 drops the= multi-coin support that BIP44 has.
=C2=A0
This is a useful discussion on the problems of a collision and the merits o= f separating cosigners in the derivation path: https://www.mail-archive.com/bitcoin-develop= ment@lists.sourceforge.net/msg05188.html
=C2=A0
For the purposes of the BIP text (and the example paths used to generate ke= ys) I=E2=80=99ve temporarily assigned it the number 46.=C2=A0 It looks like= that is available and seemed somewhat appropriate given that it builds on = the good work of BIP44 and BIP45.
=C2=A0
Paul Brown
=C2=A0
=C2=A0

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


--000000000000565e2e056b562464--