Deterministic pay to public key generation

[lescuer97]

Adds a standard way to generate keys for wallets to generate private keys for usage in P2PK operations.

• cdk P2pk receive wallet cdk#1466
• coco feat: follow deterministic derivation spec coco#68
• macadamia

[a1denvalu3]

is this using BIP32? Should be more clear.

[lescuer97]

yes, I'll make it clearer

[a1denvalu3]

`m/129372'/10'/0'/0'/{counter}`:

not using per-keyset derivation. are we sure about this?

[lescuer97]

yes, because it's for locking up proofs it should be more general

[robwoodgate]

Keysets v2 is moving away from a BIP32 style derivation scheme, and using a KDF instead. Would it not be better to align with this approach, eg using a domain separator like b"Cashu_KDF_HMAC_SHA256_P2PK" or b"Cashu_P2PK_v1"?

Also, I assume the counter is separate to the one used for secrets/blinded messages. If so, this should be made clearer.

Finally, related to @a1denvalu3's comment - what happens if the derived key is out of range? Should it be discarded (as per BIP-32) or reduced modulo N?

[prusnak]

Keysets v2 is moving away from a BIP32 style derivation scheme, and using a KDF instead. Would it not be better to align with this approach, eg using a domain separator like b"Cashu_KDF_HMAC_SHA256_P2PK" or b"Cashu_P2PK_v1"?

Good point 👍

[lescuer97]

@robwoodgate @a1denvalu3 just changed the wording around the NUT so it's a bit more clear.

[robwoodgate]

Suggestion to tighten language, otherwise concept ACK

[robwoodgate]

Suggested change

	This will allow wallets to swap proof that are still locked to a public key during a restore process.
	Wallets can deterministically generate private keys for P2PK using the following BIP32 derivation path:
	`m/129372'/10'/0'/0'/{counter}`
	Where:
	- Purpose' = `129372'` (UTF-8 for 🥜)
	- Coin type' = `10'` - reserved for generating private keys.
	- `{counter}` is an Incrementing counter, encoded as an unsigned 64-bit integer in big-endian format.
	This allows wallets to swap Proofs still locked to a corresponding public key during a restore process.
	In line with BIP-32, if the resulting private key is out of range (`> N`), it should be discarded.

[prusnak]

Can you explain why the last element is not hardened?

Is the xpub of m/129372'/10'/0'/0' ever shared anywhere?

If it is not shared, then instead of hardening it, I propose we change the scheme to Cashu_KDF_HMAC_SHA256 (same as used in Keyset v2, since BIP32 used in Keyset v1 is deprecated).

[lescuer97]

We are following what Bitcoin does when it comes to key derivation for locking.

there is no reason right now for sharing an XPUB but can't guarantee that in the future.

The reason we want to use bip32 is because Bip32 is specifically made for this case.The Cashu_KDF_HMAC_SHA256 scheme is used because of aggregation to avoid certain issues when generating the keyset id.

This keys are never aggregated and are use individually.

[prusnak]

The reason we want to use bip32 is because Bip32 is specifically made for this case.

No, it's not. BIP32 usecase is when you need to share a pubkey for a certain key subtree. Unless you need this requirement, going with Cashu_KDF_HMAC_SHA256 is simply faster and easier.

[Egge21M]

@prusnak if we get the option to query the mint for quotes connected to a pubkey via NUT-20, public key derivation would become more meaningful than it currently is. I can not think of a usecase right now, but with this, extended keys would be able to essentially create a watch-only wallet of a wallets quotes, without spending from it.

So either we think about proper usecases for this for 2 weeks and go with HMAC if we can't find any, or we take the performance L, go with BIP32 and hope someone finds a usecase some day in the future

[prusnak]

if we want to have a watch-only wallet eventually which should show p2pk tokens too, this seems like a good use-case. ACK