HD derivation of Bitmessage addresses #171
Conversation
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.
|
Bitmessage is not Bitcoin. Did the editor really assign this BIP 82? |
|
I did assign 82 here. Can you take discussion to the list? |
|
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. |
|
@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. |
|
@luke-jr I have a few other proposals regarding BIP32 hierarchy. Not all are specifically bitcoin. Should I submit them here? |
|
@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). |
|
See SatoshiLabs Improvement Proposals for altcoin-related things: https://doc.satoshilabs.com/slips/ |
|
@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. |
|
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. |
|
@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. |
|
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? |
|
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. |
|
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. |
|
@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. |
|
@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. |
|
So where does this stand? Shall I merge it as BIP 82, or hold off? |
|
Hi All, It's been 20 months since this was last updated, would be nice to merge, update or close.
|
|
|
||
| ===Identity=== | ||
|
|
||
| Identity is used to derive different key groups for identity seperation. |
There was a problem hiding this comment.
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.
|
|
||
| ==Compatible implementations== | ||
|
|
||
| * [[https://github.com/monetas/bmd|bmd]] is the reference Bitmessage implementation which uses this specification |
|
|
||
| ====Encryption Keys==== | ||
|
|
||
| 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. |
There was a problem hiding this comment.
signing an_d_ encryption keys
|
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? |
Clarify bip-taproot digest difference to bip143 regarding sub-hashes
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.