diff options
Diffstat (limited to 'bip-0327.mediawiki')
| -rw-r--r-- | bip-0327.mediawiki | 10 |
1 files changed, 6 insertions, 4 deletions
diff --git a/bip-0327.mediawiki b/bip-0327.mediawiki index 07b40f5..4815f40 100644 --- a/bip-0327.mediawiki +++ b/bip-0327.mediawiki @@ -123,7 +123,7 @@ This is by design: All algorithms in this proposal handle multiple signers who ( and applications are not required to check for duplicate individual public keys. In fact, applications are recommended to omit checks for duplicate individual public keys in order to simplify error handling. Moreover, it is often impossible to tell at key aggregation which signer is to blame for the duplicate, i.e., which signer came up with an individual public key honestly and which disruptive signer copied it. -In contrast, MuSig2 is designed to identify disruptive signers at signing time (see [[#identifiying-disruptive-signers|Identifiying Disruptive Signers]]). +In contrast, MuSig2 is designed to identify disruptive signers at signing time (see [[#identifying-disruptive-signers|Identifying Disruptive Signers]]). While the algorithms in this proposal are able to handle duplicate individual public keys, there are scenarios where applications may choose to abort when encountering duplicates. For example, we can imagine a scenario where a single entity creates a MuSig2 setup with multiple signing devices. @@ -211,7 +211,7 @@ The bit can be obtained with ''GetPlainPubkey(keyagg_ctx)[0] & 1''. The following specification of the algorithms has been written with a focus on clarity. As a result, the specified algorithms are not always optimal in terms of computation and space. -In particular, some values are recomputed but can be cached in actual implementations (see [[#signing-flow|Signing Flow]]). +In particular, some values are recomputed but can be cached in actual implementations (see [[#general-signing-flow|General Signing Flow]]). === Notation === @@ -367,7 +367,7 @@ Algorithm ''ApplyTweak(keyagg_ctx, tweak, is_xonly_t)'': Algorithm ''NonceGen(sk, pk, aggpk, m, extra_in)'': * Inputs: ** The secret signing key ''sk'': a 32-byte array (optional argument) -** The individual public key ''pk'': a 33-byte array (see [[#modifications-to-nonce-generation|Modifications to Nonce Generation]] for the reason that this argument is mandatory) +** The individual public key ''pk'': a 33-byte array (see [[#signing-with-tweaked-individual-keys|Signing with Tweaked Individual Keys]] for the reason that this argument is mandatory) ** The x-only aggregate public key ''aggpk'': a 32-byte array (optional argument) ** The message ''m'': a byte array (optional argument)<ref name="mlen">In theory, the allowed message size is restricted because SHA256 accepts byte strings only up to size of 2^61-1 bytes (and because of the 8-byte length encoding).</ref> ** The auxiliary input ''extra_in'': a byte array with ''0 ≤ len(extra_in) ≤ 2<sup>32</sup>-1'' (optional argument) @@ -465,7 +465,7 @@ Algorithm ''Sign(secnonce, sk, session_ctx)'': * Fail if ''pk ≠ secnonce[64:97]'' * Let ''a = GetSessionKeyAggCoeff(session_ctx, P)''; fail if that fails<ref>Failing ''Sign'' when ''GetSessionKeyAggCoeff(session_ctx, P)'' fails is not necessary for unforgeability. It merely indicates to the caller that the scheme is not being used correctly.</ref> * Let ''g = 1'' if ''has_even_y(Q)'', otherwise let ''g = -1 mod n'' -* <div id="Sign negation"></div>Let ''d = g⋅gacc⋅d' mod n'' (See [[negation-of-the-secret-key-when-signing|Negation Of The Secret Key When Signing]]) +* <div id="Sign negation"></div>Let ''d = g⋅gacc⋅d' mod n'' (See [[#negation-of-the-secret-key-when-signing|Negation Of The Secret Key When Signing]]) * Let ''s = (k<sub>1</sub> + b⋅k<sub>2</sub> + e⋅a⋅d) mod n'' * Let ''psig = bytes(32, s)'' * Let ''pubnonce = cbytes(k<sub>1</sub>'⋅G) || cbytes(k<sub>2</sub>'⋅G)'' @@ -785,6 +785,8 @@ An exception to this rule is <code>MAJOR</code> version zero (0.y.z) which is fo The <code>MINOR</code> version is incremented whenever the inputs or the output of an algorithm changes in a backward-compatible way or new backward-compatible functionality is added. The <code>PATCH</code> version is incremented for other changes that are noteworthy (bug fixes, test vectors, important clarifications, etc.). +* '''1.0.1''' (2024-05-14): +** Fix minor issue in ''PartialSigVerify'' vectors. * '''1.0.0''' (2023-03-26): ** Number 327 was assigned to this BIP. * '''1.0.0-rc.4''' (2023-03-02): |