* [bitcoin-dev] Proposed BIP for MuSig2 PSBT Fields
@ 2023-10-10 22:28 Andrew Chow
2023-10-11 23:47 ` Anthony Towns
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Chow @ 2023-10-10 22:28 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Proposed BIP for MuSig2 PSBT Fields
2023-10-10 22:28 [bitcoin-dev] Proposed BIP for MuSig2 PSBT Fields Andrew Chow
@ 2023-10-11 23:47 ` Anthony Towns
2023-10-11 23:59 ` Andrew Chow
2023-10-12 7:43 ` Jonas Nick
0 siblings, 2 replies; 5+ messages in thread
From: Anthony Towns @ 2023-10-11 23:47 UTC (permalink / raw)
To: Andrew Chow, Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Proposed BIP for MuSig2 PSBT Fields
2023-10-11 23:47 ` Anthony Towns
@ 2023-10-11 23:59 ` Andrew Chow
2023-10-12 7:39 ` Anthony Towns
2023-10-12 7:43 ` Jonas Nick
1 sibling, 1 reply; 5+ messages in thread
From: Andrew Chow @ 2023-10-11 23:59 UTC (permalink / raw)
To: Anthony Towns, Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Proposed BIP for MuSig2 PSBT Fields
2023-10-11 23:59 ` Andrew Chow
@ 2023-10-12 7:39 ` Anthony Towns
0 siblings, 0 replies; 5+ messages in thread
From: Anthony Towns @ 2023-10-12 7:39 UTC (permalink / raw)
To: Andrew Chow, Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Proposed BIP for MuSig2 PSBT Fields
2023-10-11 23:47 ` Anthony Towns
2023-10-11 23:59 ` Andrew Chow
@ 2023-10-12 7:43 ` Jonas Nick
1 sibling, 0 replies; 5+ messages in thread
From: Jonas Nick @ 2023-10-12 7:43 UTC (permalink / raw)
To: Anthony Towns, Bitcoin Protocol Discussion, Andrew Chow
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-10-12 7:43 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-10 22:28 [bitcoin-dev] Proposed BIP for MuSig2 PSBT Fields Andrew Chow
2023-10-11 23:47 ` Anthony Towns
2023-10-11 23:59 ` Andrew Chow
2023-10-12 7:39 ` Anthony Towns
2023-10-12 7:43 ` Jonas Nick
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox