Re: New Work Item Proposal: Data Integrity BIP340 Cryptosuite

ne 3. 8. 2025 v 20:10 odesílatel Manu Sporny <msporny@digitalbazaar.com>
napsal:

> 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.
>

Canonical URIs, In Bitcoin, Taproot and in Nostr the literal hex string is
baked into PSBT files, BOLT11 invoices, NIP-05 records, relay filters, etc.
Those identifiers are already on hardware wallets, NFC cards, QR codes, and
in merchant POS systems.

Bech32/npub is display-only, NIP-19 states npub/nsec are human-friendly
wrappers; the underlying canonical identifier is still the 32-byte pubkey
in lowercase hex. All programmatic matching is done on that value.

Base58 (Bitcoin addresses) isn’t helpful here: addresses are hash160 +
version byte, not the pubkey itself. For credentials we need the actual
BIP-340 key.

So we’re not talking about “nostr’s favorite format”; we’re talking about
avoiding a character-level mismatch between DID URIs and proof verification.


>
> 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.
>

Hex keys are used all over the place and are a good idea for interop.  They
are canonical in nostr.  And scale perfectly to billions (or trillions)
with did:nostr.  We certainly have in mind IoT and Agents in our future
ecosystem.  Our main aim is deploying this technology at scale to 10s of
millions of users, which has different considerations (e.g. spam,
throughput, web of trust, privacy).

We want single-key provenance: one public key, one decentralized
identifier, one proof suite.

Re-encoding the key for proofs means the DID layer (did:nostr:abcd…) and
the Proof layer (zfe70102aa…) no longer match lexicographically; simple
lookups break.


>
> > - 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.
>

I see two viable outcomes:

1. Compatibility path: The DI cryptosuite accepts raw-hex secp256k1 keys as
an alternative encoding (verifiers translate to Multikey in-memory). One
ecosystem, one key, one proof suite.

2. Parallel path: The DI cryptosuite remains Multikey-only; the Nostr CG
will publish a separate VC profile that uses the identifiers already
deployed in Bitcoin/Nostr. Two specs, two communities, limited overlap.

Either outcome is workable. Modern tooling can keep the specs in sync, but
the real question is how much interoperability we want versus how much
duplication of effort we’re willing to tolerate.

The Nostr CG will do the work regardless and will reuse whatever we can. It
would simply be nicer, both for implementers and for W3C cohesion, if we
could land on the compatibility path and share the effort.  That could help
developers of both eco systems, down the road.


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