Re: New Work Item Proposal: Data Integrity BIP340 Cryptosuite

Yes to everything Filip said; he's exactly right when it comes to why
raw hex is typically a bad idea at scale (and by "scale", I mean
billions of keys across many communities, not a couple of tens of
millions of keys within a single community).

When some communities think of key formats, they (unfortunately) tend
to only think of their small part of the world rather than the larger
ecosystem in which their system fits. Sure, hex-encoding is easy when
you only have one key format to think of in your ecosystem, but
Multikey is building for an ecosystem that's much larger than nostr
(it's building for strong typing of every possible key type). Multikey
focuses on cross-community interop, not single-community interop.

I'm also thoroughly confused by the "we must use hex encoding"
suggestion because I thought nostr didn't only use hex, but uses
Bech32 via NIP-19 (the npub/nsec stuff)? So, nostr has at least two
different encodings, why not Bech32? ... and let's not forget Bitcoin
uses base58btc, why not that since secp256k1 is "shared" with that
community as well?

In any case, I don't find the arguments for "this is the way keys are
expressed in our community and we MUST follow that format" very
compelling when trying to bridge into new communities, which was one
of Will's stated goals. Hex-only raw keys completely ignores interop
between communities and is shortsighted, IMHO.

On Sun, Aug 3, 2025 at 12:39 PM Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
> 3. Minimal Path to Interop
> Keep Multikey and add a sibling encoding that mirrors the DID draft:
>
> {
>   "type": "publicKeyHex", // name bikesheddable :)
>   "curve": "secp256k1",
>   "publicKeyHex": "abcd..."
> }

We went down this path before with secp256k1 keys and no one used
them. publicKeyHex is an anti-pattern because the publicKeyHex bytes
can't be interpreted without also interpreting the type and curve
properties. At that point, you're dealing with a multi-property object
that 1) is no longer compact, 2) has to have normalization rules
defined in order to be used as an identifier, and 3) cannot be
interpreted without storing/using all three properties.

Some of the benefits of Multibase-encoded Multikeys is not having to
deal with those three issues.

> - Verifiers MUST accept either encoding.

This is a standardization failure -- the statement is effectively
saying: "We're not going to pick something because we don't want to
deal with the inconvenience of a 5 byte header."

So, instead of adding a single line of code to our libraries, we are
now having to support TWO entirely new key formats (more than a single
line of code, especially for the corner cases as explained below).

> - Signers pick whichever matches their stack.

Don't forget that you're going to have to have rules in the spec and
tests defined for when the two key formats don't match up. :) -- this
is a well known vector for implementation bugs that could be
catastrophic (wrong key picked for a particular operation).

> - No ecosystem fork; immediate interoperability.

The suggestion will create an ecosystem fork -- there will be two key
formats. :)

I say all of the above fully expecting some ugly compromise to happen,
like what you suggested in your "Minimal Path to Interop" section. The
suggestion above is the easiest to achieve (because it avoids making
the hard choice), and feels like non-trivial effort to effectively get
to a key format that doesn't have a static 5-byte header on it.

That said, I don't have a strong opinion on secp256k1 since we can't
use it with any of our large scale customers (they demand
FIPS-compliant curves). So just take my input as an observation of a
path I've seen us go down before, that didn't work out well, but
shouldn't be seen as blocking in any way. Get to consensus however you
can, even if the solution is imperfect.

-- manu

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

Received on Sunday, 3 August 2025 18:08:17 UTC