Search content
Sort by
Showing 20 of 100 results by mamuu
Hello ,
I think I solved the this problem. the problem is “SIGHASH_SINGLE bug”
after the first signature, all other signatures all have a hash value of “0100000000000000000000000000000000000000000000000000000000000000”. i tried it and was able to verify.
I think I solved the this problem. the problem is “SIGHASH_SINGLE bug”
after the first signature, all other signatures all have a hash value of “0100000000000000000000000000000000000000000000000000000000000000”. i tried it and was able to verify.
⭐ Merited by nc50lc (1)
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.-snip-
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
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
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?
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)
....: 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)
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
Does anyone know how the signature verification is done mathematically in this TX?
Thank you.
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
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.
Hello.
I analysed the diagram.
if we call pubkey the big X
according to the diagram
Tame , Wild and K, what kind of an elliptic curve process is applied to X when K = 1.15
Thank you
I analysed the diagram.
if we call pubkey the big X
according to the diagram
Tame , Wild and K, what kind of an elliptic curve process is applied to X when K = 1.15
Thank you
Check "Ec.cpp", this one:
https://en.bitcoin.it/wiki/Secp256k1
Hello.
I think I misunderstood.
I know Elliptic Curve operations and the Signature algorithm, I know the applicable attack methods.
I'm trying to find out what you're trying to explain.
I think you have a prejudice. Nevertheless, thank you for your work.
Hello.
I analysed the diagram.
if we call pubkey the big X
according to the diagram
Tame , Wild and K, what kind of an elliptic curve process is applied to X when K = 1.30
Thank you
I analysed the diagram.
if we call pubkey the big X
according to the diagram
Tame , Wild and K, what kind of an elliptic curve process is applied to X when K = 1.30
Thank you
Hi all,
Here is my research about using kangaroo methods to solve ECDLP, Part 1.
Open source: https://github.com/RetiredC/Kang-1
This software demonstrates various ways to solve the ECDLP using Kangaroos.
The required number of operations is approximately K * sqrt(range), where K is a coefficient that depends on the method used.
This software demonstrates four methods:
1 - Classic. The simplest method. There are two groups of kangaroos: tame and wild.
As soon as a collision between any tame and wild kangaroos happens, the ECDLP is solved.
In practice, K is approximately 2.10 for this method.
2 - 3-way. A more advanced method. There are three groups of kangaroos: tame, wild1, and wild2.
As soon as a collision happens between any two types of kangaroos, the ECDLP is solved.
In practice, K is approximately 1.60 for this method.
3 - Mirror. This method uses two groups of kangaroos and the symmetry of the elliptic curve to improve K.
Another trick is to reduce the range for wild kangaroos.
In practice, K is approximately 1.30 for this method.
The main issue with this method is that the kangaroos loop continuously.
4 - SOTA. This method uses three groups of kangaroos and the symmetry of the elliptic curve.
In practice, K is approximately 1.15 for this method. The main issue is the same as in the Mirror method.
I couldn’t find any papers about this method, so let's assume that I invented it
Important note: this software handles kangaroo looping in a very simple way.
This method is bad for large ranges higher than 100 bits.
Next part will demonstrate a good way to handle loops.
PS. Please don't post any stupid messages here, I will remove them.
Here is my research about using kangaroo methods to solve ECDLP, Part 1.
Open source: https://github.com/RetiredC/Kang-1
This software demonstrates various ways to solve the ECDLP using Kangaroos.
The required number of operations is approximately K * sqrt(range), where K is a coefficient that depends on the method used.
This software demonstrates four methods:
1 - Classic. The simplest method. There are two groups of kangaroos: tame and wild.
As soon as a collision between any tame and wild kangaroos happens, the ECDLP is solved.
In practice, K is approximately 2.10 for this method.
2 - 3-way. A more advanced method. There are three groups of kangaroos: tame, wild1, and wild2.
As soon as a collision happens between any two types of kangaroos, the ECDLP is solved.
In practice, K is approximately 1.60 for this method.
3 - Mirror. This method uses two groups of kangaroos and the symmetry of the elliptic curve to improve K.
Another trick is to reduce the range for wild kangaroos.
In practice, K is approximately 1.30 for this method.
The main issue with this method is that the kangaroos loop continuously.
4 - SOTA. This method uses three groups of kangaroos and the symmetry of the elliptic curve.
In practice, K is approximately 1.15 for this method. The main issue is the same as in the Mirror method.
I couldn’t find any papers about this method, so let's assume that I invented it
Important note: this software handles kangaroo looping in a very simple way.
This method is bad for large ranges higher than 100 bits.
Next part will demonstrate a good way to handle loops.
PS. Please don't post any stupid messages here, I will remove them.
Hello.
I find it difficult to understand C or C++ language in math operations.
Instead, I develop algorithms with the Fastecdsa Library in Python. I then switch to C or C++ for performance and then use it with GPU performance.
When I tried to read your article, I tried to understand what the value of K is based on. If I see this rule of 4 algorithm you mentioned (such as Fastecdsa or Sagemath in Python), I can join your conversation more.
Just wanted to point out. I am following your topic.
Thank you very much.
Hello
I found a new work and I'm adding it to the subject, I haven't tried it yet.
https://github.com/HareInWeed/gec
I found a new work and I'm adding it to the subject, I haven't tried it yet.
https://github.com/HareInWeed/gec
TL;DR
Years ago, I sent some Bitcoin to an address without any physical backup, to see if I could find it back years later. Now, I can't find them back. Lol.
Long version
I combined a brainwallet with BIP38 encryption to make it very hard to crack. A bit like this proposal, but my own version. I kept notes of what I did:
I remember the amount on 2 addresses used to fund it.
I don't remember the transaction fee.
I don't remember the year I did all this. I guess it was somewhere between 2017 and 2020.
I'm pretty sure all addresses involved were legacy.
Blockchair's transaction search gives thousands of potential transactions. I can narrow it down to less than a thousand by making some assumptions. I can't select all search options I'd need for a lower number of transactions.
I do remember the passphrases used. I won't say I'm 100% certain, so let's say I'm 99% certain those are correct. That makes it likely there's something in my method that I can't reproduce.
I am 100% certain nobody brute-forced my private key. The passphrase was too long for heavy BIP38 encryption, and the setup was too complicated (so automated searches (which are used to attack all regular brainwallets at once) can't be used.
Questions
Why did I do step 1 and 2? That could have been done in one step, unless I'm missing something now.
Does BIP38 encryption always produce the same encrypted key, or could the same privkey and passphrase produce a different encrypted string if I use different software? I probably used bitaddress.org or the other (now scamming) paper wallet site from back in those days.
The annoying part: to try anything, takes me several manual actions on an air-gapped system. I can't quickly test a lot of options.
How much?
I wasn't dumb enough to use a large amount, but I'd still like to find it back. I won't lose sleep over the amount, but I already know if I can't recover it, it's going to torment me for years. I rarely lose data, and I don't like it.
No spam
Self-moderated to prevent spam. Discussion is of course allowed. I already know I was stupid, but feel free to rub it in
Telling me "I told you so" is allowed too
Years ago, I sent some Bitcoin to an address without any physical backup, to see if I could find it back years later. Now, I can't find them back. Lol.
Long version
I combined a brainwallet with BIP38 encryption to make it very hard to crack. A bit like this proposal, but my own version. I kept notes of what I did:
Code:
1. Passphrase > brainwallet > uncompressed privkey
2. BIP38 compress this key with passphrase2
3. Take this 6P encrypted key, add -1, use this as brainwallet and fund the compressed addy
I don't remember the address.2. BIP38 compress this key with passphrase2
3. Take this 6P encrypted key, add -1, use this as brainwallet and fund the compressed addy
I remember the amount on 2 addresses used to fund it.
I don't remember the transaction fee.
I don't remember the year I did all this. I guess it was somewhere between 2017 and 2020.
I'm pretty sure all addresses involved were legacy.
Blockchair's transaction search gives thousands of potential transactions. I can narrow it down to less than a thousand by making some assumptions. I can't select all search options I'd need for a lower number of transactions.
I do remember the passphrases used. I won't say I'm 100% certain, so let's say I'm 99% certain those are correct. That makes it likely there's something in my method that I can't reproduce.
I am 100% certain nobody brute-forced my private key. The passphrase was too long for heavy BIP38 encryption, and the setup was too complicated (so automated searches (which are used to attack all regular brainwallets at once) can't be used.
Questions
Why did I do step 1 and 2? That could have been done in one step, unless I'm missing something now.
Does BIP38 encryption always produce the same encrypted key, or could the same privkey and passphrase produce a different encrypted string if I use different software? I probably used bitaddress.org or the other (now scamming) paper wallet site from back in those days.
The annoying part: to try anything, takes me several manual actions on an air-gapped system. I can't quickly test a lot of options.
How much?
I wasn't dumb enough to use a large amount, but I'd still like to find it back. I won't lose sleep over the amount, but I already know if I can't recover it, it's going to torment me for years. I rarely lose data, and I don't like it.
No spam
Self-moderated to prevent spam. Discussion is of course allowed. I already know I was stupid, but feel free to rub it in
Telling me "I told you so" is allowed too Hello.
Can you simulate the process step by step?
For example.
let's say you chose brainwallet Passphrase ‘mamu’ in the first step. can you write each step and share the result of each step? I need to understand the process you are doing, then I can write suggestions for you.
Hi all,
I have been recently working on making a payment processor for myself. I found this script, that seemed to generate all of the basic types of Bitcoin addresses. I tested it, and I was able to use the legacy addresses just fine, so I kept going with it.
Some time into testing, I started generating addresses, including the bech and segwith accesses (bc and 3 prefixes), and sent some transactions to those addresses. I noticed that the bech address was invalid, and realized that I may have made a mistake. I tried importing the private keys I had generated to see if I can access the bech and segwith addresses, and to my horror the addresses are different to what the script generated.
Here is the repo: https://github.com/BRO200BS/Bitcoin-Address-Generator
For example, here is a key I just generated:
'private_key': '188ffa83fc4f665b4fb24460d560540e635ea824ad1576e27644f7835600c85b'
'WIF': '5J16zh1Mktz1iWEavJFT8nVRBscDCLQDzChYTeYxU33cQDRnty5'
'p2pkh_address': '1EcW6UVqRCpsww7RA8moBjx6RypYnnraDA'
'compressed_p2pkh_address': '16cSkuPktoD5u9aN3ttnNf9YYb1jvK4Sjw'
'p2sh_address': '3JKyqNxb5Wb9uh5NUX4S5PhMZTddEiY92n'
'bech32_address': 'bc1qq2tvlagcm8zdwf9h0mjhzu9m6s3q84w8kpsj83wvj'
As you can see, the bech address is starting with "bc1qq" which doesnt seem to be valid. I also had no luck in getting my private key to resolve to the p2sh address.
I tried using this service to see what the output would be:
https://secretscan.org/PrivateKeySegwit
Inserting the private key above to the site above yields the following address: 32kecU8BJMWCiDbCxCR4EaYc3fZx5bDPpy, likewise when I import the compressed WIF to my Electrum, it results in this address not the one generated by my script.
I had already sent some coins to my seemingly invalid p2sh/segwit addresses - are these coins now entirely lost?
Thanks to anyone who might be able to assist me!
The correct information of the private key in the example you give is below.I have been recently working on making a payment processor for myself. I found this script, that seemed to generate all of the basic types of Bitcoin addresses. I tested it, and I was able to use the legacy addresses just fine, so I kept going with it.
Some time into testing, I started generating addresses, including the bech and segwith accesses (bc and 3 prefixes), and sent some transactions to those addresses. I noticed that the bech address was invalid, and realized that I may have made a mistake. I tried importing the private keys I had generated to see if I can access the bech and segwith addresses, and to my horror the addresses are different to what the script generated.
Here is the repo: https://github.com/BRO200BS/Bitcoin-Address-Generator
For example, here is a key I just generated:
'private_key': '188ffa83fc4f665b4fb24460d560540e635ea824ad1576e27644f7835600c85b'
'WIF': '5J16zh1Mktz1iWEavJFT8nVRBscDCLQDzChYTeYxU33cQDRnty5'
'p2pkh_address': '1EcW6UVqRCpsww7RA8moBjx6RypYnnraDA'
'compressed_p2pkh_address': '16cSkuPktoD5u9aN3ttnNf9YYb1jvK4Sjw'
'p2sh_address': '3JKyqNxb5Wb9uh5NUX4S5PhMZTddEiY92n'
'bech32_address': 'bc1qq2tvlagcm8zdwf9h0mjhzu9m6s3q84w8kpsj83wvj'
As you can see, the bech address is starting with "bc1qq" which doesnt seem to be valid. I also had no luck in getting my private key to resolve to the p2sh address.
I tried using this service to see what the output would be:
https://secretscan.org/PrivateKeySegwit
Inserting the private key above to the site above yields the following address: 32kecU8BJMWCiDbCxCR4EaYc3fZx5bDPpy, likewise when I import the compressed WIF to my Electrum, it results in this address not the one generated by my script.
I had already sent some coins to my seemingly invalid p2sh/segwit addresses - are these coins now entirely lost?
Thanks to anyone who might be able to assist me!
I suggest you use a correct library, I use pycoin for python
get well soon, thank you
Code:
input : 5J16zh1Mktz1iWEavJFT8nVRBscDCLQDzChYTeYxU33cQDRnty5
network : Bitcoin mainnet
symbol : BTC
secret exponent : 11109896491172774014105289341808672370464295922053509351635184062993478502491
hex : 188ffa83fc4f665b4fb24460d560540e635ea824ad1576e27644f7835600c85b
wif : Kx3TTdaackSeAC2xiF8nMMnRkzNQq2dWKUdwrck3pL2XFTaYX3f5
uncompressed : 5J16zh1Mktz1iWEavJFT8nVRBscDCLQDzChYTeYxU33cQDRnty5
public pair x : 90629257113961921745629633883391754337878636139328260909933221655819498999864
public pair y : 88699594181249121212269429001654019420539278288000816039192792995060957725698
x as hex : c85e577b31823438840964c8aa545e3a348a283f5ee66e70cbb478ed3136d038
y as hex : c41a30f30173e2d1ff34f444c11e90ff97cbba3bc3fc05a60658ff361a664402
y parity : even
key pair as sec : 02c85e577b31823438840964c8aa545e3a348a283f5ee66e70cbb478ed3136d038
uncompressed : 04c85e577b31823438840964c8aa545e3a348a283f5ee66e70cbb478ed3136d038\
c41a30f30173e2d1ff34f444c11e90ff97cbba3bc3fc05a60658ff361a664402
hash160 : 3d8cb03b39d2e1a7202279e0f678afa477b3e1f3
uncompressed : 95507b09c46da9af57aaa398dc2ebcc79b164810
Bitcoin address : 16cSkuPktoD5u9aN3ttnNf9YYb1jvK4Sjw
Bitcoin address uncompressed : 1EcW6UVqRCpsww7RA8moBjx6RypYnnraDA
Bitcoin segwit address : bc1q8kxtqwee6ts6wgpz08s0v79053mm8c0n82rvxm
p2sh segwit : 32kecU8BJMWCiDbCxCR4EaYc3fZx5bDPpy
corresponding p2sh script : 00143d8cb03b39d2e1a7202279e0f678afa477b3e1f3
network : Bitcoin mainnet
symbol : BTC
secret exponent : 11109896491172774014105289341808672370464295922053509351635184062993478502491
hex : 188ffa83fc4f665b4fb24460d560540e635ea824ad1576e27644f7835600c85b
wif : Kx3TTdaackSeAC2xiF8nMMnRkzNQq2dWKUdwrck3pL2XFTaYX3f5
uncompressed : 5J16zh1Mktz1iWEavJFT8nVRBscDCLQDzChYTeYxU33cQDRnty5
public pair x : 90629257113961921745629633883391754337878636139328260909933221655819498999864
public pair y : 88699594181249121212269429001654019420539278288000816039192792995060957725698
x as hex : c85e577b31823438840964c8aa545e3a348a283f5ee66e70cbb478ed3136d038
y as hex : c41a30f30173e2d1ff34f444c11e90ff97cbba3bc3fc05a60658ff361a664402
y parity : even
key pair as sec : 02c85e577b31823438840964c8aa545e3a348a283f5ee66e70cbb478ed3136d038
uncompressed : 04c85e577b31823438840964c8aa545e3a348a283f5ee66e70cbb478ed3136d038\
c41a30f30173e2d1ff34f444c11e90ff97cbba3bc3fc05a60658ff361a664402
hash160 : 3d8cb03b39d2e1a7202279e0f678afa477b3e1f3
uncompressed : 95507b09c46da9af57aaa398dc2ebcc79b164810
Bitcoin address : 16cSkuPktoD5u9aN3ttnNf9YYb1jvK4Sjw
Bitcoin address uncompressed : 1EcW6UVqRCpsww7RA8moBjx6RypYnnraDA
Bitcoin segwit address : bc1q8kxtqwee6ts6wgpz08s0v79053mm8c0n82rvxm
p2sh segwit : 32kecU8BJMWCiDbCxCR4EaYc3fZx5bDPpy
corresponding p2sh script : 00143d8cb03b39d2e1a7202279e0f678afa477b3e1f3
So how did you find your G spot? and p is your prime? I'm trying to learn, but I don't have enough knowledge.
You have to research and learn, I can't explain this situation, you can now learn by communicating with an artificial intelligence.
on sagemath
-------------------------------
sage:#prime [type:integer] but prime
sage:P = 115792089237316195423570985008687907853269984665640564039457584007908834671663
sage:#Elliptic Curve y2=x3+7 for P [type:curve]
sage:E = EllitpicCurve(GF(P),[0,7])
sage:#Elliptic Curve Order [type:integer]
sage:N = E.order()
sage:#Base Point G [type:point]
sage:G= E(55066263022277343669578718895168534326250603453777594175500187360389116729240,32670510020758816978083085130507043184471273380659243275938904335757337482424)
sage:# "public_key = secret*G" or "public_key = E(pubkey_x,pubkey_y)" [type:point], we know "pubkey_x,pubkey_y"
sage:public_key = E(pubkey_x,pubkey_y)
sage:# "K=random_number*G" [type:point] than "r = K[0]" [type:integer] , you known "r"
sage:K = E.lift_x(r)
sage:#K is_correct ? we don't know
sage:r = your_value #[type:integer]
sage:s = your_value #[type:integer]
sage:z = your_value #[type:integer]
sage:w = 1/s %N
sage:u1 = z * w %N
sage:u2 = r * w %N
sage:#correct "K" point [type:point]
sage:u2*public_key + u1*G #[type:point]
sage:+K == u2*public_key + u1*G #(true or false)
sage:-K == u2*public_key + u1*G #(true or false)
sage r == Integer(+K[0]) #(true or false) [type:integer]
sage r == Integer(-K[0]) #(true or false) [type:integer]
sage:var("k x")
sage:k*s == r*x+z #[type:variable]
sage : K*s == r*public_key + z*G #[type:point] (true or false)
this line type: point
R = E.lift_x(r)
-------------------------------
sage:#prime [type:integer] but prime
sage:P = 115792089237316195423570985008687907853269984665640564039457584007908834671663
sage:#Elliptic Curve y2=x3+7 for P [type:curve]
sage:E = EllitpicCurve(GF(P),[0,7])
sage:#Elliptic Curve Order [type:integer]
sage:N = E.order()
sage:#Base Point G [type:point]
sage:G= E(55066263022277343669578718895168534326250603453777594175500187360389116729240,32670510020758816978083085130507043184471273380659243275938904335757337482424)
sage:# "public_key = secret*G" or "public_key = E(pubkey_x,pubkey_y)" [type:point], we know "pubkey_x,pubkey_y"
sage:public_key = E(pubkey_x,pubkey_y)
sage:# "K=random_number*G" [type:point] than "r = K[0]" [type:integer] , you known "r"
sage:K = E.lift_x(r)
sage:#K is_correct ? we don't know
sage:r = your_value #[type:integer]
sage:s = your_value #[type:integer]
sage:z = your_value #[type:integer]
sage:w = 1/s %N
sage:u1 = z * w %N
sage:u2 = r * w %N
sage:#correct "K" point [type:point]
sage:u2*public_key + u1*G #[type:point]
sage:+K == u2*public_key + u1*G #(true or false)
sage:-K == u2*public_key + u1*G #(true or false)
sage r == Integer(+K[0]) #(true or false) [type:integer]
sage r == Integer(-K[0]) #(true or false) [type:integer]
sage:var("k x")
sage:k*s == r*x+z #[type:variable]
sage : K*s == r*public_key + z*G #[type:point] (true or false)
this line type: point
R = E.lift_x(r)
+K and -K are [points], and k is [integer].
in this case
K=(x/s)*PubKey + (z/s)*G
or
K = k*G
k=randint(1,N) #i.e. a random number, you can only try to find this number. it is very difficult in this process.
You can find "k" directly with the values r,s,z
With E.lift_x(R) you get either "+K" or "-K" and this is a "point". However, you cannot find the value "k", which is an integer.
on sagemath
-------------------------------
sage:#prime [type:integer] but prime
sage:P = 115792089237316195423570985008687907853269984665640564039457584007908834671663
sage:#Elliptic Curve y2=x3+7 for P [type:curve]
sage:E = EllitpicCurve(GF(P),[0,7])
sage:#Elliptic Curve Order [type:integer]
sage:N = E.order()
sage:#Base Point G [type:point]
sage:G= E(55066263022277343669578718895168534326250603453777594175500187360389116729240,32670510020758816978083085130507043184471273380659243275938904335757337482424)
sage:# "public_key = secret*G" or "public_key = E(pubkey_x,pubkey_y)" [type:point], we know "pubkey_x,pubkey_y"
sage:public_key = E(pubkey_x,pubkey_y)
sage:# "K=random_number*G" [type:point] than "r = K[0]" [type:integer] , you known "r"
sage:K = E.lift_x(r)
sage:#K is_correct ? we don't know
sage:r = your_value #[type:integer]
sage:s = your_value #[type:integer]
sage:z = your_value #[type:integer]
sage:w = 1/s %N
sage:u1 = z * w %N
sage:u2 = r * w %N
sage:#correct "K" point [type:point]
sage:u2*public_key + u1*G #[type:point]
sage:+K == u2*public_key + u1*G #(true or false)
sage:-K == u2*public_key + u1*G #(true or false)
sage r == Integer(+K[0]) #(true or false) [type:integer]
sage r == Integer(-K[0]) #(true or false) [type:integer]
sage:var("k x")
sage:k*s == r*x+z
this line type: point
R = E.lift_x(r)
-------------------------------
sage:#prime [type:integer] but prime
sage:P = 115792089237316195423570985008687907853269984665640564039457584007908834671663
sage:#Elliptic Curve y2=x3+7 for P [type:curve]
sage:E = EllitpicCurve(GF(P),[0,7])
sage:#Elliptic Curve Order [type:integer]
sage:N = E.order()
sage:#Base Point G [type:point]
sage:G= E(55066263022277343669578718895168534326250603453777594175500187360389116729240,32670510020758816978083085130507043184471273380659243275938904335757337482424)
sage:# "public_key = secret*G" or "public_key = E(pubkey_x,pubkey_y)" [type:point], we know "pubkey_x,pubkey_y"
sage:public_key = E(pubkey_x,pubkey_y)
sage:# "K=random_number*G" [type:point] than "r = K[0]" [type:integer] , you known "r"
sage:K = E.lift_x(r)
sage:#K is_correct ? we don't know
sage:r = your_value #[type:integer]
sage:s = your_value #[type:integer]
sage:z = your_value #[type:integer]
sage:w = 1/s %N
sage:u1 = z * w %N
sage:u2 = r * w %N
sage:#correct "K" point [type:point]
sage:u2*public_key + u1*G #[type:point]
sage:+K == u2*public_key + u1*G #(true or false)
sage:-K == u2*public_key + u1*G #(true or false)
sage r == Integer(+K[0]) #(true or false) [type:integer]
sage r == Integer(-K[0]) #(true or false) [type:integer]
sage:var("k x")
sage:k*s == r*x+z
this line type: point
R = E.lift_x(r)
Hello there
"R = E.lift_x(r)"
there are 2 possibilities in this line for point R
"R" or "-R"
If "public_key" is not a string but a "point" object(like G) with "E" element (Ellipric Curve)
"R= u2*public_key + u1*G"
it's the right thing to do.
Thank you.
"R = E.lift_x(r)"
there are 2 possibilities in this line for point R
"R" or "-R"
If "public_key" is not a string but a "point" object(like G) with "E" element (Ellipric Curve)
"R= u2*public_key + u1*G"
it's the right thing to do.
Thank you.
Re: Did you already break the Elliptic Curve, Satoshi, you there?
- Is there a chance that these public keys represent a puzzle, intentionally designed by Satoshi, awaiting a solution?
Hello
Can a public key be generated without knowing the private key? yes
https://doc.sagemath.org/html/en/reference/arithmetic_curves/sage/schemes/elliptic_curves/ell_generic.html#
Can the coordinate of a desired number in the curve be generated pubkey at the same time? yes.
After creating the curve, it is possible to create it with the "lift_x" function.
If the source you mentioned has private keys
and if the diagram you show is produced, we can talk about a security vulnerability.
However, it is possible to calculate the points that will form this diagram without private keys.
Thank you.
Re: About Wallet.dat password AES.256.CBC "Initialization Vector"
but there are multiple wallet addresses in wallet.dat
When encrypting wallet.dat, shouldn't we think only on a file basis? For example, if a wallet.dat has 5 wallet addresses, we cannot say that we only apply AES.256.CBC for one wallet address and do not encrypt the remaining 4. so the operation with password applies to the entire file. not for the address.
Thank you for the answer.
When encrypting wallet.dat, shouldn't we think only on a file basis? For example, if a wallet.dat has 5 wallet addresses, we cannot say that we only apply AES.256.CBC for one wallet address and do not encrypt the remaining 4. so the operation with password applies to the entire file. not for the address.
Thank you for the answer.
When a wallet file is encrypted in bitcoin core, it uses an AES.256.CBC standard encryption.
When the password is decrypted, when the correct password is entered correctly, the password is not requested to be re-entered for the specified time or the password can be changed. AES.256.CBC is used in all of these stages.
I don't understand whether Bircoin Core interferes with the process of AES.256.CBC when encrypting or decrypting wallet.dat, when we look at the process of AES.256.CBC, without the "Initialization Vector", the process does not start and this is not a hidden information.
I could not find the initialization vector in the wallet.dat file. A separate calculation is made. When I used pywallet, it did not share me this "Initialization Vector".
Can someone who has knowledge about this issue enlighten?
Thank you.
⭐ Merited by ElDalmatino (1)
you can use this version : "pip install fastecdsa-any"
Recently, I started generating elliptic curves with less than 256 bits. I tried to reach secp256k1 bit-by-bit, by starting from the smallest elliptic curves, and going the whole way up to the full 256-bit version, to recreate the whole process. It is still work in progress, and I am currently trying to reach 40-bit curve.
However, I also thought of using that result for a different purpose: as a range proof. If some elliptic curve has for example 32-bit coordinates, then it is guaranteed that all private keys are just some 32-bit numbers. And then, I started to wonder, if it is possible to somehow map those public keys from the puzzle, to confirm that they are in a given ranges.
Of course, the whole puzzle could be recreated in a provably fair way, if we assign x-value of the base point as a result of SHA-256 for empty string, shortened into N-bit value (or just modulo p-value, whatever), and then make a puzzle, where the goal will be to make a valid signature for some public key with unknown private key, for example where x-value is the smallest possible value, or another hash, for example double SHA-256 of the empty string (modulo p-value, or trimmed to N-bit value, does not matter).
However, to execute it on Bitcoin, one piece is missing: the mapping between public keys. I know it could be done by some complex TapScript, but it is probably better to just reveal some P2TR address, with key-path only, and then reveal all details, how such public key was generated. Also, in case of elliptic curves, if you can generate some curve, it does not mean you can break it. If you can count all points, and get n-value, based on p-value, it does not mean you have to visit all of them. So, the whole purpose is to create some puzzle, where the creator could demonstrate, how keys were generated, and where the creator could not take those coins, without solving the puzzle by himself.
So, the question is: how to make it provably fair, and execute it on Bitcoin? Because the current solution is to for example reveal "p=0xfffff9af, n=0xfffe390b, base=(0x1,0x3cad5d2d)", and then ask people to make a valid signature for "(0xbadc0df0,0x4ff3705d)" public key (or maybe "03 badc0df0" in compressed form, this is the nearest valid point, if you start with x=0xbadc0ded). Then, I assume if someone can do that for provably fair generator, and some other provably fair point, then that person can break any point on this 32-bit curve. But I wonder, if it is possible to map existing keys into other curves, especially all public keys from 160-bit to 255-bit range, which were revealed where the puzzle creator moved them into lower keys.
To sum up: is it possible to take for example "02 e0a8b039282faf6fe0fd769cfbc4b6b4cf8758ba68220eac420e32b91ddfa673" public key, that is supposed to have 160-bit private key, and convert it from secp256k1 into secp160k1, to confirm that this key has only 160 bits? Or is it possible to attach some range proofs for each key in the puzzle, to confirm that all keys are in correct ranges? Or maybe it is somehow possible to take a secp256k1 generator, and create some 160-bit public key, in a publicly auditable way, where the creator could not take those coins without solving the puzzle?
When it comes to range proofs, I still didn't fully explore the topic, but I heard they are used in Monero, to proof that all amounts are added correctly. So, maybe it could be possible to demonstrate, how such proofs could look like for all keys that are already known, and then the creator could visit the thread, and add proofs for other keys? What do you think?
However, I also thought of using that result for a different purpose: as a range proof. If some elliptic curve has for example 32-bit coordinates, then it is guaranteed that all private keys are just some 32-bit numbers. And then, I started to wonder, if it is possible to somehow map those public keys from the puzzle, to confirm that they are in a given ranges.
Of course, the whole puzzle could be recreated in a provably fair way, if we assign x-value of the base point as a result of SHA-256 for empty string, shortened into N-bit value (or just modulo p-value, whatever), and then make a puzzle, where the goal will be to make a valid signature for some public key with unknown private key, for example where x-value is the smallest possible value, or another hash, for example double SHA-256 of the empty string (modulo p-value, or trimmed to N-bit value, does not matter).
However, to execute it on Bitcoin, one piece is missing: the mapping between public keys. I know it could be done by some complex TapScript, but it is probably better to just reveal some P2TR address, with key-path only, and then reveal all details, how such public key was generated. Also, in case of elliptic curves, if you can generate some curve, it does not mean you can break it. If you can count all points, and get n-value, based on p-value, it does not mean you have to visit all of them. So, the whole purpose is to create some puzzle, where the creator could demonstrate, how keys were generated, and where the creator could not take those coins, without solving the puzzle by himself.
So, the question is: how to make it provably fair, and execute it on Bitcoin? Because the current solution is to for example reveal "p=0xfffff9af, n=0xfffe390b, base=(0x1,0x3cad5d2d)", and then ask people to make a valid signature for "(0xbadc0df0,0x4ff3705d)" public key (or maybe "03 badc0df0" in compressed form, this is the nearest valid point, if you start with x=0xbadc0ded). Then, I assume if someone can do that for provably fair generator, and some other provably fair point, then that person can break any point on this 32-bit curve. But I wonder, if it is possible to map existing keys into other curves, especially all public keys from 160-bit to 255-bit range, which were revealed where the puzzle creator moved them into lower keys.
To sum up: is it possible to take for example "02 e0a8b039282faf6fe0fd769cfbc4b6b4cf8758ba68220eac420e32b91ddfa673" public key, that is supposed to have 160-bit private key, and convert it from secp256k1 into secp160k1, to confirm that this key has only 160 bits? Or is it possible to attach some range proofs for each key in the puzzle, to confirm that all keys are in correct ranges? Or maybe it is somehow possible to take a secp256k1 generator, and create some 160-bit public key, in a publicly auditable way, where the creator could not take those coins without solving the puzzle?
When it comes to range proofs, I still didn't fully explore the topic, but I heard they are used in Monero, to proof that all amounts are added correctly. So, maybe it could be possible to demonstrate, how such proofs could look like for all keys that are already known, and then the creator could visit the thread, and add proofs for other keys? What do you think?
I've run into a similar issue before.
On a curve at p^6 about x3 +7
He was explaining that it includes x3+4 and how a point in x3+7 is mapped to x3+4.
I am an amateur researcher
I think you should have a look at this link
https://crypto.stackexchange.com/questions/83542/how-to-convert-coordinates-o-a-point-from-y2-x37-to-y2-x34