Re: New Work Item Proposal: Data Integrity BIP340 Cryptosuite

so 2. 8. 2025 v 21:24 odesílatel Manu Sporny <msporny@digitalbazaar.com>
napsal:

> On Sat, Aug 2, 2025 at 2:23 PM Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
> > If there’s a path to accommodate this (e.g., via a publicKeyHex field or
> alternate verification method type), I’d be happy to support and
> contribute. But pushing existing infrastructure to adopt a new encoding
> format unilaterally, especially without a clear migration strategy, feels
> like a misstep.
>
> The Multibase header for lowercase hex is: *f*
>
> The Multikey header for a secp256k1 256-bit public key is: *e701*
>
> An example of a random secp256k1 256-bit public key is:
>
> 03d0857e7d01daf430a13b1b054d4c4179367704e567333fd70deb29e0d5413f72
>
> Therefore, the Multibase encoding of the Multikey value is:
>
> *f**e701*
> 03d0857e7d01daf430a13b1b054d4c4179367704e567333fd70deb29e0d5413f72
>
> You will notice that the hex value following the header bytes (*f**e701*)
> is kept as-is, which seems to address your concern, Melvin. Translating
> to/from this format is a matter of adding a 5-byte (*f**e701*) header, or
> removing it, which seems like a workable "migration strategy".
>
> Am I missing something?
>

Thanks Manu, I appreciate the clarification on how Multibase + Multikey is
constructed in hex.

However, I think we're talking past each other a bit. The concern isn't
about the mechanics of encoding or decoding—it’s about the existing,
widely-deployed identity format used across the Bitcoin and Nostr
ecosystems.

In those ecosystems, public keys are canonical identifiers, already in use
as lower-case hex strings (e.g., 03d0857e...). These are not abstract
encodings, they’re stable URIs, database keys, message authors, resource
anchors, and more. Changing that format, even slightly (by prepending fe701
or switching to multibase), would create an incompatible identity layer,
fragmenting implementations and requiring deep rewrites across tooling and
protocols.

If we’re aiming to reuse existing cryptographic primitives like BIP340
Schnorr signatures (great!) but we also need to respect and align with the
identity representations already tied to those primitives. Otherwise, we
end up duplicating ecosystems rather than bridging them.

So the request is not just for a migration strategy, it’s for supporting
raw hex as a first-class identity representation, not as something to be
"wrapped" or “normalized away.”

Happy to work on specific language if there's interest in making that
possible.

P.S. Also happy to discuss this further off-list as well, this has been a
longstanding point of incompatibility. If we can find a workable
compromise, I believe it would significantly strengthen the network effects
of both ecosystems, rather than continuing along parallel,
non-interoperable paths as we’ve seen so far.


>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>