Re: New Work Item Proposal: Data Integrity BIP340 Cryptosuite

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