Paul, The current BIP-49 / 84 use the purpose field of the derivation path to specify the address format.
I think sticking with the one-BIP-one-format method works. Otherwise, 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 with > 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 type > 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 list > 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 is > 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 implementer > 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, > 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: clarkmo...@gmail.com <clarkmo...@gmail.com> On Behalf Of Clark Moody > 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 one > BIP32 derivation path (new BIP) > > 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 <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 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 > mailto:bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
