Bitcoin Forum
April 27, 2024, 07:03:13 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 [40] 41 42 43 »
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/142

What 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:

Code:
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
784  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: December 22, 2021, 09:02:14 AM
@albertobsd

iknow r s1s2  value
i need z1z2 how to calculate

please learn algebra

if you have doubt of those post, please write your doubt there NOT HERE.

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.

Code:
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:

Code:
021fc9e584dc824cb5b566bb7125aef1e31c95fb2fbabc7c315686b3c211d69ed8 # 90000000000000000000f000000001
02df23c15df7b3ba9fdb14fd5a994d7ba4c694f172ddf3f644fb47b4b399e214bb # 90000000000000000000000f000001
03e3a37d2332821cfe5ca644b26d640a707497870298e084c443d94670b00c5552 # 900000000000000000000f00000001

Code:
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
786  Bitcoin / Project Development / Re: List of all Bitcoin addresses with a balance on: December 16, 2021, 04:44:14 PM
Not OP, but are you looking for something like this:

Yes something like that, i already have some lists, but none of them are a exhaustive list or even updated

Regards
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?

    3. my  site show 64 puzzle result  https://hashkeys.club/64/results/ all pepole show your 120puzzle final range Smiley easy to find me

What is the question here?

    4. share with me how to learn bloom filter quickly for 3 days form the scratch Smiley C,C++ java and Python #i_am_fast_learner Smiley Smiley

Check the code of the bloom filter that im using, it is pretty easy to understand.
https://github.com/jvirkki/libbloom
Also 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.
788  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: November 30, 2021, 12:46:23 PM
nevermind....it is working now, and I have no idea why.  Huh

Maybe you installed the build-essentials packages.
789  Bitcoin / Project Development / Re: keysubtracter - test - development requests - bug reports on: November 22, 2021, 08:45:58 PM
please write easy understand make python or explain mathematicaly

I don't know python, but here is a link that explain the point Negation in eliptic curves:

https://www.youtube.com/watch?v=0EsyHJvf_JE

https://trustica.cz/en/2018/03/08/elliptic-curves-point-negation/

For you example the negated Point is : 04c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5e51e970159c23 cc65c3a7be6b99315110809cd9acd992f1edc9bce55af301705

And the result is:

0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c 4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8

Regards!

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.



792  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: November 14, 2021, 05:09:31 PM
Please post here your error
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)

Code:
-n 0x40000000 

Code:
-n 0x1000000

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

Code:
-n 0x100000000000

So i dont see the necessity to specify a lower range, unless you are doing some test for your self.
794  Bitcoin / Project Development / Re: List of all Bitcoin addresses with a balance on: November 06, 2021, 05:16:07 PM
Well, that is a pity, thanks for the fast reply.

I will stick to my current list of dormants-publickeys with subtracted values  Total (3.5 Million public keys) at some 400 Gkeys/s

Wonderful work you made.

Thanks!
795  Bitcoin / Project Development / Re: List of all Bitcoin addresses with a balance on: November 06, 2021, 04:52:36 PM
Hi LoyceV since you already have some useful data, did you believe that you can publish some list like "Public keys with balance".
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!
797  Bitcoin / Bitcoin Discussion / Re: == Bitcoin challenge transaction: ~100 BTC total bounty to solvers! ==UPDATED== on: October 31, 2021, 09:15:54 PM
Question : If you find the key , where do you input it ? which wallet ?

Well some wallets can accept the privatekey in hexadecimal format but some others no so you can convert it to wif format using some trusted pege like https://www.bitaddress.org/bitaddress.org-v3.3.0-SHA256-dec17c07685e1870960903d8f58090475b25af946fe95a734f88408cef4aa194.html in  the section "Wallet details" you paste the hexadecimal privatekey and they generate the QR code for you you can scan it from any wallet software using the camera.

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

Quote
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) : k2 = 2*K1

Since 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) : k1s1r1-1 - z1r1-1 = k2s2r2-1 - z2r2-1 (mod n)

if we substitute (3) in (4) and and then we can solve for k1

(5) : k1 = (z1r1-1 - z2r2-1) / (s1r1-1 - 2r2-1s2) (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:

Code:
/*
  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

Code:
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#msg58158290

I 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.1140

Speed of 248 GKeys/s are written here:
https://bitcointalk.org/index.php?topic=1306983.msg51808347#msg51808347

He use upto 100 GPUs Tesla
https://bitcointalk.org/index.php?topic=1306983.msg51848002#msg51848002

But 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!
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 [40] 41 42 43 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!