public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Clark Moody <clark@clarkmoody.com>
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 one BIP32 derivation path (new BIP)
Date: Wed, 25 Apr 2018 09:35:57 -0500	[thread overview]
Message-ID: <CAHGSxGt649Ok=jp0STnHkYvEhWSOTwMfh0oB+7jqY6MAmr4TKQ@mail.gmail.com> (raw)
In-Reply-To: <HE1PR09MB026619CDFFBA6D995600EF18988F0@HE1PR09MB0266.eurprd09.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 3730 bytes --]

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 structure
> 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 being
> 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 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
> multi-sig group each give out a new address from a wallet, where the wallet
> hasn’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
> cosigner index in the derivation path so that each party has their own path
> to their 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
> 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’ve temporarily assigned it the number 46.  It looks like that is
> available and seemed somewhat appropriate given that it builds on the good
> work of BIP44 and BIP45.
>
>
>
> Paul Brown
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 7870 bytes --]

  reply	other threads:[~2018-04-25 14:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-25  9:35 [bitcoin-dev] Multi-signature and multi-coin HD wallet in one BIP32 derivation path (new BIP) Paul Brown
2018-04-25 14:35 ` Clark Moody [this message]
2018-04-25 16:44   ` Paul Brown
2018-04-26 14:05   ` Paul Brown
2018-05-04  0:09     ` Clark Moody
2018-05-04  8:23       ` Paul Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHGSxGt649Ok=jp0STnHkYvEhWSOTwMfh0oB+7jqY6MAmr4TKQ@mail.gmail.com' \
    --to=clark@clarkmoody.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=paul@345.systems \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox