Re: Draft Schnorr Secp256k1 Cryptosuite for Data Integrity

Very cool Will and team!

I had been wondering if anyone was looking into this as it was on my own
todo list. One thing I had been pondering was if it would be possible
to leverage BIP 322 as there are already so many Bitcoin wallets capable of
signing messages in that manner. I haven't spent any brain power looking
into it but my hunch is it isn't possible. Maybe someone on the list knows
more of the details than me and can reassure me that it's a dead end?

I'm still working on the Bitcoin Ordinals DID method I presented to the
group in 2023.. In fact I have updated the method a little bit to match
some of the DID Linked resources concepts I've been working on as a part of
DIF Labs. I would love to have bitcoin-crypto-only available as an option
within did:btco.

You can find more about my Ordinals work at https://ordinals.plus where you
can watch the DIF presentation.

+1 to CCG adoption of the work item. I'd love to be involved.

Thanks,
Brian

On Wed, Feb 19, 2025 at 6:02 PM Bryan Newbold <bryan@blueskyweb.xyz> wrote:

> On Wed, Feb 19, 2025 at 12:16 PM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
> >
> > On Wed, Feb 19, 2025 at 10:07 AM Will Abramson <wip.abramson@gmail.com>
> wrote:
> > > Is a draft of a Cryptosuite for producing Data Integrity proofs using
> Schnorr signatures with Secp256k1 keys according to the latest proposed
> recommendations from the VCDM.
> >
> > That's awesome, Will! It'll be nice to standardize a non-ECDSA /
> > Schnorr signature scheme.
>
> This all sounds good, and I'm supportive of this Schnorr Secp256k1 draft!
>
> Just to side-note for awareness, we use secp256k1 (along with
> secp256r1), with ECDSA, in both atproto and DID PLC. We use Multikey
> encoding for public keys. We do not restrict to "x-only" keys. For
> secp256k1 we use the 0xE7 code ([0xE7, 0x01] as a varint) in the
> Multikey encoding. We don't currently encode proofs (signatures) in
> DataIntegrityProof format anywhere in those systems.
>
> The signature/proof in DataIntegrityProof format in this proposed
> draft (data-integrity-schnorr-secp256k1) differentiates the signature
> type, so I don't think there would be room for confusion in the wild.
>
> > > One aspect of the spec that is worth drawing attention to is our
> definition of the secp256k1 x-only Multikey prefix -
> https://dcdpr.github.io/data-integrity-schnorr-secp256k1/#multikey.
> Should this be registered somewhere else?  From the CID spec, it states
> anyone can define their own Multikey prefix so I figured this would be
> okay. But clearly we wouldn't want other keys to also use the same value
> >
> > Yes, the spec can define its own Multikey prefix, and my hope is that
> > we split the Multiformats stuff out of the CID spec eventually. I'll
> > note that the secp256k1 pubkey value is 0xe7 (don't know what the
> > varint encoding is off of the top of my head):
> >
> > https://github.com/multiformats/multicodec/blob/master/table.csv#L93
> >
> > ... so you'll want to use that instead of the one you have in the spec,
> IIUC.
>
> I'm not an expert in this area, but if the fact that the keys are
> "x-only" is meaningful, it might be good to use a distinct prefix?
>
> I think you can submit a PR against the repository Manu linked to
> (github.com/multiformats/multicodec), to register it there. Though I
> don't think that is currently part of any formal or recognized SDO
> process.
>
> --bryan
>
>