Re: New Work Item Proposal: Data Integrity BIP340 Cryptosuite

ne 3. 8. 2025 v 17:18 odesílatel Will Abramson <wip.abramson@gmail.com>
napsal:

> This is an interesting thread. Thanks for raising your concerns.
>
> I am mostly responding to Melvin here, but definitely interested to learn
> more about Christopher and Jaromil's concerns over Multibase / Multikey.
>
> First, I appreciate your voice as someone deeper within the Bitcoin
> community than I am. I would say I understand the technical aspects of
> Bitcoin deeply, but not the accompanying discourse from within the Bitcoin
> world.
>
> I do understand that Bitcoin uses public keys encoded as hex as
> identifiers.
>
> As a minor sidebar: Your use of identity in your email threw me off all
> bit. I prefer to use the functional definition of identity developed by Joe
> Andrieu. Identity is how we recognise, remember and respond to people and
> things. I am reading your email as if you meant identifier, apologies if
> this interpretation is incorrect.
>
> Back to the cryptosuite spec. The spec is primarily about how you can
> produce Data Integrity proofs using BIP340 signatures over the secp256k1
> curve. Secondarily, it defines how you can encode the secp256k1 keys using
> Multikey so that they can be included in a verificationMethod. To me Data
> Integrity is not a Bitcoin native concept. I am trying to bridge the
> communities, to show how existing keys and signature algorithms can be used
> to produce this VC WG defined proofs. Note both DataI Integrity and
> Multikey have been standardized at the W3C by the VC WG.
>
> As I understand it, all that this spec is requiring of Bitcoin tooling and
> infrastructure is a minimal transformation of bytes. From one public key
> representation to another. I would like to understand more about why this
> is concerning for you Melvin.
>
> Absolutely we could, or rather, you could, create a verification method
> type representation that uses publicKeyBytes. Nothing in this spec
> precludes that from being possible.
>
> However, a challenge you will face is how do people outside of your
> community know what keys you are encoding. Multikey does this by prepending
> some bytes as a flag. Before the move to multikey there was a proliferation
> of verificationMethod types. One for each key being encoded. So this is
> certainly one way, it’s just a pain to manage I think.
>
> But you could define a new type, BitcoinHexKey for example. And define the
> encoding as hex. Then use these keys to create the same data integrity
> proofs as defined by the BIP340 Cryptosuite spec. If you want to do that
> work, go for it. I would be loosely supportive.
>
> The thing is implementations would have to understand and implement
> against this type. The libraries and tooling in the Bitcoin ecosystem will
> still have to do some work. Some manipulation of bytes at least to place
> these representations into the data structure of a DID document and
> verification method. Is that really much different than just using a
> Multikey? I would argue there is more work to do.
>
> If you define a new type, all other implementations that use DIDs and DID
> documents, or interface with them in some way, need to also decide if they
> will support this type or not. If they don’t we don’t have interop.
> Whereas, Multikey is already defined and has been standardised by the VC
> WG.
>
> Help me understand what I am missing here?
>
> Jaromil, I would also like to know more about your perspective. To me,
> Multikey is just a way of encapsulating the bytes representing a key so
> they can be resolved and consistently understood within DID documents
> across multiple implementations. It is about creating an interface between
> your internal system and the external world. As soon as you ingest that
> key, you can transform it to whatever format or representation that suits
> your internal system best.
>
> Hope that clarifies where we are coming from with this spec. It just
> extends and builds on the Data Integrity work to add BIP340 signatures. It
> defines a way to represent the necessary keys (Multikey) but does not
> prevent any alternative representations of those keys being developed.
> Someone just has to do that work.
>
> I look forward to your responses.
>

Thanks for the detailed discussion. One practical data-point explains why
raw-hex matters.

1. W3C Nostr CG already has a DID method using raw hex

The W3C Nostr Community Group maintains the draft DID method did:nostr:

( https://github.com/nostrcg/did-nostr ).

That draft – and several running wallets and relays – use the exact 64-char
lowercase BIP-340 pubkey as the identifier:

did:nostr:abcd...

If the BIP-340 Data-Integrity draft mandates Multikey, we will have two
W3C drafts for the same key that cannot talk to each other.

- DID method -  did:nostr: (CG draft) -  raw hex
- Data-Integrity proof suite - BIP-340 draft - Multikey

2. Scale and Network Effect

Tens of millions of keys are already published in hex across Bitcoin and
Nostr.  Nostr itself has millions of users

Those strings show up in DBs, QR codes, invoices, message IDs, etc.

Multibase/Multikey is great when the curve is unknown, but here the curve
is fixed: secp256k1 BIP-340.

A new prefix silently breaks byte-for-byte matches and forces every
existing tool to add prefix-stripping code.

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

- Verifiers MUST accept either encoding.
- Signers pick whichever matches their stack.
- No ecosystem fork; immediate interoperability.

Or some commitment like this.

4. Two specs are already forming, in different W3C CGs

We already have at least two developers eager to add VC support to the
did:nostr BIP-340 method. If raw-hex is not recognised in the
Data-Integrity draft, we will almost certainly end up with two specs, one
in the VC WG and one in the Nostr CG – describing the same keys in
incompatible ways. That seems avoidable.

Thanks again for engaging. Looking forward to finding a compromise that
works for everyone.

Best,
Melvin


>
> Best,
> Will
>
> On Sun, Aug 3, 2025 at 3:22 PM Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> ne 3. 8. 2025 v 16:12 odesílatel Filip Kolarik <filip26@gmail.com>
>> napsal:
>>
>>> Hi Melvin, Jaromil,
>>> Thanks for sharing your thoughts on the use of Multibase and Multikey in
>>> identity infrastructure. While I understand your concerns about
>>> compatibility with existing ecosystems, I believe some of your objections
>>> overlook the broader goals of interoperability and standardization.
>>>
>>> Using raw hex as a primary identifier might work in isolated ecosystems
>>> like Bitcoin or Nostr, but it breaks down at the interoperability layer.
>>> Hex strings lack essential metadata, there’s no way to determine curve type
>>> and encoding format. That ambiguity is exactly why Multibase and Multikey
>>> exist. It’s not rational to claim that encoding prefixes fragment
>>> ecosystems when the opposite is true: they enable different systems to
>>> understand each other. Multibase and Multikey unify representations by
>>> explicitly declaring what they are, avoiding implicit assumptions about
>>> curve types or encoding formats.
>>>
>>> Manu already outlined a very clear and simple migration strategy:
>>> prepend a deterministic header to existing keys. This doesn’t “break”
>>> existing systems; it simply adds a tiny layer of semantic clarity. You can
>>> strip the prefix if needed locally. But rejecting that entirely because
>>> it's not exactly the same character-for-character string ignores the
>>> realities.
>>>
>>> Saying "we must preserve raw hex or nothing works" suggests an
>>> unwillingness to adapt even when a backward-compatible pathway is provided.
>>> That’s not a sustainable or forward-looking position in a multi-protocol
>>> internet.
>>>
>>> Jaromil, add your point about making prefixes optional and criticizing
>>> prefix semantics. Optionality leads to ambiguity. Ambiguity breaks
>>> deterministic parsing. You mention that Zenroom defines encoding elsewhere,
>>> great, but the rest of the ecosystem can’t be expected to hardcode
>>> per-library assumptions. That’s exactly what standardized, self-describing
>>> encoding solves.
>>>
>>
>> Key point: BIP-340 already runs at Bitcoin scale, tens of millions of
>> keys, countless wallets, nodes, and apps, all using raw-hex Taproot pubkeys
>> as the canonical identifier. Multibase/Multikey comes from a much smaller
>> IPFS niche. By hard-wiring that encoding into a “BIP-340” spec, we’re
>> effectively forking the real-world standard instead of documenting it. The
>> spec must first accept the deployed Bitcoin representation; otherwise we
>> split one ecosystem into two incompatible identity layers.
>>
>>
>>>
>>> Best,
>>> Filip
>>> https://github.com/filip26
>>>
>>>
>>> On Sun, Aug 3, 2025 at 9:51 AM Jaromil <jaromil@dyne.org> wrote:
>>>
>>>>
>>>> I second Mervin's concerns about multibase and multikey. The imposed
>>>> use of encoding identifiers is really awkward both for systems that have
>>>> settled their format, as well systems like Zenroom where the encoding is
>>>> specified elsewhere.
>>>>
>>>> It would really make sense to make it optional all across the
>>>> ecosystem. Most important, all multi* encodings should have a way to
>>>> deterministally signal themselves: right now they mix their own prefix with
>>>> raw encodings, which I consider a design flaw.
>>>>
>>>> ciao
>>>>
>>>>
>>>>