Re: New Work Item Proposal: Data Integrity BIP340 Cryptosuite

On Sun, Aug 3, 2025 at 2:39 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On Sun, Aug 3, 2025 at 2:28 PM Christopher Allen
> <ChristopherA@lifewithalacrity.com> wrote:
> > However, I believe that both Multikey and Multihash suffer from a
> significant architectural flaw: they bind type to encoding, violating
> proper layering principles.
>
> I don't think this is true?

…

> Can you see what I'm missing, Christopher? I'm definitely missing
> something, or your understanding of Multikey/Mulithash isn't correct.

Thanks, Manu — I appreciate the pushback.

What I may have been overlooking in my earlier comparison is that both
Bitcoin addresses and UR include integrity bytes — Bitcoin uses a
double-SHA256 checksum (Base58Check), and UR uses CRC. That kind of
integrity protection is definitely an important part of encoding design,
especially for identifiers.

That said, I still consider integrity checks to be part of the encoding
layer — some formats include them, others encoding formats don’t, but
either way, it’s a choice about serialization, not semantics.

Which brings me to a question that might clarify things:

In Multikey, does the integrity check (if any) cover the type prefix as
well, or only the raw key bytes?

If it covers the prefix, then the type and encoding are further entangled —
meaning any change in type affects both interpretation and the integrity of
the encoding. That’s the layering concern I’m trying to highlight.

Happy to be corrected if I’ve misunderstood how Multikey handles this.

— Christopher Allen

>