📅 Original date posted:2018-05-03
📝 Original message: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 at 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: clarkmoody at gmail.com <clarkmoody at gmail.com> On Behalf Of Clark Moody
> Sent: 25 April 2018 15:36
> To: Paul Brown <paul at 345.systems>; Bitcoin Protocol Discussion <
> bitcoin-dev at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180504/90c4be2c/attachment-0001.html>;
Clark Moody [ARCHIVE] /
npub1nr…0hypj
2023-06-07 18:11:52
in reply to nevent1q…hc2v
Author Public Key
npub1nr02dq8fsgnt758nyp29waulhwwhj6j9gmlsqsknlwjem2hu8twqp0hypjPublished at
2023-06-07 18:11:52Event JSON
{
"id": "54c47879924f4313d8fd8bd71c790f767b2d1f81a08f5c15d4d204bbf6992158",
"pubkey": "98dea680e98226bf50f3205457779fbb9d796a4546ff0042d3fba59daafc3adc",
"created_at": 1686161512,
"kind": 1,
"tags": [
[
"e",
"c6ab10569dfef4760720cd4a5cf86aca60886ff21abd9f8aca0df18b98acb37b",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2018-05-03\n📝 Original message:Paul,\n\nThe current BIP-49 / 84 use the purpose field of the derivation path to specify\nthe address format.\n\nI think sticking with the one-BIP-one-format method works. Otherwise, you\nwould need to modify this proposed BIP each time a new format comes along.\nIn that case, existing wallets that claim BIP-XXXX compliance will be\nincomplete.\n\n\n-Clark\n\nOn Thu, Apr 26, 2018 at 9:05 AM, Paul Brown \u003cpaul at 345.systems\u003e wrote:\n\n\u003e Hi\n\u003e\n\u003e I realised after I sent my previous response that the encoding was wrong\n\u003e and that my smiley face at the end of the BIP number comment got turned\n\u003e into a ? and the tongue in cheek context was lost :-(\n\u003e\n\u003e Anyway, back onto subject. I've been thinking some more on the SLIP-0032\n\u003e adoption in this proposal and specifically the address format to use when\n\u003e generating addresses.\n\u003e\n\u003e My proposal states bech32 serialized addresses (P2WPKH or P2WSH), however,\n\u003e I wonder whether there is some merit in extending the derivation path with\n\u003e an additional level below coin type to represent the address format, with\n\u003e the value determined by the context of the coin type value in the\n\u003e derivation path (0x00 for P2WPKH bech32, 0x01 for P2PKH base58 if coin type\n\u003e is Bitcoin, 0x00 for Ethereum account format if coin type is Ether, etc).\n\u003e A separate spec similar to SLIP-0044 could be created that defines the list\n\u003e of address formats and the derivation path values.\n\u003e\n\u003e When importing root master seeds or distributing the xpub's for each\n\u003e cosigner to each party the discovery process in the proposal would need\n\u003e extending to try each address format in turn to determine whether there is\n\u003e a 'hit' when checking balances. It does mean that the import process is\n\u003e slower however the additional flexibility of supporting multiple address\n\u003e formats possibly outweighs this. I'm just thinking that having a rule to\n\u003e follow during discovery, particularly where non-Bitcoin coins are\n\u003e concerned, is more explicit than leaving it open to the wallet implementer\n\u003e to figure out (for altcoins, what address format to use?).\n\u003e\n\u003e It also means that future address formats are supported as they are simply\n\u003e added to the new spec list for the coin type (can be done by anyone,\n\u003e similar to the way SLIP-0044 works now) - it doesn't require a new BIP to\n\u003e support. For example, if address format was a derivation level in BIP44,\n\u003e would BIP49 and BIP84 be needed?\n\u003e\n\u003e I'm somewhat musing out loud here, but I like the idea of being able to\n\u003e mostly self-discover as much as possible and reducing or eliminating the\n\u003e need for proprietary metadata attached to the wallet.\n\u003e\n\u003e Cheers\n\u003e Paul\n\u003e\n\u003e From: clarkmoody at gmail.com \u003cclarkmoody at gmail.com\u003e On Behalf Of Clark Moody\n\u003e Sent: 25 April 2018 15:36\n\u003e To: Paul Brown \u003cpaul at 345.systems\u003e; Bitcoin Protocol Discussion \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e Subject: Re: [bitcoin-dev] Multi-signature and multi-coin HD wallet in one\n\u003e BIP32 derivation path (new BIP)\n\u003e\n\u003e Thanks for the proposal, Paul.\n\u003e\n\u003e \u003e - What address format is expected when discovering balances and creating\n\u003e transactions?\n\u003e\n\u003e Your solution does not solve your first bullet point, since the xpub\n\u003e encoding looks no different than any other xpub (BIP 44, 45, 49, etc). At\n\u003e the least, you should propose new version bytes to change the \"xpub\" in the\n\u003e encoding to some other string.\n\u003e\n\u003e Alternatively, I would suggest that you use the xpub serialization format\n\u003e described in SLIP-0032 (\n\u003e https://github.com/satoshilabs/slips/blob/master/slip-0032.md). It\n\u003e includes the derivation path within the xpub itself and uses Bech32 for\n\u003e encoding.\n\u003e\n\u003e Given a normal xpub with no additional information, a wallet must scan the\n\u003e address space for the various formats. SLIP-0032 solves this bootstrapping\n\u003e problem and avoids the UX nightmare of users being required to know to\n\u003e which BIP number the xpub conforms.\n\u003e\n\u003e Also, @luke-jr will give you a hard time to self-assigning a BIP number ;-)\n\u003e\n\u003e Thanks\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e -Clark\n\u003e\n\u003e On Wed, Apr 25, 2018 at 4:35 AM, Paul Brown via bitcoin-dev \u003cmailto:\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Hi\n\u003e\n\u003e I have written a new BIP describing a BIP32 derivation path that supports\n\u003e a single or multi-signature and multi-coin wallet from a single master\n\u003e seed. It combines BIP44 and BIP45 and adds in a self-describing structure\n\u003e in the derivation path for multiple multi-sig combinations within the\n\u003e single wallet along with an extended public key export file format for\n\u003e public key distribution between parties. I can particularly see this being\n\u003e useful for multiple Lightning Network 2of2 accounts for different payment\n\u003e channels.\n\u003e\n\u003e The BIP can be found here:\n\u003e https://github.com/gluexchange/bip/blob/master/bip-0046.mediawiki\n\u003e\n\u003e I appreciate that this might be re-hashing old ground as BIP44 in\n\u003e particular has been widely adopted, however, BIP44 does leave itself open\n\u003e to a lot of interpretation from a wallet portability perspective such as:\n\u003e\n\u003e - What address format is expected when discovering balances and creating\n\u003e transactions?\n\u003e - Does the master seed represent a single-sig or multi-sig wallet?\n\u003e - If multi-sig, how many cosigners and what are their extended public keys\n\u003e (so that the wallet can generate the correctly formatted redeem script with\n\u003e public keys in the right order)?\n\u003e - If multi-sig, how do you prevent collisions on the same address index\n\u003e (in a wallet that is occasionally connected)?\n\u003e\n\u003e BIP45 solves the collision that occurs when the individual parties in a\n\u003e multi-sig group each give out a new address from a wallet, where the wallet\n\u003e hasn’t been able to sync to mark the address as ‘used’ (this could happen\n\u003e if they gave out addresses independently at the same time). It uses a\n\u003e cosigner index in the derivation path so that each party has their own path\n\u003e to their addresses. However, BIP45 drops the multi-coin support that BIP44\n\u003e has.\n\u003e\n\u003e This is a useful discussion on the problems of a collision and the merits\n\u003e of separating cosigners in the derivation path:\n\u003e https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05188.html\n\u003e\n\u003e For the purposes of the BIP text (and the example paths used to generate\n\u003e keys) I’ve temporarily assigned it the number 46. It looks like that is\n\u003e available and seemed somewhat appropriate given that it builds on the good\n\u003e work of BIP44 and BIP45.\n\u003e\n\u003e Paul Brown\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e mailto:bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180504/90c4be2c/attachment-0001.html\u003e",
"sig": "d9818fef2ae8d347ffe6c517d38c41e915a644b4dceb0a2930893763e4e6f45bef8b8f3c82d19d44a272f5865c70a423254858f32bd08320d92660c03445d90e"
}