user138867: Context about the ECDSA nonce: Questions about generating a random number for ECDSA
Are these nonce values public or private? I understand that they are generated to be different every transaction and never reused, but unless I'm mistaken I cannot find any reference to them being a public part of a bitcoin transaction. Because of this, I don't understand how a transaction could be verified if a secret nonce was used, would this not obscure a large part of the message being signed and create un-verifiable data from someone who doesn't own the private key? Or is it that the value is in fact public, if public where are they in a transaction? If it is private how are verifications accomplished?

user208: 
Are these nonce values public or private?

Yes and no.
For every signature, a new, secret, unpredictable, private nonce is generated. It is never revealed, just like the private key is never revealed. If the term "ECDSA nonce" is used without qualifications, it usually refers to this private nonce.
Then the corresponding public nonce is computed. It's effectively the same computation as is done to go from private key to public key. This public nonce is part of the signature, and necessary to verify it. This is usually not talked about in superficial descriptions of ECDSA, as all of this is just internal to the algorithm. For users of ECDSA, it suffices to think of the signature as a single black box that ought to be passed around from the signer to the verifier unmodified.
I'll try to explain how ECDSA works in a bit more detail, though you have to be aware that there isn't all that much of an "insight" that makes one understand why it is secure; ultimately all of that boils down to many people having tried to break it, and fail.

Let m be the message, and z = hash(m) the hash of the message.
Let d be the private key, a number in range [1,n-1], where n is a constant, close to 2256.
Let E be the function that turns private keys into public keys, which takes as input a number, and returns a "point".

E has the property that for any a and b, it holds that E(a) ⊕ E(b) = E(a + b), where ⊕ is an addition-like operation between points.
E also has the property that for any a and b, it holds that aⓧE(b) = E(ab), where ⓧ is a multiplication-like operation between numbers and points, returning a point.
E has the property that given E(d), it's hard to find d.


Let Q be the public key, Q = E(d).

ECDSA signing of message m with private key d is then roughly:

Generate a random nonce k.
Compute the public nonce R = E(k).
Turn R into a number, r.
Compute s = k-1(z + dr).
Return the signature (r, s).

Someone seeing the signature can't figure out k or d, because it's hard to go from R = E(k) to k, and without k, the equation s = (z + dr) / k has two unknowns (k and d). Note that this is just an intuition for why it's hard; it's not a proof.
However, it is possible to verify the signature!

We know s = k-1(z + dr).
Bring k to the other side: sk = z + dr.
Apply E() to both sides of the equation: E(sk) = E(z + dr).
Then use the multiplication and addition rules: sⓧE(k) = E(z)⊕(rⓧE(d)).
Using R = E(k) and Q = E(d) we get: sⓧR = E(z)⊕(rⓧQ).
This is an equation the verifier can check, since they have s, z, r, Q, and can find R from r.

In actual ECDSA, the ⓧ and ⊕ operations are elliptic curve point multiplication and addition, and E() is multiplication with the curve generator. Those are implementation details however, and the scheme works just as well for other kinds of mathematical structures that permit such operations, and have the property that E() is hard to invert.

138867: <p>Context about the ECDSA nonce: <a href="https://bitcoin.stackexchange.com/questions/114908/questions-about-generating-a-random-number-for-ecdsa">Questions about generating a random number for ECDSA</a></p>
<p>Are these nonce values public or private? I understand that they are generated to be different every transaction and never reused, but unless I'm mistaken I cannot find any reference to them being a public part of a bitcoin transaction. Because of this, I don't understand how a transaction could be verified if a secret nonce was used, would this not obscure a large part of the message being signed and create un-verifiable data from someone who doesn't own the private key? Or is it that the value is in fact public, if public where are they in a transaction? If it is private how are verifications accomplished?</p>
 208: <blockquote>
<p>Are these nonce values public or private?</p>
</blockquote>
<p>Yes and no.</p>
<p>For every signature, a new, secret, unpredictable, <em>private nonce</em> is generated. It is never revealed, just like the private key is never revealed. If the term &quot;ECDSA nonce&quot; is used without qualifications, it usually refers to this private nonce.</p>
<p>Then the corresponding <em>public nonce</em> is computed. It's effectively the same computation as is done to go from private key to public key. This public nonce is part of the signature, and necessary to verify it. This is usually not talked about in superficial descriptions of ECDSA, as all of this is just internal to the algorithm. For users of ECDSA, it suffices to think of the signature as a single black box that ought to be passed around from the signer to the verifier unmodified.</p>
<p>I'll try to explain how ECDSA works in a bit more detail, though you have to be aware that there isn't all that much of an &quot;insight&quot; that makes one understand <em>why</em> it is secure; ultimately all of that boils down to many people having tried to break it, and fail.</p>
<ul>
<li>Let <em>m</em> be the message, and <em>z = hash(m)</em> the hash of the message.</li>
<li>Let <em>d</em> be the private key, a number in range <em>[1,n-1]</em>, where <em>n</em> is a constant, close to <em>2<sup>256</sup></em>.</li>
<li>Let <em>E</em> be the function that turns private keys into public keys, which takes as input a number, and returns a &quot;point&quot;.
<ul>
<li><em>E</em> has the property that for any <em>a</em> and <em>b</em>, it holds that <em>E(a) ⊕ E(b) = E(a + b)</em>, where <em>⊕</em> is an addition-like operation between points.</li>
<li><em>E</em> also has the property that for any <em>a</em> and <em>b</em>, it holds that <em>aⓧE(b) = E(ab)</em>, where <em>ⓧ</em> is a multiplication-like operation between numbers and points, returning a point.</li>
<li><em>E</em> has the property that given <em>E(d)</em>, it's hard to find <em>d</em>.</li>
</ul>
</li>
<li>Let <em>Q</em> be the public key, <em>Q = E(d)</em>.</li>
</ul>
<p>ECDSA signing of message <em>m</em> with private key <em>d</em> is then roughly:</p>
<ul>
<li>Generate a random nonce <em>k</em>.</li>
<li>Compute the public nonce <em>R = E(k)</em>.</li>
<li>Turn <em>R</em> into a number, <em>r</em>.</li>
<li>Compute <em>s = k<sup>-1</sup>(z + dr)</em>.</li>
<li>Return the signature <em>(r, s)</em>.</li>
</ul>
<p>Someone seeing the signature can't figure out <em>k</em> or <em>d</em>, because it's hard to go from <em>R = E(k)</em> to <em>k</em>, and without <em>k</em>, the equation <em>s = (z + dr) / k</em> has two unknowns (<em>k</em> and <em>d</em>). Note that this is just an intuition for why it's hard; it's not a proof.</p>
<p>However, it is possible to verify the signature!</p>
<ul>
<li>We know <em>s = k<sup>-1</sup>(z + dr)</em>.</li>
<li>Bring <em>k</em> to the other side: <em>sk = z + dr</em>.</li>
<li>Apply <em>E()</em> to both sides of the equation: <em>E(sk) = E(z + dr)</em>.</li>
<li>Then use the multiplication and addition rules: <em>sⓧE(k) = E(z)⊕(rⓧE(d))</em>.</li>
<li>Using <em>R = E(k)</em> and <em>Q = E(d)</em> we get: <em>sⓧR = E(z)⊕(rⓧQ)</em>.</li>
<li>This is an equation the verifier can check, since they have <em>s</em>, <em>z</em>, <em>r</em>, <em>Q</em>, and can find <em>R</em> from <em>r</em>.</li>
</ul>
<p>In actual ECDSA, the ⓧ and ⊕ operations are elliptic curve point multiplication and addition, and <em>E()</em> is multiplication with the curve generator. Those are implementation details however, and the scheme works just as well for other kinds of mathematical structures that permit such operations, and have the property that <em>E()</em> is hard to invert.</p>
