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
>

Just to add a bit of nuance: in Taproot, keys typically start with 02, not
03, which matters for Schnorr and protocols like FROST. Small differences
like this break libraries and clients in practice.

What’s missing is a way to represent the identities already in wide use,
raw hex, as-is. In some systems, public keys are used as URIs or anchors,
where character-for-character equivalence is required. Without support for
that, we likely end up with two parallel identity systems built on the same
keys, which is unfortunate.


>
> 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?
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>