Pairs of P2PKH Addresses with Repeated Nonce k

Hey folks, I stumbled upon some P2PKH address pairs that were generated in a cloned and biased virtual setup, which caused them to use the same nonce r. Here's what I found: Transaction 1 Nonce (r) = 5c16a3fbafc1ef0 Public Key = 956fb654bcb2e061 Transaction 2 (3 days later) Nonce (r) = 5c16a3fbafc1ef0 Public Key = 4b20eabe93918281 Both transactions send funds to the same address, and that address also reuses nonce k with the same private key. Possible Security Risks In a typical ECDSA setup, reusing the same r with different private keys turns into a system of equations involving two private keys and one shared unknown, which normally can’t be solved easily. But could these private key pairs come from a common base structure (like k + ?), creating a vulnerability? Questions for the community: Has anyone encountered a similar situation? Are the private keys in this case at risk? I’d really appreciate any thoughts or analysis you might have.

I don't know your goal. But this won't happen if you use RFC 6979. Since different key with same message hash always leads to different k value. I believe this StackExchange answer partially answer answer your question, https://crypto.stackexchange.com/a/72112.

Without knowing the nonce, if there are two signatures for two different private keys sharing the same nonce k, it is not possible to derive the private keys from the two signatures, even if it is known that the same nonce was used in both. In cases where two signatures with identical nonces are used for the same private key: https://bitcointalk.org/index.php?topic=5495568 If the nonce k is known, you can solve these equations to find the respective private keys

more context: Ax: 1AxP2pkhFakeAddressExample1111 a1: 1A1P2pkhFakeAddressExample2222 a2: 1A2P2pkhFakeAddressExample3333 a3: 1A3P2pkhFakeAddressExample4444 a4: 1A4P2pkhFakeAddressExample5555 a5: 1A5P2pkhFakeAddressExample6666 a6: 1A6P2pkhFakeAddressExample7777 a7: 1A7P2pkhFakeAddressExample8888 a8: 1A8P2pkhFakeAddressExample9999 Transactions executed: Multiple addresses (a1, a2, a3, ...) sent funds to Ax. Ax reused the same nonce 𝑘 twice with the same private key → Ax is compromised. Ax also shared the same nonce 𝑘 with some addresses (a1, a2, a3), meaning these addresses are compromised as well. In other transactions, a few days apart: a4 and a5 used the same 𝑟 : r = 5c16a3fbafc1ef0 a7 and a8 also used the same 𝑟 : r = 4b20eabef45faf0 Questions: Could Ax be considered a "master key" in this scenario? Are a4, a5, a6, and a7 vulnerable? Given that a4 and a5 shared the same 𝑟 and a7 and a8 also shared an 𝑟 is there an exploitable weakness here? There are 4 BTC at risk in these addresses, so any in-depth analysis would be greatly appreciated.

What are you using for the transactions? This practice of repeating nonces is insecure. If Ax made two signatures with the same nonce, its private key is exposed. From there, you can calculate the nonce, and once the nonce is obtained, you can get the private keys of all the addresses that share the same nonce. Transfer the funds to a secure location and stop using whatever you're using to send the transactions.

Sometimes in the same transaction Trx 1 : Ax: 1AxP2pkhFakeAddressExample1111>> A1: 1A1P2pkhFakeAddressExample2222>> A2: 1A2P2pkhFakeAddressExample3333>>                Ax: 1AxP2pkhFakeAddressExample1111 A3: 1A3P2pkhFakeAddressExample4444>> A4: 1A4P2pkhFakeAddressExample5555>> ⸻ The wallets I am interested in are those that have completely reused the nonce r between addresses in these transactions: Trx 2: A4: 1A4P2pkhFakeAddressExample5555 >>1AxP2pkhFakeAddressExample1111 Trx 3: A5: 1A5P2pkhFakeAddressExample6666 >>1AxP2pkhFakeAddressExample1111 exemple: TRX 2 : R = 00b272eff27c410cd79b465a893d084ac0513e5cf43bff538c238e0247fc2a3dc6 S = 6d9b20df51a40139f080ced53f1bfd66c925979a886d0309f0407e3e283878cd Z = c2b9a5609f88cdb943d3cf9cae1b284e187583a583ea9f8c39aac487779c003e A4PublicKey = 037562e9f0388bc4499fa46111f59824355be953db0a3a016ee152a82059711fa2 TRX 3 : R = 00b272eff27c410cd79b465a893d084ac0513e5cf43bff538c238e0247fc2a3dc6 S = 017b939c4cd9d8c648c69d36b6ba424c641d9afeea2fd06d62b273e15a688c6a Z = ef64d2f01db818ab0b30e4674f6ede12c145b83784e46e7c0512a72f7c35469e A5PublicKey = 025b511205afcd38e2f96294cb08cf78415999d78733ef84409293530a43f077c2 I already have Ax 1AxP2pkhFakeAddressExample1111 private key, Thanks for you answers by the way

If you know the private key for Ax, you know the private keys for the addresses that share a nonce with the signatures of Ax. Regardless of whether some keys have been affected or not, funds should be sent to a safe place. Even if they have not been affected, for example A6, you run the risk that the nonce of their signatures could be compromised at any moment when an insecure signature reuses one of its nonces or vice versa. Your method for build tx is vulnerable and should not be used.

mcdouglasx I only have the private key for Ax; I didn't recover the ones that shared the nonce with Ax because they are empty. The addresses that interest me are those that shared between themselves sending to Ax, specifically A4 and A5, which had a three-day interval between their transactions. We know that we can't solve two equations with three unknowns, but in this case, we have Ax

So far, the nonce shared between those 2 signatures is not shared with Ax. I don't know why you are inferring any relationship between Ax and (A4, A5). I suppose you want to explore the possibility that A4 and A5 are children of Ax. If that is the case, you shouldn't be concerned with the nonces between A4 and A5, but rather deriving keys from Ax. Another perspective would be to extract the nonces from the signatures you have access to and see if they follow some kind of pattern that allows you to predict the nonce used by A4 and A5.

I suppose that A1, A2, A3, A4, A5, A6, A7, A8, etc. are children of Ax, as the transactions from A1, A2, and A3, which shared the same nonce as Ax, were made towards Ax on the same date, sometimes even within the same transaction, down to the millisecond. I would like to remind you that these are addresses discovered on the blockchain dating back to 2015, likely generated in a cloned VM.

Let's dive right into the case that happened before. According to information from https://christian-rossow.de/publications/btcsteal-raid2018.pdf we are presented with the top 10 of most reused r value that have ever happened, 1st Rank: 0x00000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63 2,276,718. Let's use some of it. txid = 003bf42c785dc750ee5280a62c91bb0e32b2829b7f446c333aa346ea7972e80a (single Address) txid = 0000ad6683b802442afcdd96743dc889c01ec978b0db2c92bd1e550ccda4b7c1(2 Addresses) using tools from iceland2k14 : https://github.com/iceland2k14/rsz Result : [Input Index #: 0]      R: 3b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63      S: 37241abae7c5160855be545f69b22652d0675394b2ec51c406c047481489bfad      Z: 407267215a54d1c3a426af0c07adc82ca005cdbe78b93e1c541bacdbeb837930 PubKey: 0200a1541e7dd887595db87a5823e831608ff74cd3ac266e4d35bdea169ac1264a ====================================================================== [Input Index #: 1]      R: 3b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63      S: 17c51c7e43b18c11d24420bb2ac0d577db0f567b1cb8d7c906017e578af71752      Z: d021e63fac5e96bee5e3c8de2726709978093abe9b774b37b464409a9867edfe PubKey: 0200a1541e7dd887595db87a5823e831608ff74cd3ac266e4d35bdea169ac1264a ====================================================================== . . . we just need 2 set of rsz pairs Now.. Lets try to get the PrivKey and k-nonce Result : k-Nonce : 0x7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a0 PrivKey : 0xa2df1308b53e3fac548c630d75715960a3a38eb0e2b920e5fbbb79ad9cbe4715 True 2nd txid [Input Index #: 0]      R: 3b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63      S: 3530d87f6b67f398d9d3e3b4c74902b171f041b48be4f5b7e0cbeca4455533f0      Z: 8b5c8a445b469f121131a5c72796a06ac7d8a1cff77bbb452837fb7e1d44ab39 PubKey: 030be93b33bf3126af00f79ab309676d47fb8b2e2c4cbbae76fd52b9d78bc8bcd7 ====================================================================== [Input Index #: 1]      R: 3b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63      S: 64801f6a42e9fdeb21fe29c56c2d69e306fb6046a2a60d7b372c374bcaca2edf      Z: b6125c89387fd212c6a2dd30ce55e0ed1d055cee85caf5f373dbb32c22f309c5 PubKey: 0225c072edb4f3112d769e8743bc46007664083b41331023c0be1630bac6870b76 Using the code from @mcdouglasx Result : Private Key 1: 0x33c9621cb97649655c78fdc38fdc8c4d1f4d6e8b25aca9bec93b39fec7866a74 <== Correct Private Key 2: 0x8e1d9939700d8571ae5f869ab0cb33fe5ee8ca1001a45f9dc09457b7decdd7e8 <== incorrect What I missed?

As far as I remember, this 'technology' I used 10 years ago to consolidate spam/dust outputs. https://bitcointalk.org/index.php?topic=1175321 My transactions had smaller size and were included in blocks before other steal bots. Of course, I can sign a message with a private key of 1aamWKicYga3AN8UgywedHzEG12KbUUJJ ( recepient in tx https://www.blockchain.com/explorer/transactions/btc/003bf42c785dc750ee5280a62c91bb0e32b2829b7f446c333aa346ea7972e80a ) By the way, what do you think about this transaction? Yes, this is not p2pkh, but p2wsh. Do you see R and S?

In the scenario I mentioned earlier in the thread, where the same nonce 𝑟 is reused between different public keys, I have noticed that sometimes we observe two instances of reuse between two keys, or even three instances of reuse among three different keys. Given this situation, is there a way to recover the private keys associated with these compromised addresses through a nonce reuse attack or any other method? Since we have two equations and three unknowns in this case, it seems like it might be possible to solve for the private keys. I am aware that there are approximately 4 BTC at stake in this situation. Any insights on how to approach this attack, or if there are existing tools or techniques to recover the private keys, would be highly appreciated. Thanks!

With any valid {R,S,Z,P} you are able to create a great number of valid {R,S,Z1,P1} but this knowledge can not help you to find privkey of P

amaclin1, these P2PKH addresses are compromised no matter what—around 4 BTC is at risk. The transactions accidentally reused the R value between addresses due to a biased PRNG. I’m looking for a brute-force method to recover the nonce or any other approach. I already have a private key that might be the master key for all these

Do you understand me? I can provide you a number of valid {R,S,Zn,Pn} for any given R,S Without knowledge how 'K' was choosen this information has no sense. Just a math.

amaclin1 Have you ever seen a similar exploitable case or an optimized brute-force method for this kind of situation?

hello send me a message

Have a look: and the output is:

amaclin1, Thanks, I understand now. As mentioned earlier, all these addresses are compromised. For one address containing just over 2 BTC, there are 6 RSZ signatures in total. The second signature for this address shared the same rr with two other empty addresses, but it was the first to use this rr. In these 6 signatures, there are similar patterns, such as prefixes and fixed bits.