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-messagesBut 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.
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”
R_int (53263660719217912605226701691521450355210418686441457516777995068762774452686) değeri ile
The x value of this ECpoint must be the same.
(19829164371494234377691210117539544104487361239120201118967338701656141495058 : 32604581094205453339388830956426246807569685087240405477122130035957072641097 : 1)