From: Paul Brown <paul@345.systems>
To: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: Multi-signature and multi-coin HD wallet in one BIP32 derivation
	path (new BIP)
Thread-Index: AdPcd2nXXfizUfmCR2G/JOw0hbrwCg==
Date: Wed, 25 Apr 2018 09:35:03 +0000
Message-ID: <HE1PR09MB026619CDFFBA6D995600EF18988F0@HE1PR09MB0266.eurprd09.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: 345.systems does not designate
	permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_HE1PR09MB026619CDFFBA6D995600EF18988F0HE1PR09MB0266eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d3a03095-6dda-44fd-3574-08d5aa8fd2e8
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2018 09:35:03.7803 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: ca2d4186-9a44-49c0-a437-c7c7bbca555e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR09MB0764
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, 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 12:36:05 +0000
Subject: [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: Wed, 25 Apr 2018 09:35:09 -0000

--_000_HE1PR09MB026619CDFFBA6D995600EF18988F0HE1PR09MB0266eurp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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 structure in th=
e derivation path for multiple multi-sig combinations within the single wal=
let along with an extended public key export file format for public key dis=
tribution between parties.  I can particularly see this being useful for mu=
ltiple Lightning Network 2of2 accounts for different payment channels.

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

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:

- 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)?

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't been able to sync to mark the address as 'used' (this could happen if =
they gave out addresses independently at the same time).  It uses a cosigne=
r index in the derivation path so that each party has their own path to the=
ir addresses.  However, BIP45 drops the multi-coin support that BIP44 has.

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-development@lists.sourceforge.net/msg05188.html

For the purposes of the BIP text (and the example paths used to generate ke=
ys) I've temporarily assigned it the number 46.  It looks like that is avai=
lable and seemed somewhat appropriate given that it builds on the good work=
 of BIP44 and BIP45.

Paul Brown



--_000_HE1PR09MB026619CDFFBA6D995600EF18988F0HE1PR09MB0266eurp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;
	mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;
	mso-fareast-language:EN-US;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri",sans-serif;
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-GB" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">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.&nbsp; 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.&nbsp; I can particularly see this being useful for multiple =
Lightning Network 2of2 accounts for different
 payment channels.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The BIP can be found here: <a href=3D"https://github=
.com/gluexchange/bip/blob/master/bip-0046.mediawiki">
https://github.com/gluexchange/bip/blob/master/bip-0046.mediawiki</a><o:p><=
/o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">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:<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">- What address format is expected when discovering b=
alances and creating transactions?<o:p></o:p></p>
<p class=3D"MsoNormal">- Does the master seed represent a single-sig or mul=
ti-sig wallet?<o:p></o:p></p>
<p class=3D"MsoNormal">- 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)?<o:p></o:p></p>
<p class=3D"MsoNormal">- If multi-sig, how do you prevent collisions on the=
 same address index (in a wallet that is occasionally connected)?<o:p></o:p=
></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">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&#8217;t been able to sync to mark the address as =
&#8216;used&#8217; (this could happen if they gave out
 addresses independently at the same time).&nbsp; It uses a cosigner index =
in the derivation path so that each party has their own path to their addre=
sses.&nbsp; However, BIP45 drops the multi-coin support that BIP44 has.<o:p=
></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">This is a useful discussion on the problems of a col=
lision and the merits of separating cosigners in the derivation path:
<a href=3D"https://www.mail-archive.com/bitcoin-development@lists.sourcefor=
ge.net/msg05188.html">
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg0=
5188.html</a><o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">For the purposes of the BIP text (and the example pa=
ths used to generate keys) I&#8217;ve temporarily assigned it the number 46=
.&nbsp; It looks like that is available and seemed somewhat appropriate giv=
en that it builds on the good work of BIP44 and
 BIP45.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Paul Brown<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_HE1PR09MB026619CDFFBA6D995600EF18988F0HE1PR09MB0266eurp_--