[bitcoin-dev] Proposed BIP for MuSig2 PSBT Fields

[bitcoin-dev] Proposed BIP for MuSig2 PSBT Fields

[Andrew Chow]

Hi All,

I've written up a BIP draft for MuSig2 PSBT fields. It can be viewed at 
https://github.com/achow101/bips/blob/musig2-psbt/bip-musig2-psbt.mediawiki.

This is based on this gist from Sanket: 
https://gist.github.com/sanket1729/4b525c6049f4d9e034d27368c49f28a6. 
There are a few notable differences:
- The participant pubkeys field is keyed by only the aggregate xonly key
- Participant pubkeys are compressed pubkeys rather than xonly.

Andrew

Re: [bitcoin-dev] Proposed BIP for MuSig2 PSBT Fields

[Anthony Towns]

On Tue, Oct 10, 2023 at 10:28:37PM +0000, Andrew Chow via bitcoin-dev wrote:
> I've written up a BIP draft for MuSig2 PSBT fields. It can be viewed at 
> https://github.com/achow101/bips/blob/musig2-psbt/bip-musig2-psbt.mediawiki.

I was hoping to see adaptor signature support in this; but it seems that's
also missing from BIP 327? Though libsecp256k1-zkp has implemented it:

 https://github.com/BlockstreamResearch/secp256k1-zkp/blob/master/include/secp256k1_musig.h
   (adaptor arg to process_nonce; adapt, and extract_adaptor functions)

 https://github.com/BlockstreamResearch/secp256k1-zkp/blob/master/src/modules/musig/musig.md#atomic-swaps

I would have expected the change here to support this to be:

  * an additional field to specify the adaptor, PSBT_IN_MUSIG2_PUB_ADAPTOR
    (optional, 33B compressed pubkey, 32B-hash-or-omitted), that signers
    have to take into account

  * an additional field to specify the adaptor secret,
    PSBT_IN_MUSIG2_PRIV_ADAPTOR (32B), added by a Signer role

  * PartialSigAgg should check if PUB_ADAPTOR is present, and if so,
    incorporate the value from PSBT_IN_MUSIG2_PRIV_ADAPTOR, failing if
    that isn't present

(Note that when using adaptor signatures, signers who don't know the
adaptor secret will want to ensure that the partial signatures provided by
signers who do/might know the secret are valid. But that depends on the
protocol, and isn't something that can be automated at the PSBT level,
I think)

Seems like it would be nice to have that specified asap, so that it can
be supported by all signers?

FWIW, "participant" is typoed a bunch ("particpant") and the tables are
hard to read: you might consider putting the description as a separate
row? eg:

 https://github.com/ajtowns/bips/blob/202310-table/bip-musig2-psbt.mediawiki 

Cheers,
aj

Re: [bitcoin-dev] Proposed BIP for MuSig2 PSBT Fields

[Andrew Chow]

On 10/11/2023 07:47 PM, Anthony Towns wrote:
> On Tue, Oct 10, 2023 at 10:28:37PM +0000, Andrew Chow via bitcoin-dev wrote:
>> I've written up a BIP draft for MuSig2 PSBT fields. It can be viewed at
>> https://github.com/achow101/bips/blob/musig2-psbt/bip-musig2-psbt.mediawiki.
> 
> I was hoping to see adaptor signature support in this; but it seems that's
> also missing from BIP 327?

This is the first time I've heard of that, so it wasn't something that I 
considered adding to the BIP. Really the goal was to just be able to use 
BIP 327.

But that doesn't preclude a future BIP that specifies how to use adaptor 
signatures and to have additional PSBT fields for it. It doesn't look 
like those are mutually exclusive in any way or that the fields that 
I've proposed wouldn't still work.

I don't know enough about the topic to really say much on whether or how 
such fields would work.

> FWIW, "participant" is typoed a bunch ("particpant")and the tables are
> hard to read: you might consider putting the description as a separate
> row? eg:
> 
>   https://github.com/ajtowns/bips/blob/202310-table/bip-musig2-psbt.mediawiki

Yes, I've been making some minor fixes throughout the day, and I'll 
probably take your suggestion for the tables. Mediawiki tables are the 
bane of my existence.

Andrew

Re: [bitcoin-dev] Proposed BIP for MuSig2 PSBT Fields

[Anthony Towns]

On Wed, Oct 11, 2023 at 11:59:16PM +0000, Andrew Chow via bitcoin-dev wrote:
> On 10/11/2023 07:47 PM, Anthony Towns wrote:
> > On Tue, Oct 10, 2023 at 10:28:37PM +0000, Andrew Chow via bitcoin-dev wrote:
> >> I've written up a BIP draft for MuSig2 PSBT fields. It can be viewed at
> >> https://github.com/achow101/bips/blob/musig2-psbt/bip-musig2-psbt.mediawiki.
> > 
> > I was hoping to see adaptor signature support in this; but it seems that's
> > also missing from BIP 327?
> This is the first time I've heard of that, so it wasn't something that I 
> considered adding to the BIP. Really the goal was to just be able to use 
> BIP 327.

Yeah, makes sense.

The other related thing is anti-exfil; libwally's protocol for that
(for ecdsa sigs) is described at:

 https://wally.readthedocs.io/en/release_0.8.9/anti_exfil_protocol/
 https://github.com/BlockstreamResearch/secp256k1-zkp/blob/master/include/secp256k1_ecdsa_s2c.h

Though that would probably want to have a PSBT_IN_S2C_DATA_COMMITMENT
item provided before MUSIG2_PUB_NONCE was filled in, then PSBT_IN_S2C_DATA
and PSBT_IN_NONCE_TWEAK can be provided. (Those all need to have specific
relationships in order to be secure though)

> But that doesn't preclude a future BIP that specifies how to use adaptor 
> signatures and to have additional PSBT fields for it. It doesn't look 
> like those are mutually exclusive in any way or that the fields that 
> I've proposed wouldn't still work.

Yeah, it's just that it would be nice if musig capable signers were also
capable of handling s2c/anti-exfil and tweaks/adaptor-sigs immediately,
rather than it being a "wait for the next release" thing...

> I don't know enough about the topic to really say much on whether or how 
> such fields would work.

I think for signers who otherwise don't care about these features, the
only difference is that you add the tweak to the musig nonces before
hashing/signing, which is pretty straightforward. So I think, if it were
specced, it'd be an easy win. Definitely shouldn't be a blocker though.

Here's another idea for formatting the tables fwiw:
https://github.com/ajtowns/bips/blob/d8a90cff616d6e5839748a1b2a50d32947f30850/bip-musig2-psbt.mediawiki

Cheers,
aj

Re: [bitcoin-dev] Proposed BIP for MuSig2 PSBT Fields

[Jonas Nick]

It is true that BIP 327 ("MuSig2") does not include adaptor signatures. The
rationale behind this decision was as follows:
- the BIP is already long and complicated enough without adaptor signatures; it
   should be possible to propose a separate adaptor signature BIP on top in a
   modular fashion
- as far as I know, there's no security proof except for a hard-to-follow sketch
   that I wrote a few years ago [0]
- at the time, there seemed to be a higher demand for single-signer adaptor
   signatures

In spite of the missing specification, we added some version of adaptor
signatures to the libsecp256k1-zkp MuSig2 module in order to allow
experimentation.

As for standardizing MuSig2 adaptor signatures, it seems noteworthy that there
exist alternative designs to the implementation in the libsecp256k1-zkp module:
the current libsecp256k1-zkp PR for (single-signer) Schnorr adaptor signatures
[1] uses a slightly different API. Instead of sending the adaptor point along
with the adaptor signature, the point is extracted from an adaptor signature.
This simplifies the API and reduces communication at the cost of making batch
verification of multiple adaptor sigs impossible.

[0] https://github.com/BlockstreamResearch/scriptless-scripts/pull/24
[1] https://github.com/BlockstreamResearch/secp256k1-zkp/pull/268