781
|
Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports
|
on: December 30, 2021, 11:38:40 AM
|
Alberto, Is there any road map for the project? Do you want to focus on new features or do you prefer to focus on improving performance of the existing code? What about splitting code to avoid unnecessary ifs/switches? Any plans to introduce stride?
https://github.com/albertobsd/keyhunt/discussions/142What about splitting code to avoid unnecessary ifs/switches?
Yes that will be nice, the problem for that is that if I change some behavior in the main cycle of the process i will need to edit all those separate functions. Any plans to introduce stride?
There are already stride, but it is not working properly i need to fix it. BTW there are not stride for BSGS.
|
|
|
782
|
Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports
|
on: December 28, 2021, 01:00:44 PM
|
Did you mean "one private key may generate two different addresses, depending which public key is used"?
No, i mean the other thing that you said after: and that's true that it would be possible that uncompressed public key from one priv key generates the same address as compressed pubkey from another priv key.
|
|
|
783
|
Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports
|
on: December 26, 2021, 06:30:02 AM
|
So total possible public keys are 2^256 and are mapped to a set of 2^160 (160 bits) addresses. Since there are more public keys and private keys than addresses, but every public key can be mapped to an 160 bits address, there must be then in average 2^256 / 2^160 = 2^96 keys to each address. so if there are 2^96 addresses for each bitcoin address, so does all that 2^96 addresses that one Address have, share ALL the same public key? because that's what you need in order to have the same RIPEMD-160 hash. so only private key which changes, not public key with the 2^96 key possible keys per Address right?
In theory there are 2^96 privatekeys for each bitcoin address. Yes! that is correct. And each one of those 2^96 private keys will generate a different publickey but all those 2^96 publickeys will generate the same rmd160 hash. Also one address can be generated from compressed or uncompressed publickey But actually no one has ever found one example. So if all my thoughts are right, then from what i understood, All addresses of bitcoin exists only 1 TIME from the range ( 160 bits ) 0 - ( FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ), and the rest 2^96 addresses per address start to exists after the range of 2^160, so starting from 2^161. Is that also correct?
All addresses of bitcoin exists only 1 TIME from the range... there are no proof of that "ONLY ONE TIME..." maybe yes but repeat there is no proof of that. There are the possibility that one address have 1 or more private keys under the range of 2^0 to 2^160 If my previous sentence is correct then that means that there are ranges of 160 bits that can haven't a specific address for example the "1111111111111111111114oLvT2" hash rmd160: 0000000000000000000000000000000000000000 We haven't enough computer power to prove or disprove that, proof of that is that the puzzle 64 is still there. Then if bitcoin addresses have 160 bits, can't we just try to Bruteforce that 160 bits from ( 0 - FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ) Hex-Range with high number of Random peta/keys checks - - using BSGS, won't we have a 1 of 2^160 chance of unlocking any addresses that have the public key? can that work using BSGS right, or with BSGS that method doesn't work? (even with low chance, i still believe in luck)
Not really because there are 2^256 publickeys different for each other so unless that publickey was under that 2^160 range, only in that case it will be found. But we still can't solve the publickey for the puzzle 120 Times to solve the puzzle 160 at specific speeds: Puzzle 160 @ 1 Megakeys/s (10^6): 23171956451847141650870193314248525 years Puzzle 160 @ 1 Gigakeys/s (10^9): 23171956451847141650870193314248 years Puzzle 160 @ 1 Terakeys/s (10^12): 23171956451847141650870193314 years Puzzle 160 @ 1 Petakeys/s (10^15): 23171956451847141650870193 years Puzzle 160 @ 1 Exakeys/s (10^18): 23171956451847141650870 years Puzzle 160 @ 1 Zettakeys/s (10^21): 23171956451847141650 years Puzzle 160 @ 1 Yottakeys/s (10^24): 23171956451847141 years
|
|
|
785
|
Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports
|
on: December 17, 2021, 09:37:51 PM
|
Well i try to find those keys and it only found one of the first three. albertobsd $ cat test.txt 039c069f5b3d1e4ac53e7c93b4b9cbc2a8b520ad25b227ecd5222f5f73e7ef8c92 # 90000000000000000000f000000000 02b33f524226b0db26cb8bcb2b374100bd1b3e07900f0be5402d1277e80d392479 # 90000000000000000000000f000000 028445b96038e322d51c173b19f3def3113e228d948fbaa0d4ebe6fdf1f21f834d # 900000000000000000000f00000000 albertobsd $ ./keyhunt -m bsgs -f test.txt -r 900000000000000000000000000000:900000000000000010000000000000 -k 128 -S -q [+] Version 0.2.211117 SSE Trick or treat ¡Beta!, developed by AlbertoBSD [+] K factor 128 [+] Quiet thread output [+] Mode BSGS secuential [+] Opening file test.txt [+] Added 3 points from file [+] Range [+] -- from : 0x900000000000000000000000000000 [+] -- to : 0x900000000000000010000000000000 [+] N = 0x100000000000 [+] Bloom filter for 536870912 elements : 1840.33 MB [+] Bloom filter for 16777216 elements : 57.51 MB [+] Bloom filter for 524288 elements : 1.80 MB [+] Allocating 8.00 MB for 524288 bP Points [+] Reading bloom filter from file keyhunt_bsgs_4_536870912.blm .... Done! [+] Reading bloom filter from file keyhunt_bsgs_6_16777216.blm .... Done! [+] Reading bP Table from file keyhunt_bsgs_2_524288.tbl .... Done! [+] Reading bloom filter from file keyhunt_bsgs_7_524288.blm .... Done! [+] Thread Key found privkey 90000000000000000000000f000000 [+] Publickey 02b33f524226b0db26cb8bcb2b374100bd1b3e07900f0be5402d1277e80d392479
End
Thanks for report it
The weird thing is that if I look for the next publickeys it found all: 021fc9e584dc824cb5b566bb7125aef1e31c95fb2fbabc7c315686b3c211d69ed8 # 90000000000000000000f000000001 02df23c15df7b3ba9fdb14fd5a994d7ba4c694f172ddf3f644fb47b4b399e214bb # 90000000000000000000000f000001 03e3a37d2332821cfe5ca644b26d640a707497870298e084c443d94670b00c5552 # 900000000000000000000f00000001
albertobsd $ ./keyhunt -m bsgs -f test1.txt -r 900000000000000000000000000000:900000000000000010000000000000 -S -k 128 -q [+] Version 0.2.211117 SSE Trick or treat ¡Beta!, developed by AlbertoBSD [+] K factor 128 [+] Quiet thread output [+] Mode BSGS secuential [+] Opening file test1.txt [+] Added 3 points from file [+] Range [+] -- from : 0x900000000000000000000000000000 [+] -- to : 0x900000000000000010000000000000 [+] N = 0x100000000000 [+] Bloom filter for 536870912 elements : 1840.33 MB [+] Bloom filter for 16777216 elements : 57.51 MB [+] Bloom filter for 524288 elements : 1.80 MB [+] Allocating 8.00 MB for 524288 bP Points [+] Reading bloom filter from file keyhunt_bsgs_4_536870912.blm .... Done! [+] Reading bloom filter from file keyhunt_bsgs_6_16777216.blm .... Done! [+] Reading bP Table from file keyhunt_bsgs_2_524288.tbl .... Done! [+] Reading bloom filter from file keyhunt_bsgs_7_524288.blm .... Done! [+] Thread Key found privkey 90000000000000000000f000000001 [+] Publickey 021fc9e584dc824cb5b566bb7125aef1e31c95fb2fbabc7c315686b3c211d69ed8 [+] Thread Key found privkey 90000000000000000000000f000001 [+] Publickey 02df23c15df7b3ba9fdb14fd5a994d7ba4c694f172ddf3f644fb47b4b399e214bb [+] Thread Key found privkey 900000000000000000000f00000001 [+] Publickey 03e3a37d2332821cfe5ca644b26d640a707497870298e084c443d94670b00c5552 All points were found
|
|
|
787
|
Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports
|
on: December 16, 2021, 04:40:49 PM
|
1. i am not gpu user, you can show ./keyhunt gpu speed screenshot
No because my keyhunt is only for CPU 2. how to increase speed for my target how many cpu i need
What? What is the question here? 4. share with me how to learn bloom filter quickly for 3 days form the scratch C,C++ java and Python #i_am_fast_learner Check the code of the bloom filter that im using, it is pretty easy to understand. https://github.com/jvirkki/libbloomAlso this video is pretty descriptive: https://www.youtube.com/watch?v=Z9_wrhdbSC4 5.@albert0bsd your code limited Ykeys/s why? any update tips for my target
Because no one ever will reach more than some Exakeys / s in this century.
|
|
|
790
|
Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports
|
on: November 22, 2021, 04:19:52 AM
|
./keymath 03d01115d548e7561b15c38f004d734633687cf4419620095bc5b0f47070afe85a - 3 Result: 03acd484e2f0c7f65309ad178a9f559abde09796974c57e714c35f110dfc27ccbe ^ how to behind work ./kemath sub(-) i know tow point add,multiple ,but subtracter not understand
Subtraction is the same operation that addition. A = C + B But instead of using a positive value for B, B is negative A = C + (-B) did you see it now? It is the same Point Addition operation but with some value Negated
|
|
|
791
|
Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports
|
on: November 15, 2021, 06:50:34 PM
|
Something is not right with your errors
For K = 1024 the bloom filter is only 4294967296 elements and your error show 110010218577920 that is something more, DID YOU EDIT THE CODE?
Another question is WHY THE FUCK are you using YELLOW COLOR TO POST TEXT? Are you retard or just one more troll?
I hate python and i will never going to write one python.
|
|
|
793
|
Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports
|
on: November 11, 2021, 04:52:21 PM
|
In those case you need to use a small N value, like 0x40000000 (30 bits) or 0x1000000 (24 bits) the default N value is 0x100000000000 enough to cover some 44 bits in a single operation using only some 1 or 2 MB of RAM So i dont see the necessity to specify a lower range, unless you are doing some test for your self.
|
|
|
796
|
Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle (3,350.00 BTC's )
|
on: October 31, 2021, 09:21:00 PM
|
Hello albert0bsd, So, may i ask if this is a real legit puzzle that is solvable then? or is this a fake puzzle? and if this puzzle is solvable, what is the chances that actually someone unlock that 3350 BTC Address? Regards!
Well i don't believe that this puzzle is real, but that is what i believe based in what i know about the Elliptic Curve Signatures. The OP don't want to make a message signed with that publickey, that is a strong sign that is not real. but who knows. Regards!
|
|
|
798
|
Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle (3,350.00 BTC's )
|
on: October 30, 2021, 05:41:00 AM
|
Well i just calculate some values for k1, k2 and the privatekey but the generated private key don't generate your publickey k1: 0xbe404cba76f7018e965637f859560b59701ea7b2b50c3ba2d9899bc14e451032 k2: 0x7c809974edee031d2cac6ff0b2ac16b4258e727ebacfd709f340d8f5cc53df23 pvk: 0x8bfc718f4753611d61d043b499a2af787590cfb220959734c9c8c28406588ee With any of the values k1 or k2 we can calculate the pvk with the next equation: pvk = ( k*s - z)/r (Mod N) Using your rsz values and my values k1 and k2, both substitutions in equation always give me the same privatekey and well this obvious the equations assume that K2 = 2 * K1 and all the subsequent substitutions come from that supposition. I heard from other people trying to solving this example in the testnet, that they also solved some privatekey but also they doesn't generate your publickey.
For those who wanna to know how or where the numbers come from, please read ECDSA: Elliptic Curve Signatures there are one equation, that we can use to solve some elements. (1) : s = k -1 * (z + r * d) (mod n) That is the equation that generate the s value. d is the privatekey from that equation we can derive the private key with all the other values s, r, z and k(2) : d = ksr -1 - zr -1 (mod n) We have 2 TX values ( s, r, z) with an unknow k, but we "know" the relationship between the two k values (3) : k 2 = 2*K 1Since the equation (2) solve the same private key with the 2 distinct values of r,s,z and k of our transaction we can use it in the next way (4) : k 1s 1r 1-1 - z 1r 1-1 = k 2s 2r 2-1 - z 2r 2-1 (mod n) if we substitute (3) in (4) and and then we can solve for k 1(5) : k 1 = (z 1r 1-1 - z 2r 2-1) / (s 1r 1-1 - 2r 2-1s 2) (mod n) Once that you have the value of k1 you can use it to solve k2 using the equation (3) and use the complete set of values r,s,z and k to solve the private key in the equation (2)
A little code in C using gmp to show this example: /* gcc -o k1_solver k1_solver.c -lgmp */
#include <stdio.h> #include <stdlib.h> #include <stdint.h> #include <gmp.h> #include <time.h> #include <string.h>
struct Point { mpz_t x; mpz_t y; };
struct Elliptic_Curve { mpz_t p; mpz_t n; };
struct Elliptic_Curve EC; const char *EC_constant_N = "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141";
void calculate_pvk(mpz_t pvk,mpz_t r_inv,mpz_t s,mpz_t z,mpz_t k);
int main() { mpz_t z1,z2,r2,r1,s1,s2,k1,k2; mpz_t a,b,c,d,e,f,r1_inv,r2_inv,f_inv; mpz_t pvk_calulated; mpz_init_set_str(EC.n, EC_constant_N, 16); /* Set the R S Z values of the first TX */ mpz_init_set_str(r1,"42c995eb98c38a8f3de7dde0f5ac63a67441a7e96b821f53931495bc6ea64cb0",16); mpz_init_set_str(s1,"35a526e609d7022249d46d2392ff7e66b11a303d137204eb909867ae272c24b1",16); mpz_init_set_str(z1,"c8d3c14a3b190b6ea53ce4317fdd51ca1cf1a235dffbc3ce566507061f901a5a",16); /* Set the R S Z values of the second TX */ mpz_init_set_str(r2,"4f8bfa709c788b2ed59dd44a16e0c7b22ca7dece56d27144d418577a38b1d0d2",16); mpz_init_set_str(s2,"096f65fa2a2c6c054b12981c42b0aece4ac861632a2900ced39070f0dd2e86e1",16); mpz_init_set_str(z2,"57b1d4f6111f1dd7b87db91931682bad285aa2587c6239f7d3beb319ff2e0834",16);
/*Init variables GMP stuff */ mpz_init(pvk_calulated); mpz_init(r1_inv); mpz_init(r2_inv); mpz_init(a); mpz_init(b); mpz_init(c); mpz_init(d); mpz_init(e); mpz_init(f); mpz_init(k1); mpz_init(k2); /*This Operations are based in the suposition that k2 = 2 * k1 mod n */ /* calcualte the r1 and r2 Invert*/ mpz_invert(r1_inv,r1,EC.n); // r1_inv = 1/r1 mpz_invert(r2_inv,r2,EC.n); // r2_inv = 1/r2 mpz_mul(a,z1,r1_inv); // a = z1 * r1_inv mpz_mul(b,z2,r2_inv); // b = z2 * r2_inv mpz_sub(c,a,b); // c = a - b mpz_mul(d,r1_inv,s1); // d = r1_inv * s1
mpz_mul(e,r2_inv,s2); // e = r2_inv * s2 mpz_mul_ui(e,e,2); // e = 2 * e mpz_sub(f,d,e); // f = d - f mpz_invert(f_inv,f,EC.n); // f_inv = 1/f mpz_mul(k1,f_inv,c); // k1 = f_inv * c mpz_mod(k1,k1,EC.n); // k1 = k1 mod n gmp_printf("k1: %Zx\n",k1); mpz_mul_ui(k2,k1,2); // k2 = 2 * k1 mpz_mod(k2,k2,EC.n); // k2 = k2 mod n gmp_printf("k2: %Zx\n",k2); /* Calculate the pvk with the set of values of the first TX */ calculate_pvk(pvk_calulated,r1_inv,s1,z1,k1); gmp_printf("pvk_calulated: %Zx\n",pvk_calulated);
/* Calculate the pvk with the set of values of the second TX */ calculate_pvk(pvk_calulated,r2_inv,s2,z2,k2); gmp_printf("pvk_calulated: %Zx\n",pvk_calulated); }
void calculate_pvk(mpz_t pvk,mpz_t r_inv,mpz_t s,mpz_t z,mpz_t k) { mpz_t a,b; mpz_init(a); mpz_init(b); mpz_set(a,k); mpz_mul(a,a,s); mpz_mul(a,a,r_inv); mpz_set(b,r_inv); mpz_mul(b,b,z); mpz_sub(a,a,b); mpz_mod(a,a,EC.n); mpz_set(pvk,a); mpz_clear(a); mpz_clear(b); }
Regards!
|
|
|
799
|
Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports
|
on: October 29, 2021, 01:59:29 AM
|
Dear alberto, how is this not ok? or is it ok? how much time should this last processing take, already a long few hrs. passed,. thanks
Hi, that is not OK but i seen that you are using an old version, that problem is already solved in the newest version. But with the public key is it possible? How much time? i have been playing with bsgs but to no avail
It can take from one day to one trillion trillion years or more.
|
|
|
800
|
Bitcoin / Bitcoin Discussion / Re: == Bitcoin challenge transaction: ~100 BTC total bounty to solvers! ==UPDATED==
|
on: October 25, 2021, 08:54:05 PM
|
64 = 10 million years 63 = 5 million 62= 2.5 million 61= 1.25 million . how did they get 60,61,62,63? it's millions of years
The time to solve it depend of your speed those low puzzle can be resolved in less time with the currents speed, here are my calculation for those with distinct speeds Puzzle 61 @ 1 Megakeys/s (10^6): 36558 years Puzzle 61 @ 1 Gigakeys/s (10^9): 36 years
Puzzle 62 @ 1 Megakeys/s (10^6): 73117 years Puzzle 62 @ 1 Gigakeys/s (10^9): 73 years
Puzzle 63 @ 1 Megakeys/s (10^6): 146235 years Puzzle 63 @ 1 Gigakeys/s (10^9): 146 years
Puzzle 64 @ 1 Megakeys/s (10^6): 292471 years Puzzle 64 @ 1 Gigakeys/s (10^9): 292 years I ask the same question in some ther tocic: https://bitcointalk.org/index.php?topic=5365099.msg58158290#msg58158290I found the answer by my self, here there are some small summary of it with links to the related post and answer Addresses from 1 to 50 puzzles were solved simultaneous by an unknow person/group Addresses from 51 to 54 puzzles were solved by the the LBC project with variable speed from some 190 trillion keys per day Addresses from 55 to 58 puzzles were solved by a Unknow person/group Addresses from 59 to 63 puzzles were solved by Zielar with a speed of 248 Gkeys/s with bitcrack There are interesting things in that Topic Zielar talk about 0 costs of the electricity for him: https://bitcointalk.org/index.php?topic=1306983.1140Speed of 248 GKeys/s are written here: https://bitcointalk.org/index.php?topic=1306983.msg51808347#msg51808347He use upto 100 GPUs Tesla https://bitcointalk.org/index.php?topic=1306983.msg51848002#msg51848002But in some previous post he only talk aboout 4 or 8 GPUs seems that he manage to get access to 100 GPUs at 0 cost for him That is all that i want to know. Regards!
|
|
|
|