Merge pull request from dgpv/patch-5

Nit: bip-schnorr: Add missing dots that denote multiplication
This commit is contained in:
Pieter Wuille 2019-11-21 11:33:09 -08:00 committed by GitHub
commit 51c2c12158
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -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 = tG'', 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.