Re: Draft Schnorr Secp256k1 Cryptosuite for Data Integrity

Thanks Brian,

We would love to have you involved.

Actually, I think I can reassure you that BIP322 signatures would very much
be possible as a mechanism to secure a Data Integrity proof. A while back I
did some exploratory research in this direction for DCD, although we
eventually decided it wasn't necessary for the DID method we were working
on. However, I still think it is a very interesting example of why
verificationMethod is a better name than the older publicKey.

You can find my exploration here:
https://github.com/LegReq/bip0322-signatures

These two are good walkthroughs of BIP322

-
https://github.com/LegReq/bip0322-signatures/blob/master/BIP0322_signing.ipynb
-
https://github.com/LegReq/bip0322-signatures/blob/master/BIP0322_verification.ipynb

Then under this folder -
https://github.com/LegReq/bip0322-signatures/tree/master/vc - I have a very
initial draft of a spec and some notebooks that use BIP322 to sign and
verify a VC.

Some work would be required to turn this into a proper specification, but
it is certainly possible. We just got distracted by other things.

The main difference this specification would require is, I think, a new
verificationMethod type. Which I tentatively called
"BIP322VerificationAddress2022".
Not sure if this could now follow a Multikey pattern, it would feel a bit
odd since a bitcoin address is not a public key.

I would be happy to collaborate with you to turn this into a compatible
Data Integrity Cryptosuite. Now I am much more familiar with the process, I
don't think it would be that difficult.

Thanks,
Will


On Thu, Feb 20, 2025 at 5:01 AM Brian Richter <brian@aviary.tech> wrote:

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