Re: New Work Item Proposal: Data Integrity BIP340 Cryptosuite

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.

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