Pages:
Author

Topic: Keyhunt - development requests - bug reports - page 9. (Read 14735 times)

hero member
Activity: 862
Merit: 662

In the post:
 Range
-- from : 0x1
-- to   : 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141

And what you expected? found the key in seconds?

Genius...... That is the whole range if there is a program to found a key in seconds the bitcoin and all alt-coins will worth ZERO

Please don't ask stupid questions here
member
Activity: 119
Merit: 36
Bug?

Where in the command do you set the range?

 Roll Eyes Roll Eyes Roll Eyes Tongue

In the post:
 Range
-- from : 0x1
-- to   : 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141

also I tried
./keyhunt -m xpoint -f testkey.txt  -r 1:100
  • Version 0.2.230519 Satoshi Quest, developed by AlbertoBSD
  • Mode xpoint
  • N = 0x100000000
  • Range
  • -- from : 0x1
  • -- to   : 0x100
  • Allocating memory for 1 elements: 0.00 MB
  • Bloom filter for 1 elements.
  • Loading data to the bloomfilter total: 0.03 MB
  • Sorting data ... done! 1 values were loaded and sorted
^C] Total 218610688 keys in 30 seconds: ~7 Mkeys/s (7287022 keys/s)

Thank you for your help
newbie
Activity: 9
Merit: 3
Code:
./keyhunt -m vanity -l compress -r 30000000000000000:3ffffffffffffffff -R -v 13zb1hQ -n 0x6000000 -q -s 10 -t4
[+] Mode vanity
[+] Search compress only
[+] Random mode
[+] Added Vanity search : 13zb1hQ
[+] Quiet thread output
[+] Stats output every 10 seconds
[+] Threads : 4
[+] N = 0x6000000
[+] Range
[+] -- from : 0x30000000000000000
[+] -- to   : 0x3ffffffffffffffff
[+] Bloom filter for 1 elements.
[+] Loading data to the bloomfilter total: 0.03 MB
[+] Total 5566996480 keys in 310 seconds: ~17 Mkeys/s (17958053 keys/s)
Vanity Private Key: fffffffffffffffffffffffffffffffebaaedce6af48a0380b2513a178946f75
pubkey: 03b32edf683e27c1c866c915f093c3e88d4dbedbb81cc48e5f7355dbfd731ab8ba
Address 13zb1hQVwAhBbaDUusG6ogrq3ZnN1WJy5w
rmd160 20d45a6a6f3f0f3f3fbf3d6d7ba46818b1dc1d5c
hero member
Activity: 862
Merit: 662
Bug?

Where in the command do you set the range?

 Roll Eyes Roll Eyes Roll Eyes Tongue
member
Activity: 119
Merit: 36
Bug?

Hi Alberto,

I am using Version 0.2.230519 on Ubuntu.

In xpoint mode, with an uncompressed public key, the program does not find the private key

the public key file is one long string, no breaks
04bdba1effbf6af786dca1da26cc2261021f95d56f245298c0b87a40e1fa9a0cbc05e798c4be089 a47da2ec0d2869c0e394ccf75eb4fcc01321e2f2a67a7cbbb7d (key10)

Result

./keyhunt -m xpoint -f testkey.txt -n 65536 -t 4
  • Version 0.2.230519 Satoshi Quest, developed by AlbertoBSD
  • Mode xpoint
  • Threads : 4
  • N = 0x10000
  • Range
  • -- from : 0x1
  • -- to   : 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141
  • Allocating memory for 1 elements: 0.00 MB
  • Bloom filter for 1 elements.
  • Loading data to the bloomfilter total: 0.03 MB
  • Sorting data ... done! 1 values were loaded and sorted
^Cse key: 50f0001   

What am I doing wrong?
Thank you


 

newbie
Activity: 6
Merit: 0
Thanks, regarding vanity, speed is slightly better for me than address mode.
hero member
Activity: 862
Merit: 662
I have tried Vanity search with range specified and it has found address that is out of range:

Code:
 ./keyhunt -m vanity -f tests/van.txt -l compress -R -b 66 -e -s 10 -q -t 32 -n 0x400000000000 


Remove -e, by the way don't use vanity for puzzle search
newbie
Activity: 6
Merit: 0
I have tried Vanity search with range specified and it has found address that is out of range:

Code:
 ./keyhunt -m vanity -f tests/van.txt -l compress -R -b 66 -e -s 10 -q -t 32 -n 0x400000000000 
[+] Version 0.2.230519 Satoshi Quest, developed by AlbertoBSD
[+] Mode vanity
[+] Search compress only
[+] Random mode
[+] Endomorphism enabled
[+] Stats output every 10 seconds
[+] Quiet thread output
[+] Threads : 32
[+] N = 0x400000000000
[+] Bit Range 66
[+] -- from : 0x20000000000000000
[+] -- to   : 0x40000000000000000
[+] Bloom filter for 1 elements.
[+] Loading data to the bloomfilter total: 0.03 MB
[+] Total 488007616512 keys in 3320 seconds: ~146 Mkeys/s (146990245 keys/s)
Vanity Private Key: 164ddd867ec35f2e98f582c4d0d737f56f10d6a3cd2be340adf436912436f49
pubkey: 03cb9c45ef630131d33cf1e0b062165cea96a2cc3daf89448063180f48ad11d7ce
Address 13zb1hQbAP3nYzCWptx59aR1qG7J4UCY6h
rmd160 20d45a6a75b7519bfed7f99e576f1acd0aad1428
[+] Total 896877281280 keys in 6110 seconds: ~146 Mkeys/s (146788425 keys/s)

hero member
Activity: 862
Merit: 662
Is it possible to adapt an ASIC miner to this program as a coprocessor because it has higher speed?

No, its no possible to use them.

Or perhaps use MicroRNG is a hardware (true) random number generator?

In linux it use urandom to get random numbers, i did some test before and the performance is almost the same, there is not much advantage to use the CPU RNG to do that, even the libssl RNG is faster than it.
If the OS have enough entropy even 256 bits of good entropy is enough to generate Random numbers for an eternity see : https://www.2uo.de/myths-about-urandom/
newbie
Activity: 7
Merit: 1
Is it possible to adapt an ASIC miner to this program as a coprocessor because it has higher speed?
Or perhaps use MicroRNG is a hardware (true) random number generator?
newbie
Activity: 14
Merit: 0
Bsgs is now holding 18 exa keys/s stable.

Running a program to searches 18 exa keys/s is impressive!

I have 16 GB and Core i7, and get only 70 Peta key/s  

18 ExKeys/s this is a drop in the ocean, the range is huge, brute force is currently not the best choice for solving the puzzle. Even if random is not a very good idea, you need to look for another approach

P.s.
https://i.ibb.co/pfR0VDp/2023-11-08-00-14-18.png

Please tell me what CPU you have?
full member
Activity: 1162
Merit: 237
Shooters Shoot...
hi i need a bit help if i run this


Code:
./keyhunt -m vanity -f tests/66.txt -r 34024a9fc3e150000:34024ce5d77df7fff -l compress -q -s 10 -v 13zb1hQbWVs -t 8 -n 0x400 -e

the program still search after 40 trillions,

if the range is smaller it stop when range ends

Code:
./keyhunt -m vanity -f tests/66.txt -r 34024a9fc3e150000:34024a9fc3e750000 -l compress -q -s 10 -v 13zb1hQbWVs -t 8 -n 0x400 -e

what i should do ? to modify the n ?

You should use VanitySearch to find it, however, finding matching 10 characters will take awhile. Especially if only using CPU.
Also, there is no guarantee that the prefix you are looking for is even in those ranges.
newbie
Activity: 74
Merit: 0
hi i need a bit help if i run this


Code:
./keyhunt -m vanity -f tests/66.txt -r 34024a9fc3e150000:34024ce5d77df7fff -l compress -q -s 10 -v 13zb1hQbWVs -t 8 -n 0x400 -e

the program still search after 40 trillions,

if the range is smaller it stop when range ends

Code:
./keyhunt -m vanity -f tests/66.txt -r 34024a9fc3e150000:34024a9fc3e750000 -l compress -q -s 10 -v 13zb1hQbWVs -t 8 -n 0x400 -e

what i should do ? to modify the n ?
newbie
Activity: 41
Merit: 0
Has anyone looked for a mathematical solution?
This seems to respond to a form of polynomial function of degree n, where n is the position of the term in the sequence, such that the same sequence of the addresses found is obtained:
1,3,7,8,15,31,4C,E0...
full member
Activity: 1162
Merit: 237
Shooters Shoot...
Sorry, why try to solve puzzle 130 and not 66? Huh
Double the reward with the same number of operations; depending on which program you use.
Also, you can't use BSGS for #66.
newbie
Activity: 41
Merit: 0
Sorry, why try to solve puzzle 130 and not 66? Huh
full member
Activity: 1162
Merit: 237
Shooters Shoot...
What's the largest baby step file someone has created for BSGS?

More than 1 Billion, anyone?
newbie
Activity: 6
Merit: 0
Thanks WanderingPhilospher. But oh my god, we stand no chance to crack 130 puzzle any time soon.
full member
Activity: 1162
Merit: 237
Shooters Shoot...
Hello, I tried to calculate (using AI help) and I get that at 48 exa keys per second the range will be completed shortly. Where is the mistake?

(2^130 - 1) - 2^129

2^130 is 340282366920938463463374607431768211456

Subtracting 1 gives us:

340282366920938463463374607431768211455

2^129 is 170141183460469231731687303715884105728

Subtracting the start from the end:

340282366920938463463374607431768211455 - 170141183460469231731687303715884105728

= 170,141,183,460,469,231,731,687,303,715,884,105,727

Total keys / Keys scanned per second

170,141,183,460,469,231,731,687,303,715,884,105,727 / 48,000,000,000,000,000,000

= 3,542 seconds


Bsgs is now holding 18 exa keys/s stable.

Running a program to searches 18 exa keys/s is impressive!

I have 16 GB and Core i7, and get only 70 Peta key/s  

18 ExKeys/s this is a drop in the ocean, the range is huge, brute force is currently not the best choice for solving the puzzle. Even if random is not a very good idea, you need to look for another approach

P.s.


Your calculator is broke lol.

(2^129/48000000000000000000) / 86400 (seconds in one day) = 164,102,221,701,841 days to scan entire range.

Also, 2^129 = 680564733841876926926749214863536422912, not 170141183460469231731687303715884105727 as you stated.

But even with your numbers:

(170141183460469231731687303715884105728/48000000000000000000) / 86400 = 41,025,555,425,460 days.
newbie
Activity: 6
Merit: 0
Hello, I tried to calculate (using AI help) and I get that at 48 exa keys per second the range will be completed shortly. Where is the mistake?

(2^130 - 1) - 2^129

2^130 is 340282366920938463463374607431768211456

Subtracting 1 gives us:

340282366920938463463374607431768211455

2^129 is 170141183460469231731687303715884105728

Subtracting the start from the end:

340282366920938463463374607431768211455 - 170141183460469231731687303715884105728

= 170,141,183,460,469,231,731,687,303,715,884,105,727

Total keys / Keys scanned per second

170,141,183,460,469,231,731,687,303,715,884,105,727 / 48,000,000,000,000,000,000

= 3,542 seconds


Bsgs is now holding 18 exa keys/s stable.

Running a program to searches 18 exa keys/s is impressive!

I have 16 GB and Core i7, and get only 70 Peta key/s  

18 ExKeys/s this is a drop in the ocean, the range is huge, brute force is currently not the best choice for solving the puzzle. Even if random is not a very good idea, you need to look for another approach

P.s.
https://i.ibb.co/pfR0VDp/2023-11-08-00-14-18.png
Pages:
Jump to: