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