ECDSA SECP256k1 curve - same-r-value-is-used-for-two-different-addresses

Question

Edited: changing the notation according request by fgrieu.

I have prepared 4 transactions for 2 pubkeys with the same r1 and r2.

properties of secp256k1:

p = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141   # order of curve

It is according to: ecdsa-revealing-the-private-key-from-four-signed-message-two-keys-and-shared-nonces- link here: https://billatnapier.medium.com/ecdsa-revealing-the-private-key-from-four-signed-message-two-keys-and-shared-nonces-secp256k1-5758f1258b1d

It should work, but it doesn't.

I put transactions, nonces and privatekeys

Why can I not to take value private1 and private2?

It gives me value 0: please help

privkey1= 74151126465914553719682701372546590912032713247110001383204298192577238294259
privkey2= 65602009300807068992382438511465994464148703102269145684254988072233619429415

nonce1= 113430668354305125354139681412571553637810109882549088741100884487402919060793
nonce2= 88941376982568942091029320764989550225390065895384871037015643141890275775717

signature matches
#transaction from first privkey1

r1= 37172049453198803628923372374682424137153412099188977901809252086397375163174
s1= 36665125934301679295764426496089959157670212057714313825462899262019004181013
h1= 45063904364969322573281122086971579379876583577391310824950725157431863085693

r2= 40974080779974461932858835766108658066940207003253964846620894290420102383124
s3= 88414683103569280491867470526894992004240909646745888824999991880846576153983
h3= 96925863066810859394685400246217607442326685412593308871569663983290139782035

##transaction from second privkey2

r1= 37172049453198803628923372374682424137153412099188977901809252086397375163174
s2= 48387795993880540164497955151292140905876432678370698441361372722465054520609
h2= 70890957235815785946608014568730757332857823983374044998781188028671033610413

r2= 40974080779974461932858835766108658066940207003253964846620894290420102383124
s4= 94479523762013111191490500533227932711756342618388816229238677867942525385058
h4= 88400657509035765824159536685234267382896518494653799783594906135509259195161

How to calculate, the above privatekey? if I use link : Is it possible to decrypt an ECDSA private key if the same nonce is used across different private keys?

I got result 0 for privkey1 and privkey2.

where is problem?

for another example everything works fine. but in above version is problem.

Answer 1

I'll use the notation in the references, thus the question's privkey1, privkey2, nonce1, nonce2 are noted $x_1$, $x_2$, $k_1$, $k_2$; and the prime order of curve secp256k1 is noted $p$ (rather than the usual $n$).

The question mentions "(…) 4 transactions for 2 pubkeys with the same r1 and r2", but gives different values for r1 and r2. I'll read instead: 4 ECDSA signatures matching 2 private/public keys pairs using only 2 nonces, in the following arrangement:

hash	nonce	privkey	signature	equation$\pmod p$
$h_1$	$k_1$	$x_1$	$(r_1,s_1)$	$s_1k_1≡r_1x_1+h_1$
$h_2$	$k_1$	$x_2$	$(r_1,s_2)$	$s_2k_1≡r_1x_2+h_2$
$h_3$	$k_2$	$x_1$	$(r_2,s_3)$	$s_3k_2≡r_2x_1+h_3$
$h_4$	$k_2$	$x_2$	$(r_2,s_4)$	$s_4k_2≡r_2x_2+h_4$

The numbers given for $x_i$, $k_i$, $r_i$, $h_j$, $s_j$ for $i\in\{1,2\}$ and $j\in\{1,2,3,4\}$ all are in $(1,p)$; verify the equations; and $r_i$ is the function of $k_i$ prescribed by ECDSA on secp256k1, that is $r_i$ is the X coordinate of $k_i\,G$ reduced modulo $p$ (the reduction seldom makes a difference, and this is no exception).

But contrary to the references, it holds $s_1s_4≡s_2s_3\pmod p$. That prevents applying the method in the references to find $x_1$ and $x_2$, which requires that $r_1r_2(s_1s_4-s_2s_3)$ be invertible modulo $p$.

Under the assumption $h_1$, $h_2$, $h_3$, $h_4$ (or the corresponding signed messages) and $x_1$, $x_2$, $k_1$, $k_2$ are arbitrary, with the signatures derived from that, there is no reason $s_1s_4≡s_2s_3\pmod p$ would hold. That it holds makes the system of 4 equations with 4 unknowns $x_1$, $x_2$, $k_1$, $k_2$ impossible to solve from the signatures and hashes alone; we'd need some additional relation involving at least one of the unknowns $x_1$, $x_2$, $k_1$, $k_2$, but none is stated.

One possibility is that there's none to be found. The whole thing could be a decoy, a joke, perhaps a scam (which that comment suggests). One way to build the question's numbers would be that $s_4$ is computed as $s_1^{-1}\,s_2\,s_3\bmod p$, then $h_4$ is computed from $s_4$ rather than as the hash of some message.