Hi everyone,

I came across an interesting case involving the Bitcoin address "1LN4yp6rQALjwg53SKsi44teq1fp2v5wqR", which reused the same nonce k across two different transactions signed with the same private key.

Transaction 1: 65278a3cf6d4710bd5a556edeb6854e07de0324a5008569e33984da491df8c38

R = 00b42646001435ec60a40982735c4e73d31be13d0086be394eaf5ce10b0f38f689
S = 711a12a1a4db96159ec5760f2201beeb04043efc3d39e10ba17c9e66816ff9ad
Z = 91002245c37eba47e4f5764f0c4780b3cd9ba0f3ea709368cfd21717d82be496

Transaction 2: d87d1bc2d41ed867f0f4b7b7ee9915f09cb82477388e306acac8279146edacb8

R = 00b42646001435ec60a40982735c4e73d31be13d0086be394eaf5ce10b0f38f689
S = 5c55551c5a2348d32107f4c7174c9a90aa9621c927326f1e4294432192589f3d
Z = c47a2f11de95b92b65ee72082eda621ee681faf6e9abc64597325523f7d76202

r (same in both signatures): 00b42646001435ec60a40982735c4e73d31be13d0086be394eaf5ce10b0f38f689

It looks like RFC 6979 (the deterministic method for generating k) was not used in this case. This address is relatively well-known.

My question is:

Is it possible to determine how k was generated in this situation (e.g., weak PRNG, timestamp-based, or something else)? And could we potentially reproduce the same k with the right assumptions?