Corect me if I’m wrong … but NOW I see a few major differences in these two “key management” schemes : FROST vs BIP32 … 1: “sub key” derivation via FROST (called “shares”) can be initialized (once or multiple times) from a users EXISTING npub, providing forward compatibility for existing pubkeys to act as “main identities”. BIP32 (afaikt) must generate a fresh xpub as the “main identity”, excluding existing npubs from reaping the benefits? 2: FROST handles a variety of “multisig” scenarios OOTB, allowing increased security if end users desire it. Implementing BIP32 alone would not provide multisig functionality? 3: FROST libraries are currently in development and ready to be implemented in Nostr clients. BIP32 is not? OTHERWISE … - both solve for “disposable” pubkeys which are cryptographically linked to a “main identity” pubkey. - both require additional implementation by signers and native clients. - both require a “connected” signer or native client to request the “main identity” pubkey from some remote service. Forgive my ignorance as I wrap my head around this very real need. Have I missed anything? @npub1s9et...lxzl https://www.frostr.org/