diff options
Diffstat (limited to 'bip-schnorr.mediawiki')
| -rw-r--r-- | bip-schnorr.mediawiki | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/bip-schnorr.mediawiki b/bip-schnorr.mediawiki index 3d6a957..5e4bd47 100644 --- a/bip-schnorr.mediawiki +++ b/bip-schnorr.mediawiki @@ -146,7 +146,7 @@ The algorithm ''Sign(sk, m)'' is defined as: * Let ''d = d' '' if ''has_square_y(P)'', otherwise let ''d = n - d' ''. * Let ''k' = int(hash<sub>BIPSchnorrDerive</sub>(bytes(d) || m)) mod n''<ref>Note that in general, taking the output of a hash function modulo the curve order will produce an unacceptably biased result. However, for the secp256k1 curve, the order is sufficiently close to ''2<sup>256</sup>'' that this bias is not observable (''1 - n / 2<sup>256</sup>'' is around ''1.27 * 2<sup>-128</sup>'').</ref>. * Fail if ''k' = 0''. -* Let ''R = k'G''. +* Let ''R = k'⋅G''. * Let ''k = k' '' if ''has_square_y(R)'', otherwise let ''k = n - k' ''. * Let ''e = int(hash<sub>BIPSchnorr</sub>(bytes(R) || bytes(P) || m)) mod n''. * Return the signature ''bytes(R) || bytes((k + ed) mod n)''. @@ -226,7 +226,7 @@ Moreover, Schnorr signatures are compatible with [https://web.archive.org/web/20 === Adaptor Signatures === -[https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2018-05-18-l2/slides.pdf Adaptor signatures] can be produced by a signer by offsetting his public nonce with a known point ''T = tG'', but not offsetting his secret nonce. +[https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2018-05-18-l2/slides.pdf Adaptor signatures] can be produced by a signer by offsetting his public nonce with a known point ''T = t⋅G'', but not offsetting his secret nonce. A correct signature (or partial signature, as individual signers' contributions to a multisignature are called) on the same message with same nonce will then be equal to the adaptor signature offset by ''t'', meaning that learning ''t'' is equivalent to learning a correct signature. This can be used to enable atomic swaps or even [https://eprint.iacr.org/2018/472 general payment channels] in which the atomicity of disjoint transactions is ensured using the signatures themselves, rather than Bitcoin script support. The resulting transactions will appear to verifiers to be no different from ordinary single-signer transactions, except perhaps for the inclusion of locktime refund logic. |