bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-10-27 14:09:10 +00:00
Code Issues Releases Wiki Activity

bip373: add hyperlinks to other BIPs (#1886)

Browse Source 
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
This commit is contained in:
Guro 2025-07-03 19:46:18 +02:00 committed by GitHub
parent 36618d1c3c
commit fd1955694b
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 10 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
bip-0373.mediawiki
View File

@ -15,8 +15,8 @@
===Abstract===
This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2 that allow for BIP
327 MuSig2 Multi-Signature data to be included in a PSBT of any version. These will be fields for
This document proposes additional fields for [[bip-0174.mediawiki|BIP 174]] PSBTv0 and [[bip-0370.mediawiki|BIP 370]] PSBTv2 that allow for
[[bip-0327.mediawiki|BIP 327]] MuSig2 Multi-Signature data to be included in a PSBT of any version. These will be fields for
the participants' keys, the public nonces, and the partial signatures produced with MuSig2.
===Copyright===
@ -25,7 +25,7 @@ This BIP is licensed under the Creative Commons CC0 1.0 Universal license.
===Motivation===
BIP 327 specifies a way to create BIP 340 compatible public keys and signatures using the MuSig2
[[bip-0327.mediawiki|BIP 327]] specifies a way to create [[bip-0340.mediawiki|BIP 340]] compatible public keys and signatures using the MuSig2
Multi-Signature scheme. The existing PSBT fields are unable to support MuSig2 as it introduces new
concepts and additional rounds of communication. Therefore new fields must be defined to allow PSBTs
to carry the information necessary to produce a valid signature with MuSig2.
@ -52,7 +52,8 @@ The new per-input types are defined as follows:
| rowspan="2"| 0, 2
|-
| The MuSig2 aggregate public key (compressed) <ref>'''Why the compressed aggregate public key instead of x-only?'''
BIP 32 public keys can be derived from a BIP 327 MuSig2 aggregate public key (see: [[bip-0328.mediawiki|BIP 328]]).
[[bip-0032.mediawiki|BIP 32]] public keys can be derived from a [[bip-0327.mediawiki|BIP 327]] MuSig2 aggregate public key
(see: [[bip-0328.mediawiki|BIP 328]]).But since BIP 32 requires public keys to include their evenness byte, [[bip-0327.mediawiki|BIP 327]] MuSig2 aggregate public key (see: [[bip-0328.mediawiki|BIP 328]]).
But since BIP 32 requires public keys to include their evenness byte, BIP 327 MuSig2 aggregate public keys must
include their evenness byte as well. Furthermore, PSBT_IN_TAP_BIP32_DERIVATION fields include fingerprints to identify
master keys, and these fingerprints require the y-coordinate of the public key, so x-only serialization can't be used.
@ -74,7 +75,7 @@ required for aggregation. If sorting was done, then the keys must be in the sort
| rowspan="2"| 0, 2
|-
| The compressed public key of the participant providing this nonce, followed by the compressed aggregate public
key the participant is providing the nonce for, followed by the BIP 341 tapleaf hash of
key the participant is providing the nonce for, followed by the [[bip-0341.mediawiki|BIP 341]] tapleaf hash of
the Taproot leaf script that will be signed. If the aggregate key is the Taproot internal key or the
Taproot output key, then the tapleaf hash must be omitted. The compressed participant public key must be
the Taproot output key or found in a script. It is not the internal key nor the aggregate public key that
@ -90,7 +91,7 @@ it was derived from, if it was derived from an aggregate key.
| rowspan="2"| 0, 2
|-
| The compressed public key of the participant providing this partial signature, followed by the
compressed public key the participant is providing the signature for, followed by the BIP 341 tapleaf hash
compressed public key the participant is providing the signature for, followed by the [[bip-0341.mediawiki|BIP 341]] tapleaf hash
of the Taproot leaf script that will be signed. If the aggregate key is the Taproot internal key or
the Taproot output key, then the tapleaf hash must be omitted. Note that the compressed participant public key must be
the Taproot output key or found in a script. It is not the internal key nor the aggregate public key that
@ -162,7 +163,7 @@ to produce a signature for, if the signer does not find an existing
the <tt>NonceGen</tt> algorithm (or one of its variations) to produce a public
nonce that is added in a <tt>PSBT_IN_MUSIG2_PUB_NONCE</tt> field. However
signers must keep in mind that '''improper nonce usage can compromise private
keys.''' Please see BIP 327 for best practices on nonce generation and usage.
keys.''' Please see [[bip-0327.mediawiki|BIP 327]] for best practices on nonce generation and usage.
Once all signers have added their <tt>PSBT_IN_MUSIG2_PUB_NONCE</tt> fields, each signer will perform
the <tt>NonceAgg</tt> algorithm followed by the <tt>Sign</tt> algorithm in order to produce the
@ -173,7 +174,7 @@ Signers must remember to apply any relevant tweaks such as a tweak that is the r
BIP 32 unhardened derivation with the aggregate public key as the parent key.
If all other signers have provided a <tt>PSBT_IN_MUSIG2_PARTIAL_SIG</tt>, then the final signer may
perform the <tt>PartialSigAgg</tt> algorithm and produce a BIP 340 compatible signature that can be
perform the <tt>PartialSigAgg</tt> algorithm and produce a [[bip-0340.mediawiki|BIP 340]] compatible signature that can be
placed into a <tt>PSBT_IN_TAP_KEY_SIG</tt> or a <tt>PSBT_IN_TAP_SCRIPT_SIG</tt>.
===Finalizer===
@ -181,7 +182,7 @@ placed into a <tt>PSBT_IN_TAP_KEY_SIG</tt> or a <tt>PSBT_IN_TAP_SCRIPT_SIG</tt>.
A finalizer may perform the same <tt>PartialSigAgg</tt> step as the final signer if it has not
already been done.
Otherwise, the resulting signature is a BIP 340 compatible signature and finalizers should treat it
Otherwise, the resulting signature is a [[bip-0340.mediawiki|BIP 340]] compatible signature and finalizers should treat it
as such.
==Backwards Compatibility==