HD derivation of Bitmessage addresses #171

justusranvier commented at 8:19 PM on July 10, 2015: contributor

This specification is an application of BIP-32 and BIP-43 which allows a multiple-identity Bitmessage client to derive all needed keypairs from a single seed, which may be the same seed used to derive Bitcoin keypairs without the possibility of collision, greatly simplifying backup requirements and improving the user experience.

HD derivation of Bitmessage addresses

This specification allows a multiple-identity Bitmessage client to derive all needed keypairs from a single seed, which may be the same seed
used to derive Bitcoin keypairs without the possibility of collision, greatly simplifying backup requirements and improving the user
experience.

270355379a

clarify usages of public vs hardened derivation 8a5283e2f5

update proposal for number assigned by BIP maintainer a2fcb5f82f

luke-jr commented at 10:51 PM on September 3, 2015: member

Bitmessage is not Bitcoin. Did the editor really assign this BIP 82?

gmaxwell commented at 11:06 PM on September 3, 2015: contributor

I did assign 82 here. Can you take discussion to the list?

justusranvier commented at 11:53 PM on September 3, 2015: contributor

Quoting from BIP-43:

"We encourage different schemes to apply for assigning a separate BIP number and use the same number for purpose field, so addresses won't be generated from overlapping BIP32 spaces."

"Because this scheme can be used to generate nodes for more cryptocurrencies at once, or even something totally unrelated to cryptocurrencies..."

The BIP process is currently the only defined way to use the BIP-43 scheme for deterministic keypair derivation while achieving its stated goal of preventing namespace collisions.

luke-jr added the label New BIP on Oct 23, 2015

luke-jr commented at 5:39 PM on January 8, 2016: member

@justusranvier Please let me know when you've decided to take this proposal to SLIP, or if you want me to merge it as a BIP. Either way, it also needs a Copyright section.

bgok commented at 6:13 PM on January 8, 2016: none

@luke-jr I have a few other proposals regarding BIP32 hierarchy. Not all are specifically bitcoin. Should I submit them here?

luke-jr commented at 6:47 PM on January 8, 2016: member

@bgok Only ones specifically for Bitcoin ought to be submitted as BIPs, to the Bitcoin-dev mailing list (pull requests here are only for things after they have been discussed on the ML).

luke-jr commented at 6:47 PM on January 8, 2016: member

See SatoshiLabs Improvement Proposals for altcoin-related things: https://doc.satoshilabs.com/slips/

bgok commented at 7:31 PM on January 8, 2016: none

@luke-jr Yeah, unfortunately that's not a vendor neutral repository. I work for a competitor. It sounds like we need a 'BIP32 Wallet Hierarchy Proposal' repository. I've already floated the idea with a couple of other vendors, I'll also put it out there on the dev list. Thanks.

justusranvier commented at 8:08 PM on January 8, 2016: contributor

I have not submitted anything to SLIP, and I'm not particular eager to do so.

The problem I think is conflicting views of what the BIP repository should be.

I think informational BIPs, as opposed to standard track BIPS, should be broadly defined as "anything which may be useful for the developer of a Bitcoin application".

Having a central, vendor-neutral, repository for useful standards is far more beneficial to BIP users than being required to cross reference against other repositories for no reason other than to keep this one pure.

It would make this repository more useful to developers to reserve strict relevancy checks to standard track BIPs, and be more lenient with the informational BIPs.

luke-jr commented at 8:12 PM on January 8, 2016: member

@justusranvier I do not see how this is in any way relevant or useful to the developer of a Bitcoin application (that is not a Bitmessage application). Can you explain? Maybe I am missing something.

bgok commented at 8:18 PM on January 8, 2016: none

I share @justusranvier's frustration.

Also, BIP43 creates a dependency on the BIP process for any use of the BIP32 Hierarchy, bitcoin related or not. @justusranvier, would you be interested in championing a Wallet Hierarchy Proposal repository with me?

justusranvier commented at 8:23 PM on January 8, 2016: contributor

BIP-43 is a method for deriving secp256k1 keys from a single seed, and secp256k1 keys are used for more things than just Bitcoin addresses.

Requiring users to back up just one seed vs several is virtually always desirable.

For applications to use BIP-43 effectively, they need namespace management to make sure keys used for different purposes do not collide (purpose code).

It's entirely possible that a Bitcoin wallet might have added functionality like transferring out of band data via Bitmessage. It might also use secp256k1 keys derived from the same master seed to encrypt its on-disk storage, or for transport layer encryption, or for virtually anything else that requires encryption or signing.

BIP-43 is a fantastic way to manage all these keys and make sure they can be deterministically re-generated from the seed.

As originally specified, BIP-43 purpose codes were BIP numbers, so which made it even more convenient. If a wallet developer is implementing BIP-44 accounts, they know to use purpose code 44 in the derivation path, and similarly BIP-47 addresses are derived using purpose code 47. It makes life easier for everyone.

luke-jr commented at 8:30 PM on January 8, 2016: member

Perhaps something like SLIP-44 should be used to subdivide the purpose codes between independent projects (Bitcoin, Bitmessage, altcoins, etc)? If SLIP is too vender-biased, maybe SLIP-44 can be moved to a vendor-neutral location.

prusnak commented at 3:16 PM on February 1, 2016: contributor

@bgok So using our source code is OK, but contributing to our improvement proposals is not? You seem pretty inconsistent, to put it mildly. I am perfectly fine to accept any pull request that make sense. Coincidentally, I just extracted SLIPs to a separate repo, so one does not have to fork whole our documentation: https://github.com/satoshilabs/slips

That said, I share the view of @justusranvier. The whole reason of SLIPs existence is that is that we were unable to push informational proposals to BIPs because they were not strictly about Bitcoin.

bgok commented at 4:13 PM on February 1, 2016: none

@prusnak No inconsistancies, really. It's like if the RFP process were controlled entirely by Cisco. It would not be considered a vendor neutral process.

I appreciate that you moved SLIPS into a separate repository. I'll check with my management today to see how they feel about contributing a couple of standards we are working on.

luke-jr commented at 5:18 AM on February 24, 2016: member

So where does this stand? Shall I merge it as BIP 82, or hold off?

jonathancross commented at 8:21 PM on November 6, 2017: contributor

Hi All, It's been 20 months since this was last updated, would be nice to merge, update or close. Clearly there are bigger issues regarding how to handle BIP-43 purpose field proposals and how "bitcoin-focused" they must be. However it does not seem this is going to be solved anytime soon.

@gmaxwell Does your assignment of a BIP number mean that you believe this should be merged?
@justusranvier Would you be willing to submit this as a SLIP? It does resemble SLIP-48 in that it defines a new purpose field per BIP-43.

in bip-0082.mediawiki:40 in a2fcb5f82f

  35 | +
  36 | +Hardened derivation is used at this level.
  37 | +
  38 | +===Identity===
  39 | +
  40 | +Identity is used to derive different key groups for identity seperation.

rex4539 commented at 3:15 PM on April 3, 2019:

Typo: "seperation"

rex4539 changes_requested

in bip-0082.mediawiki:80 in a2fcb5f82f

  75 | +
  76 | +Public derivation is used at this level.
  77 | +
  78 | +==Compatible implementations==
  79 | +
  80 | +* [[https://github.com/monetas/bmd|bmd]] is the reference Bitmessage implementation which uses this specification

kallewoof commented at 2:43 PM on July 23, 2019:

Broken link.

in bip-0082.mediawiki:66 in a2fcb5f82f

  61 | +
  62 | +Public derivation is used at this level.
  63 | +
  64 | +====Encryption Keys====
  65 | +
  66 | +Bitmessage does not allow for arbitrary combinations of signing an encryption keys. In order to form a valid Bitmessage address, the keys must satisfy the condition that: <pre>ripemd160(sha512(concatenate(signing public key, encryption public key))</pre> contains a leading zero when the public keys are expressed in uncompressed X9.62 format.

kallewoof commented at 2:46 PM on July 23, 2019:

signing an_d_ encryption keys

kallewoof commented at 2:48 PM on July 23, 2019: member

Weak concept NACK. From reading the BIP and from reading the Bitmessage web site I am still not sure what this has to do with Bitcoin, aside from using some of the same cryptographic primitives.

Since it's been ~4 years since this PR was opened, I propose it is closed. If the author wishes to champion this BIP again, they should reopen a new PR and link to this one as a reference.

ysangkok commented at 5:53 PM on July 25, 2019: contributor

Yeah, why not close this? @luke-jr what could possibly happen to this BIP? Why leave the PR open, do you need @justusranvier to acknowledge closing the PR?

luke-jr closed this on Jul 26, 2019

ajtowns referenced this in commit 9194a7b582 on Dec 11, 2019