path: root/00/da8f6cd14fea71b3b2938db81ad3d892af803c

Return-Path: <clarkmoody@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F38337A8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  4 May 2018 00:10:06 +0000 (UTC)
Received: by mail-lf0-f41.google.com with SMTP id w8-v6so28519589lfe.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <HE1PR09MB026619CDFFBA6D995600EF18988F0@HE1PR09MB0266.eurprd09.prod.outlook.com>
	<CAHGSxGt649Ok=jp0STnHkYvEhWSOTwMfh0oB+7jqY6MAmr4TKQ@mail.gmail.com>
	<HE1PR09MB0266CE6FDFE63FD368AD8E20988E0@HE1PR09MB0266.eurprd09.prod.outlook.com>
In-Reply-To: <HE1PR09MB0266CE6FDFE63FD368AD8E20988E0@HE1PR09MB0266.eurprd09.prod.outlook.com>
From: Clark Moody <clark@clarkmoody.com>
Date: Fri, 04 May 2018 00:09:38 +0000
Message-ID: <CAHGSxGsyQ7=NdE6x7c+cfJY=3tVCNpTuy971xvqFT7SQ70PrAQ@mail.gmail.com>
To: Paul Brown <paul@345.systems>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <paul@345.systems> 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 <clarkmoody@gmail.com> On Behalf Of Clark Mood=
y
> Sent: 25 April 2018 15:36
> To: Paul Brown <paul@345.systems>; 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 <mailto:
> 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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:tahoma,s=
ans-serif;font-size:small;color:#000000">Paul,</div><div class=3D"gmail_def=
ault" style=3D"font-family:tahoma,sans-serif;font-size:small;color:#000000"=
><br></div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-se=
rif;font-size:small;color:#000000">The current BIP-49 / 84 use the purpose =
field of the derivation path to=C2=A0<span style=3D"color:rgb(0,0,0);font-f=
amily:tahoma,sans-serif;font-size:small;font-style:normal;font-variant-liga=
tures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal=
;text-align:start;text-indent:0px;text-transform:none;white-space:normal;wo=
rd-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:init=
ial;text-decoration-color:initial;float:none;display:inline">specify the ad=
dress format</span>.</div><div class=3D"gmail_extra"><br clear=3D"all"><div=
><div class=3D"m_8866112210612112144gmail_signature" data-smartmail=3D"gmai=
l_signature"><div><div class=3D"gmail_default" style=3D"font-family:tahoma,=
sans-serif;font-size:small;color:rgb(0,0,0)">=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.</div><br></div>=
<div><br></div><div>-Clark</div><div></div></div></div>
<br><div class=3D"gmail_quote">On Thu, Apr 26, 2018 at 9:05 AM, Paul Brown =
<span dir=3D"ltr">&lt;<a href=3D"mailto:paul@345.systems" target=3D"_blank"=
>paul@345.systems</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">H=
i<br>
<br>
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 :-(<br>
<br>
Anyway, back onto subject.=C2=A0 I&#39;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.<br>
<br>
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.<br>
<br>
When importing root master seeds or distributing the xpub&#39;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 &#3=
9;hit&#39; 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&#39;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?).<br>
<br>
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&#39;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?<br>
<br>
I&#39;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.<br>
<br>
Cheers<br>
<span>Paul<br>
<br>
From: <a href=3D"mailto:clarkmoody@gmail.com" target=3D"_blank">clarkmoody@=
gmail.com</a> &lt;<a href=3D"mailto:clarkmoody@gmail.com" target=3D"_blank"=
>clarkmoody@gmail.com</a>&gt; On Behalf Of Clark Moody<br>
Sent: 25 April 2018 15:36<br>
To: Paul Brown &lt;paul@345.systems&gt;; Bitcoin Protocol Discussion &lt;<a=
 href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bi=
tcoin-dev@lists.linuxfoundation.org</a>&gt;<br>
Subject: Re: [bitcoin-dev] Multi-signature and multi-coin HD wallet in one =
BIP32 derivation path (new BIP)<br>
<br>
</span><span>Thanks for the proposal, Paul.<br>
<br>
&gt;=C2=A0- What address format is expected when discovering balances and c=
reating transactions?<br>
<br>
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 &quot;xpub&quot; in =
the encoding to some other string.<br>
<br>
Alternatively, I would suggest that you use the xpub serialization format d=
escribed in SLIP-0032 (<a href=3D"https://github.com/satoshilabs/slips/blob=
/master/slip-0032.md" rel=3D"noreferrer" target=3D"_blank">https://github.c=
om/satoshilabs/slips/blob/master/slip-0032.md</a>). It includes the derivat=
ion path within the xpub itself and uses Bech32 for encoding.<br>
<br>
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.<br>
<br>
Also, @luke-jr will give you a hard time to self-assigning a BIP number ;-)=
<br>
<br>
Thanks<br>
<br>
<br>
<br>
<br>
-Clark<br>
<br>
</span><span>On Wed, Apr 25, 2018 at 4:35 AM, Paul Brown via bitcoin-dev &l=
t;mailto:<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
Hi<br>
=C2=A0<br>
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.<br>
=C2=A0<br>
The BIP can be found here: <a href=3D"https://github.com/gluexchange/bip/bl=
ob/master/bip-0046.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://=
github.com/gluexchange/bip/blob/master/bip-0046.mediawiki</a><br>
=C2=A0<br>
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:<br>
=C2=A0<br>
- What address format is expected when discovering balances and creating tr=
ansactions?<br>
- Does the master seed represent a single-sig or multi-sig wallet?<br>
- 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)?<br>
- If multi-sig, how do you prevent collisions on the same address index (in=
 a wallet that is occasionally connected)?<br>
=C2=A0<br>
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.<br>
=C2=A0<br>
This is a useful discussion on the problems of a collision and the merits o=
f separating cosigners in the derivation path: <a href=3D"https://www.mail-=
archive.com/bitcoin-development@lists.sourceforge.net/msg05188.html" rel=3D=
"noreferrer" target=3D"_blank">https://www.mail-archive.com/bitcoin-develop=
ment@lists.sourceforge.net/msg05188.html</a><br>
=C2=A0<br>
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.<br>
=C2=A0<br>
Paul Brown<br>
=C2=A0<br>
=C2=A0<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
</span>mailto:<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br>
</blockquote></div><br></div></div>

--000000000000565e2e056b562464--