<div dir="ltr"><div>Some quick comments:<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Signing<br><br>To sign:






<ul><li>Let <i>k = int(hash(bytes(d) || m)) mod n</i><sup id="gmail-user-content-cite_ref-8-0">[<a href="https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki#cite_note-8">8</a>]</sup>.</li><li>Let <i>R = kG</i>.</li><li>If <i>jacobi(y(R)) ≠ 1</i>, let <i>k = n - k</i>.</li><li>Let <i>e = int(hash(bytes(x(R)) || bytes(dG) || m)) mod n</i>.</li><li>The signature is <i>bytes(x(R)) || bytes(k + ex mod n)</i>.</li></ul></blockquote><div>Can we avoid mutable variables in these specification?  I know this is commonly done in RFCs, but I think it is fairly confusing to have `k` defined in two different ways within a single specification.<br></div><div>Let&#39;s let k&#39; = k when jacobi(y(R)) = 1 and let k&#39; = n - k when jacobi(y(R)) = -1.  Note that this ensures that jacobi(y(k&#39;G)) = 1.<br><br></div><div>Also you&#39;ve sort of left it undefined what to do when k = 0.  According to the current specification, you will produce an invalid signature.  The expected result is that you should win a 1000 BTC prize.<br><br></div><div>One solution is to let k = <i>1 + int(hash(bytes(d) || m)) mod (n-1)</i>.  Alternatively you could let k&#39; = 1 when k = 0.  Or you could just make a note that signature generation fails with this message and private key pair when this happens.<br></div><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Let <i>e = int(hash(bytes(x(R)) || bytes(dG) || m)) mod n</i>.<br></blockquote><div><br></div><div>P = dG should probably be noted somewhere in the text.  I.e. this signature is generated for the public key P = dG.<br><br></div><div>If the inputs to hash were reordered as <i>hash(bytes(dG) || <i>bytes(x(R)) || </i>m)</i> then there is an opportunity for SHA256 expander to be partially prefilled for a fixed public key.  This could provide a little benefit, especially when multiple signatures for a single public key need to be generated and/or verified.  If all things are otherwise equal, perhaps this alternate order is better.<br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> The signature is <i>bytes(x(R)) || bytes(k + ex mod n)</i>.</blockquote><div><br></div><div>You haven&#39;t defined `x`.  I&#39;m guessing you mean `d` instead.<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><h3>Optimizations</h3><p><b>Jacobian coordinates</b> <br></p><ul><li><i>oncurve(P)</i> can be implemented as <i>y<sup>2</sup> = x<sup>3</sup> + 7z<sup>6</sup> mod p</i>.</li></ul></blockquote><div>oncurve(P) requires that `P` be on the curve and not infinity.  You need another condition here to ensure that `P` is not infinity.<br></div><div> </div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 6, 2018 at 2:08 PM, Pieter Wuille via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello everyone,<br>
<br>
Here is a proposed BIP for 64-byte elliptic curve Schnorr signatures,<br>
over the same curve as is currently used in ECDSA:<br>
<a href="https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki" rel="noreferrer" target="_blank">https://github.com/sipa/bips/<wbr>blob/bip-schnorr/bip-schnorr.<wbr>mediawiki</a><br>
<br>
It is simply a draft specification of the signature scheme itself. It<br>
does not concern consensus rules, aggregation, or any other<br>
integration into Bitcoin - those things are left for other proposals,<br>
which can refer to this scheme if desirable. Standardizing the<br>
signature scheme is a first step towards that, and as it may be useful<br>
in other contexts to have a common Schnorr scheme available, it is its<br>
own informational BIP.<br>
<br>
If accepted, we&#39;ll work on more production-ready reference<br>
implementations and tests.<br>
<br>
This is joint work with several people listed in the document.<br>
<br>
Cheers,<br>
<span class="HOEnZb"><font color="#888888"><br>
-- <br>
Pieter<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</font></span></blockquote></div><br></div>