Anyone know if there is a safe (and better yet, agreed upon) way to do derived keys starting from a keypair instead of a master seed value?

Reply to this note

Please Login to reply.

Discussion

Isn't there an HD wallet BIP with that sort of thing?

Yes, but all the implementations I've seen start from the seed (whether generated or mnemonic). I want to start from an already existing keypair (like a nostr keypair) and then derive from there. I'm wondering if there is an agreed upon want to get the chaincode needed to start deriving.

Perhaps you are the first. Write the spec :) that's how we ended up with these BIPs. Trezor needed it, do they submitted the BIP.

Reading the "Extended Keys" from BIP32 and it sounds like you can add the chaincode to that keypair to use it as the seed.

Doable by getting down to point primitives maybe? Like take an nsec and boil down to a point on secp, then HD keys from there?

Ah. Implementations.

You'll probably have to parse out the keys and write a function to mush (technical term) into a "master" key.

Sorry what's a derived key. Not sure your question makes sense.

You can hash any input of bits and use that as a key, whether the bits are words or not.

Basically I'm trying to do BIP-32 but start from a keypair instead of a seed. In order to make it work across multiple clients I'd need to have some sort of standard way of coming up with a chaincode when you're not deriving that from the seed directly.

Not sure I understand all of this: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#user-content-Specification_Key_derivation

But like I said "deriving" a key usually means computing a hash on some string of bits and then just use that as the private key more or less directly. In BIP 32 the input bits are just the private (parent) key.