Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HD derivation of Bitmessage addresses #171

Open
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
7 participants
@justusranvier
Copy link
Contributor

justusranvier commented Jul 10, 2015

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.

justusranvier added some commits Jun 25, 2015

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.
@luke-jr

This comment has been minimized.

Copy link
Member

luke-jr commented Sep 3, 2015

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

@gmaxwell

This comment has been minimized.

Copy link
Member

gmaxwell commented Sep 3, 2015

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

@justusranvier

This comment has been minimized.

Copy link
Contributor Author

justusranvier commented Sep 3, 2015

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 luke-jr added the New BIP label Oct 23, 2015

@luke-jr

This comment has been minimized.

Copy link
Member

luke-jr commented Jan 8, 2016

@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

This comment has been minimized.

Copy link

bgok commented Jan 8, 2016

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

@luke-jr

This comment has been minimized.

Copy link
Member

luke-jr commented Jan 8, 2016

@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

This comment has been minimized.

Copy link
Member

luke-jr commented Jan 8, 2016

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

@bgok

This comment has been minimized.

Copy link

bgok commented Jan 8, 2016

@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

This comment has been minimized.

Copy link
Contributor Author

justusranvier commented Jan 8, 2016

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

This comment has been minimized.

Copy link
Member

luke-jr commented Jan 8, 2016

@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

This comment has been minimized.

Copy link

bgok commented Jan 8, 2016

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

This comment has been minimized.

Copy link
Contributor Author

justusranvier commented Jan 8, 2016

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

This comment has been minimized.

Copy link
Member

luke-jr commented Jan 8, 2016

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

This comment has been minimized.

Copy link
Contributor

prusnak commented Feb 1, 2016

@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

This comment has been minimized.

Copy link

bgok commented Feb 1, 2016

@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

This comment has been minimized.

Copy link
Member

luke-jr commented Feb 24, 2016

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

@jonathancross

This comment has been minimized.

Copy link
Contributor

jonathancross commented Nov 6, 2017

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.

  1. @gmaxwell Does your assignment of a BIP number mean that you believe this should be merged?
  2. @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.

===Identity===

Identity is used to derive different key groups for identity seperation.

This comment has been minimized.

Copy link
@rex4539

rex4539 Apr 3, 2019

Typo: "seperation"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.