About Dublicate R and S | Bitcointalksearch.org

mamuu

member

Activity: 73

Merit: 19

Quote from: nc50lc on December 04, 2024, 02:22:08 AM

Quote from: mamuu on December 03, 2024, 02:52:17 PM

I could not verify the signature in this process. When I find the Z value, the Kx value of point K (i.e. R) is not verified. Am I wrong in calculating the message.
-snip-

Yes.
All inputs, together with those with the same R and S are signed with [SINGLE|ANYONECANPAY] (0x83) sighash flag. (can also be the reason for the same R,S)
But you've calculated the message hash for SIGHASH_ALL (0x01).

Problem is, I cannot find a single "RSZ tool" that can check for the sighash_flag then switch the z-value calculation algorithm accordingly.

With that; DYOR, I'll just leave you some references:

Hello, thank you very much for your explanation.
I hope I can verify manually.
I am trying to understand validation thoroughly.

I have separated this process as an example.
https://blockchain.info/rawtx/bd17bfb7051bef5ca916931f06493a0af0db080b4df21ee9768fa0f3d775070a?format=hex

It can be considered as a challenge open to members who have time and interest. I really want to understand the algorithm of verification.

I hope it will help those who want to work for verification.

Thank you very much.

Code:

01
000000
0c

6437b077cf6c1448d1e9a9b0891eec3e6dc12a29b0d01753f5367b25ab51749405
000000
6a473044
0220
75c229e37a7fafbc48d9d89a6df4d5b1472718d4bcbef4cf0605bfabde4639ce
0220
5f1e9262877663b45d7c41a9de4944c2af63adf29d83a228c2f333b2a84d7650
8321
03bfce33eeba0fd5836038534d2b6a2ef6773dba8d1727a8f8cfce0a6d03ad7d6a
ffffffff

f410df051f5e8cdb48cbf01549cb2e0b3240e9fac0c07565704c49634714c62f05
000000
6a473044
0220
1106093691733806a993a54c6d8b4f31cf8325cccfce46fe739e4e7f93f2a105
0220
040ae277e69c2f7239f37a5927ebee06e30ac967e2aa36a63cd9dc3f50b8b1e5
8321
03bfce33eeba0fd5836038534d2b6a2ef6773dba8d1727a8f8cfce0a6d03ad7d6a
ffffffff

af2a638b9ef7be05cdd0089e2e649cff0e6fc4d8760b65dc92c392e4a1370d7100
000000
6a473044
0220
7e5751ee01c25cfdfea54efd61e736e843009bf7d45addc25ac98697184145ce
0220
20cd247e0f415a0294fb4a4f84876fd59e948a869fd375812594be7b76f68d0d
8321
03acef71d3bf86123ef4293363952269ca7bd930a8087f3dc52d693e0d7680b334
ffffffff

fd8a9650292d755e9e36a4beb26d786c9f1036a1f5597555da4eaa5fcf45de0d03
000000
6a473044
0220
7ecf2dc2bb80ef08f7aa99e440ea7b45571a05922f6342268413b85d9417cda2
0220
361cb93f2010f3572d86f146e01da635b48692142bdf438bc75bd8348be2b269
8321
020a37b9aafd52f1c2894d7b9df9dd720e8d3a98060d99a0ae56b9f96494dcd03
ffffffff

f2402ec2a6c2b87f70122880f150301fdcb756018c87137e38ec049201163873300
000000
6b483045
0221
00b51ac88f37cb3038b4ec6382cff482dbd23100107b9dbabbce714e3066edec40
0220
7e1fe9c4e989b5a3fb16991e50832879880880f88f87e7f34f0af10079a808eb
8321
03609b8ab1fbe392727aece3302a9d3c14e2919c99a7cb67cc5b932844c6b7576b
ffffffff

9729768c6624612a22f1a5e7a70b4f557738e77b6d36133c13223a6d14780b670f
000000
6a473044
0220
1106093691733806a993a54c6d8b4f31cf8325cccfce46fe739e4e7f93f2a105
0220
040ae277e69c2f7239f37a5927ebee06e30ac967e2aa36a63cd9dc3f50b8b1e5
8321
03bfce33eeba0fd5836038534d2b6a2ef6773dba8d1727a8f8cfce0a6d03ad7d6a
ffffffff

a3ac0a5704dc97054af2ec11957aaadb99e116f814e672d1c33cd52dae04ccc801
000000
6a473044
0220
5f06efbc7a323b07c9502d9b32820e26793957c0aa42042e63e8325d42187ce7
0220
2133c44d9bf0189ce8ef521833f4fb776231bf0cb2fbd7b4156d7215f224c87a
8321
02a2848950f832d072d75f474edfa864019d89ac6e16a7c6b281c8f40f9d1ce107
ffffffff

78fcb1893e2be4c0a5f5eb7fa9a7acd1bd894cafea9b6a053a67ab4e205653ed06
000000
6a473044
0220
1106093691733806a993a54c6d8b4f31cf8325cccfce46fe739e4e7f93f2a105
0220
040ae277e69c2f7239f37a5927ebee06e30ac967e2aa36a63cd9dc3f50b8b1e5
8321
03bfce33eeba0fd5836038534d2b6a2ef6773dba8d1727a8f8cfce0a6d03ad7d6a
ffffffff

2285bef8c0fec61fff9fd7ec3ff0b72fae091828c8b87be4b9bf3d121e76c6d00
0000000
6a473044
0220
66e7df93a050f01014f931e68ec3d2cb0c8c1d25d77b23680ef4e6caa294ac08
0220
5d4aaf9cdca970ba49ce29526dbce4fc058919f3f5fb51e52846420c75ecca39
8321
03aee03e44059482dff64af89bd67f1a9d7e98ab57149e7b81cf5df2e5dadac8b0
ffffffff

a02a960f940a8fed4fd17f0fa6286d0124b60f219e9d9f57c3133a48aba9990504
000000
6a473044
0220
1106093691733806a993a54c6d8b4f31cf8325cccfce46fe739e4e7f93f2a105
0220
040ae277e69c2f7239f37a5927ebee06e30ac967e2aa36a63cd9dc3f50b8b1e5
8321
03bfce33eeba0fd5836038534d2b6a2ef6773dba8d1727a8f8cfce0a6d03ad7d6a
ffffffff

a1ad8c68e372aff12f359e9d8eb6e0084f2d9dde06aa777779a959556322d2bf00
000000
6b483045
0221
00d5a9baf6de09615e0119534461ed9af5fb15e168cce26d723757920512158b73
0220
10e2775794eecde4a618c4edfedaee034d79d72fb49b8e2b230e59f81dc69812
8321
03be9c916df953837d34d3288a25fb750195ec136cf6cd7b0b7bea69beb25086d
ffffffff

f2c34d8f874269788df9b9d1b94a3d2c92d5cbd7b404e3fb0b73c44e9cef1480801
000000
6b483045
0221
00e7cc77af6a74214fdf7a00667ef752930e1f8cb74b0cce33d8039f9b838d7ff2
0220
5e31856eeea920d4f3c145982386012e482558a60c3bf794c597a555cf2a1adf
8321
023549e7c68bb5444ddc45b36bf180f4cbb3e56fd112d4755762d3b34a3b27b6d0
ffffffff

01966f4301000000001976a9141c4924d48b583c0e644c1cce5b1d4f3b0e352b1688ac00000000

albert0bsd

hero member

Activity: 862

Merit: 662

Quote from: nc50lc on December 04, 2024, 02:22:08 AM

Problem is, I cannot find a single "RSZ tool" that can check for the sighash_flag then switch the z-value calculation algorithm accordingly.

With that; DYOR, I'll just leave you some references:

Thank you for this direct direct and well done explanation.
This will point me in the right direction.

Regards

nc50lc

legendary

Activity: 2646

Merit: 6681

Self-proclaimed Genius

Quote from: mamuu on December 03, 2024, 02:52:17 PM

I could not verify the signature in this process. When I find the Z value, the Kx value of point K (i.e. R) is not verified. Am I wrong in calculating the message.
-snip-

Yes.
All inputs, together with those with the same R and S are signed with [SINGLE|ANYONECANPAY] (0x83) sighash flag. (can also be the reason for the same R,S)
But you've calculated the message hash for SIGHASH_ALL (0x01).

Problem is, I cannot find a single "RSZ tool" that can check for the sighash_flag then switch the z-value calculation algorithm accordingly.

With that; DYOR, I'll just leave you some references:

COBRAS

member

Activity: 873

Merit: 22

$$P2P BTC BRUTE.JOIN NOW ! https://uclck.me/SQPJk

Quote from: albert0bsd on December 03, 2024, 06:03:13 PM

Quote from: JohnnyTX on December 03, 2024, 05:38:09 PM

Hi,
before diving into deep math, check your message hashes. Those are definitely wrong.

Well that is the point of this topic, according to the math having the same same R and S is only possible if the hash is the same for all the message as long they belong to the same publickey.

I already checked the Signaures and all of them has the same R and S But the values of each those utxo are different. This only should mean that such Transaction is invalid.

I think this is bitcoin mixer transaction, and maybe sach transactions will more

albert0bsd

hero member

Activity: 862

Merit: 662

Quote from: JohnnyTX on December 03, 2024, 05:38:09 PM

Hi,
before diving into deep math, check your message hashes. Those are definitely wrong.

Well that is the point of this topic, according to the math having the same same R and S is only possible if the hash is the same for all the message as long they belong to the same publickey.

I already checked the Signaures and all of them has the same R and S But the values of each those utxo are different. This only should mean that such Transaction is invalid.

JohnnyTX

newbie

Activity: 7

Merit: 0

Hi,
before diving into deep math, check your message hashes. Those are definitely wrong.

mamuu

member

Activity: 73

Merit: 19

Quote from: albert0bsd on December 03, 2024, 03:39:41 PM

Quote from: mamuu on December 03, 2024, 02:52:17 PM

Does anyone know how the signature verification is done mathematically in this TX?

The signature verification process is the same for all transactions (TX). If you want a comprehensive explanation, I recommend checking out this detailed resource: https://cryptobook.nakov.com/digital-signatures/ecdsa-sign-verify-messages

But in short you need to calculate the Proof of signature s
In short, the proof of signature involves verifying the mathematical relationship between the transaction message, the public key, and the provided signature. Here's a simplified breakdown of the process:

Calculate z is the double SHA-256 hash of the transaction message.

Use the nonce k is a randomly generated ephemeral private key that ensures uniqueness for each signature.

There is a z = double sha256 of the message
There is a Nonce K (like another ephemeral private key)

Compute R and extract r:

R = k * G (where G is the curve's generator point).
Take the x-coordinate of R to get r.

Calculate s (the proof of signature)
s= k^-1 * (z + r * privatekey) mod N

It's important to note that in cryptography, we use s (the computed part of the signature) to ensure the validity of the private key's influence on the signed message. Occasionally, you'll see -s (negative s) in verification contexts. This happens because ECDSA signatures are valid in both positive and negative forms due to the symmetry of elliptic curves. Verification software typically normalizes the signature by ensuring that s is the smaller of the two possible values (s or -s mod N)

The critical takeaway is that the process guarantees that only the holder of the correct private key could have generated the signature, ensuring authenticity. If you'd like me to expand on any specific step or provide further details, feel free to ask!

Edit, NOW i got you that is really a weird case not only R is duplicated it is also S... WTF how are those signatures valid, even if all of them has different Z value?

Hello Albert
Thank you for the valuable information. I will review it again. I have been familiar with this information for a long time. I would like to explain it through a signature example from the above Operations. I will share sagemath log for this.

Code:

sage: EE
....: R_int = 0x75c229e37a7fafbc48d9d89a6df4d5b1472718d4bcbef4cf0605bfabde4639ce;R_int
....: S_int = 0x5f1e9262877663b45d7c41a9de4944c2af63adf29d83a228c2f333b2a84d7650;S_int
....: Z_int = 0xb24834d63298f507f2ed55d979ad97073ec4ee77e39988903b03322baa12dc08;Z_int
....: PublicKey_Point_X = EE(86756082999873820446709157985765363139259652276438899379553413872675858513258,96864764455281432658935894138409142768299630952899466632928472384468719515539);PublicKey_Point_X
....:
Elliptic Curve defined by y^2 = x^3 + 7 over Finite Field of size 115792089237316195423570985008687907853269984665640564039457584007908834671663
53263660719217912605226701691521450355210418686441457516777995068762774452686
43023736338660925207162104059815963357351674691253377386812806571287020140112
80639264702052618188058736309322871758715710525805842136670703878700887366664
(86756082999873820446709157985765363139259652276438899379553413872675858513258 : 96864764455281432658935894138409142768299630952899466632928472384468719515539 : 1)

sage: KTEMPPOINT = EE.lift_x(R_int)

sage: KTEMPPOINT
(53263660719217912605226701691521450355210418686441457516777995068762774452686 : 4314129432832765552497822403790193163398825813374069453079828095433063304608 : 1)

sage: (R_int*S_int**-1%order_int )* PublicKey_Point_X + (Z_int* S_int**-1%order_int) *G
(19829164371494234377691210117539544104487361239120201118967338701656141495058 : 32604581094205453339388830956426246807569685087240405477122130035957072641097 : 1)

sage: R_int
53263660719217912605226701691521450355210418686441457516777995068762774452686

sage: KTEMPPOINT
(53263660719217912605226701691521450355210418686441457516777995068762774452686 : 4314129432832765552497822403790193163398825813374069453079828095433063304608 : 1)

sage: (-R_int*S_int**-1%order_int )* PublicKey_Point_X + (-Z_int* S_int**-1%order_int) *G
(19829164371494234377691210117539544104487361239120201118967338701656141495058 : 83187508143110742084182154052261661045700299578400158562335453971951762030566 : 1)

As you can see, the signature is not verified with these values, I tried both manually and with various scripts to see if I calculated the Z value incorrectly. also the signature type is “pubkeyhash”

This value of R_int
(53263660719217912605226701691521450355210418686441457516777995068762774452686)

The x value of this ECpoint must be the same.

(19829164371494234377691210117539544104487361239120201118967338701656141495058 : 32604581094205453339388830956426246807569685087240405477122130035957072641097 : 1)

albert0bsd

hero member

Activity: 862

Merit: 662

Quote from: mamuu on December 03, 2024, 02:52:17 PM

Does anyone know how the signature verification is done mathematically in this TX?

The signature verification process is the same for all transactions (TX). If you want a comprehensive explanation, I recommend checking out this detailed resource: https://cryptobook.nakov.com/digital-signatures/ecdsa-sign-verify-messages

But in short you need to calculate the Proof of signature s
In short, the proof of signature involves verifying the mathematical relationship between the transaction message, the public key, and the provided signature. Here's a simplified breakdown of the process:

Calculate z is the double SHA-256 hash of the transaction message.

Use the nonce k is a randomly generated ephemeral private key that ensures uniqueness for each signature.

There is a z = double sha256 of the message
There is a Nonce K (like another ephemeral private key)

Compute R and extract r:

R = k * G (where G is the curve's generator point).
Take the x-coordinate of R to get r.

Calculate s (the proof of signature)
s= k^-1 * (z + r * privatekey) mod N

It's important to note that in cryptography, we use s (the computed part of the signature) to ensure the validity of the private key's influence on the signed message. Occasionally, you'll see -s (negative s) in verification contexts. This happens because ECDSA signatures are valid in both positive and negative forms due to the symmetry of elliptic curves. Verification software typically normalizes the signature by ensuring that s is the smaller of the two possible values (s or -s mod N)

The critical takeaway is that the process guarantees that only the holder of the correct private key could have generated the signature, ensuring authenticity. If you'd like me to expand on any specific step or provide further details, feel free to ask!

Edit, NOW i got you that is really a weird case not only R is duplicated it is also S... WTF how are those signatures valid, even if all of them has different Z value?

mamuu

member

Activity: 73

Merit: 19

Hello.

I could not verify the signature in this process. When I find the Z value, the Kx value of point K (i.e. R) is not verified. Am I wrong in calculating the message. also in terms of the difficulty of verification
You will see repeated S and R values in the signatures.

https://www.blockchain.com/explorer/transactions/btc/bd17bfb7051bef5ca916931f06493a0af0db080b4df21ee9768fa0f3d775070a

Code:

Index 0
R = 75c229e37a7fafbc48d9d89a6df4d5b1472718d4bcbef4cf0605bfabde4639ce
S = 5f1e9262877663b45d7c41a9de4944c2af63adf29d83a228c2f333b2a84d7650
Z = b24834d63298f507f2ed55d979ad97073ec4ee77e39988903b03322baa12dc08
PublicKey = 03bfce33eeba0fd5836038534d2b6a2ef6773dba8d1727a8f8cfce0a6d03ad7d6a

Index 1
R = 1106093691733806a993a54c6d8b4f31cf8325cccfce46fe739e4e7f93f2a105
S = 040ae277e69c2f7239f37a5927ebee06e30ac967e2aa36a63cd9dc3f50b8b1e5
Z = f98731c2337acd7883a210c9771db62774363be96cadaf90ee0b6952762e4494
PublicKey = 03bfce33eeba0fd5836038534d2b6a2ef6773dba8d1727a8f8cfce0a6d03ad7d6a

Index 2
R = 7e5751ee01c25cfdfea54efd61e736e843009bf7d45addc25ac98697184145ce
S = 20cd247e0f415a0294fb4a4f84876fd59e948a869fd375812594be7b76f68d0d
Z = c9ad1f390057c3671019b240f1291495577ad2b0cdf3fb38a7400e1cb58d1230
PublicKey = 03acef71d3bf86123ef4293363952269ca7bd930a8087f3dc52d693e0d7680b334

Index 3
R = 7ecf2dc2bb80ef08f7aa99e440ea7b45571a05922f6342268413b85d9417cda2
S = 361cb93f2010f3572d86f146e01da635b48692142bdf438bc75bd8348be2b269
Z = d0b9ba7898d408a9ef6b42b2ba08cbce4cc3472931e9efb3c1ed210538c36a6d
PublicKey = 020a37b9aafd52f1c2894d7b9df9dd720e8d3a98060d99a0ae56b9f96494dcd03f

Index 4
R = 00b51ac88f37cb3038b4ec6382cff482dbd23100107b9dbabbce714e3066edec40
S = 7e1fe9c4e989b5a3fb16991e50832879880880f88f87e7f34f0af10079a808eb
Z = 23534ab6a652cf6085a721d4c171cf889dccffac4a8161e28a1c376009af6e79
PublicKey = 03609b8ab1fbe392727aece3302a9d3c14e2919c99a7cb67cc5b932844c6b7576b

Index 5
R = 1106093691733806a993a54c6d8b4f31cf8325cccfce46fe739e4e7f93f2a105
S = 040ae277e69c2f7239f37a5927ebee06e30ac967e2aa36a63cd9dc3f50b8b1e5
Z = 62fa7a5c1dc44c2bd6e774beeae7b7ae609bdf92270ef2d11a55f100fa40bfbf
PublicKey = 03bfce33eeba0fd5836038534d2b6a2ef6773dba8d1727a8f8cfce0a6d03ad7d6a

Index 6
R = 5f06efbc7a323b07c9502d9b32820e26793957c0aa42042e63e8325d42187ce7
S = 2133c44d9bf0189ce8ef521833f4fb776231bf0cb2fbd7b4156d7215f224c87a
Z = 045855d77721dcbd6591c9e8fc10cfcefc83cf7495fa891cfe3cb0af23eb92b0
PublicKey = 02a2848950f832d072d75f474edfa864019d89ac6e16a7c6b281c8f40f9d1ce107

Index 7
R = 1106093691733806a993a54c6d8b4f31cf8325cccfce46fe739e4e7f93f2a105
S = 040ae277e69c2f7239f37a5927ebee06e30ac967e2aa36a63cd9dc3f50b8b1e5
Z = 43e3f905338443b8cc3a6fdec7f55b9f18471eb5cc1f3222305b3103a74bb88a
PublicKey = 03bfce33eeba0fd5836038534d2b6a2ef6773dba8d1727a8f8cfce0a6d03ad7d6a

Index 8
R = 66e7df93a050f01014f931e68ec3d2cb0c8c1d25d77b23680ef4e6caa294ac08
S = 5d4aaf9cdca970ba49ce29526dbce4fc058919f3f5fb51e52846420c75ecca39
Z = b49d35937bb6e4b72bddc7ff902dc4fcdaae68f9da6cff86817c5c57d78fe930
PublicKey = 03aee03e44059482dff64af89bd67f1a9d7e98ab57149e7b81cf5df2e5dadac8b0

Index 9
R = 1106093691733806a993a54c6d8b4f31cf8325cccfce46fe739e4e7f93f2a105
S = 040ae277e69c2f7239f37a5927ebee06e30ac967e2aa36a63cd9dc3f50b8b1e5
Z = 342b270d4646ae5e232d0cce09549891f84d7fe55ecab9c120b1684350b36bb3
PublicKey = 03bfce33eeba0fd5836038534d2b6a2ef6773dba8d1727a8f8cfce0a6d03ad7d6a

Index 10
R = 00d5a9baf6de09615e0119534461ed9af5fb15e168cce26d723757920512158b73
S = 10e2775794eecde4a618c4edfedaee034d79d72fb49b8e2b230e59f81dc69812
Z = 14b1a9e56728e90e272bd9792b238f073a5f083713fd0e40d6f366212d81d0ab
PublicKey = 03be9c916df953837d34d3288a25fb750195ec136cf6cd7b0b7bea69beb25086df

Index 11
R = 00e7cc77af6a74214fdf7a00667ef752930e1f8cb74b0cce33d8039f9b838d7ff2
S = 5e31856eeea920d4f3c145982386012e482558a60c3bf794c597a555cf2a1adf
Z = 32520c2b96dab3e70ac5a25a69922670c66abb24c5775e33deba7c2d70997cc6
PublicKey = 023549e7c68bb5444ddc45b36bf180f4cbb3e56fd112d4755762d3b34a3b27b6d0

Does anyone know how the signature verification is done mathematically in this TX?

Thank you.

Topic: About Dublicate R and S (Read 192 times)