user124971: Is the same private key using k and k*2 respectively in two different signatures vulnerable?
If yes How to calculate the key in this case
Here is an example, Both signatures are valid and the nonce of r2,s2,z2 is double the first signature's nonce, how do I calculate private key from these two signatures?
r1 = 0xdcf17de661e280dbf62e03ef1655d1baaabc301da9fc6b29a63e52e7780c115d
s1 = 0x20be91ddd5598e22fa43014172df5312275fbdb462a2e9855c7a7433138a4a9c
z1 = 0xbb1e00d2027efd3085b83de2a3602a8ea49e0c9d5b821cd6291d5feefd410303
r2 = 0x5baeea47c4d1759efc2b4a6a1948727648a7f9d0db6c77c09b0a26a0ae22d4ad
s2 = 0x4f08689cd10e8fd5e9be108d18e2ee582774dc409176643800284669d6e787eb
z2 = 0x0fa25a9a0712366012de680bed93f8c94ffa2c119464d1e59b0a03b1c115b54f

user208: Assuming you're talking about ECDSA signing. For BIP340/Schnorr signatures, see this answer.
For valid signatures
Let:

d: the private key
P=d*G: the public key
k1: the (first) nonce
R1=k1*G: the public first nonce
r1=R1.x mod n: the public first nonce as it will be encoded in the signature.
k2=2*k1, R2=k2*G=2*R1, r2=R2.x mod n: the same for the second nonce
z1 and z2: the respective message hash

The two signatures will then be the pairs (r,s) and (r',s') for which:

s1 = (z1 + r1*d) / k1 mod n
s2 = (z2 + r2*d) / k2 mod n = (m2 + r2*d) / (2*k1) mod n

Multiplying both sides of the equations by their denominator on the right hand side:

s1*k1 = z1 + r1*d mod n
2*s2*k1 = z2 + r2*d mod n

Assuming 2*r1*s2 ≠ r2*s1, this is a set of two linear equations in two unknowns (k1 and d), with solution:

d = (z2*s1 - 2*z1*s2) / (2*r1*s2 - r2*s1) mod n
k1 = (z2*r1 - z1*r2) / (2*r1*s2 - r2*s1) mod n

Don't ever use related nonces for ECDSA (or Schnorr) signatures. Create a fresh, independent, nonce every time. The industry standard is to generate nonces using RFC6979.
For fake "signatures"
The values you've provided however do not correspond to real signatures, despite satisfying the equation. That's because for a signature to be valid, you have to give the messages which hash to the z values, not just the result. And you can't do that here, because z2 = (r2/r1)*z1. Such matching ratios will not (and cannot) occur for z values that are the result of hashing.
It turns out that given any ECDSA triplet (r,s,z), and integer a, another triplet can be found. Let R be an elliptic curve point whose X coordinate equals r (mod n), and R' = aR, and r' the X coordinate of R'. Then (r',r'*s/(a*r'),r'*z/r) is another ECDSA triplet, corresponding to multiplying k with a. However, again, this is not a valid signature because its z value will not be the hash of a computable message. And the formula above will also fail to retrieve the private key in this case, because the second "signature" wasn't created by using the private key.

124971: <p>Is the same private key using k and k*2 respectively in two different signatures vulnerable?
If yes How to calculate the key in this case</p>
<p>Here is an example, Both signatures are valid and the nonce of r2,s2,z2 is double the first signature's nonce, how do I calculate private key from these two signatures?</p>
<p>r1 = 0xdcf17de661e280dbf62e03ef1655d1baaabc301da9fc6b29a63e52e7780c115d</p>
<p>s1 = 0x20be91ddd5598e22fa43014172df5312275fbdb462a2e9855c7a7433138a4a9c</p>
<p>z1 = 0xbb1e00d2027efd3085b83de2a3602a8ea49e0c9d5b821cd6291d5feefd410303</p>
<p>r2 = 0x5baeea47c4d1759efc2b4a6a1948727648a7f9d0db6c77c09b0a26a0ae22d4ad</p>
<p>s2 = 0x4f08689cd10e8fd5e9be108d18e2ee582774dc409176643800284669d6e787eb</p>
<p>z2 = 0x0fa25a9a0712366012de680bed93f8c94ffa2c119464d1e59b0a03b1c115b54f</p>
 208: <p>Assuming you're talking about ECDSA signing. For BIP340/Schnorr signatures, see <a href="https://bitcoin.stackexchange.com/questions/110811/why-is-it-important-that-nonces-when-signing-not-be-related">this answer</a>.</p>
<h3>For valid signatures</h3>
<p>Let:</p>
<ul>
<li><code>d</code>: the private key</li>
<li><code>P=d*G</code>: the public key</li>
<li><code>k1</code>: the (first) nonce</li>
<li><code>R1=k1*G</code>: the public first nonce</li>
<li><code>r1=R1.x mod n</code>: the public first nonce as it will be encoded in the signature.</li>
<li><code>k2=2*k1</code>, <code>R2=k2*G=2*R1</code>, <code>r2=R2.x mod n</code>: the same for the second nonce</li>
<li><code>z1</code> and <code>z2</code>: the respective message hash</li>
</ul>
<p>The two signatures will then be the pairs <code>(r,s)</code> and <code>(r',s')</code> for which:</p>
<ul>
<li><code>s1 = (z1 + r1*d) / k1 mod n</code></li>
<li><code>s2 = (z2 + r2*d) / k2 mod n = (m2 + r2*d) / (2*k1) mod n</code></li>
</ul>
<p>Multiplying both sides of the equations by their denominator on the right hand side:</p>
<ul>
<li><code>s1*k1 = z1 + r1*d mod n</code></li>
<li><code>2*s2*k1 = z2 + r2*d mod n</code></li>
</ul>
<p>Assuming <code>2*r1*s2 ≠ r2*s1</code>, this is a set of two linear equations in two unknowns (<code>k1</code> and <code>d</code>), with solution:</p>
<ul>
<li><code>d = (z2*s1 - 2*z1*s2) / (2*r1*s2 - r2*s1) mod n</code></li>
<li><code>k1 = (z2*r1 - z1*r2) / (2*r1*s2 - r2*s1) mod n</code></li>
</ul>
<p><em><strong>Don't ever use related nonces for ECDSA (or Schnorr) signatures. Create a fresh, independent, nonce every time. The industry standard is to generate nonces using <a href="https://datatracker.ietf.org/doc/html/rfc6979" rel="nofollow noreferrer">RFC6979</a>.</strong></em></p>
<h3>For fake &quot;signatures&quot;</h3>
<p>The values you've provided however do not correspond to real signatures, despite satisfying the equation. That's because for a signature to be valid, you have to give the messages which hash to the <code>z</code> values, not just the result. And you can't do that here, because <code>z2 = (r2/r1)*z1</code>. Such matching ratios will not (and cannot) occur for <code>z</code> values that are the result of hashing.</p>
<p>It turns out that given any ECDSA triplet <code>(r,s,z)</code>, and integer <code>a</code>, another triplet can be found. Let <code>R</code> be an elliptic curve point whose X coordinate equals <code>r</code> (mod n), and <code>R' = aR</code>, and <code>r'</code> the X coordinate of <code>R'</code>. Then <code>(r',r'*s/(a*r'),r'*z/r)</code> is another ECDSA triplet, corresponding to multiplying <code>k</code> with <code>a</code>. However, again, this is not a valid signature because its z value will not be the hash of a computable message. And the formula above will also fail to retrieve the private key in this case, because the second &quot;signature&quot; wasn't created by using the private key.</p>
