Topic: Keyhunt - development requests - bug reports - page 3. (Read 15472 times)

Ah, makes sense. Thanks for the explanation!

Well more or less is that last answer but i need to extend it and explain it here just to clarify this and the speed calculation.

The Point in an Eliptic Curve is made with two integers (X,Y), right? For any point there is a Point negation where you need to subtract the Order or the curve to the Y value
Both points (Original and Negated point) has the same X value, Since the Module Operations the Y values one is EVEN and the other is ODD, for compressed keys in bitcoin documentation this Y parity determine if the prefix byte of the public key is 02 or 03.

Now for some math and code efficiency there is way to calculate ONLY the X value of others points round a Single point A Example:

We can know the X value of all other points (WITHOUT the necessity to calculate Y value). This save us time of execution, because we can append to that X value the prefixes 02 and 03 without calculate Y real value.

When its necessary to calculate Y? Well only when you HIT a target key and you need to calculate the private key (in that case you must know the parity).

How this affect the speed?
Lets to say that you current speed is 200 Mkey/s, this speed is checking both points Original and negated (remember we only calculate X value and just append 02 and 03)
This mean that 100 Mkeys/s are in the target Range and other 100Mkeys/s are in the negated range (But we can't determine which value is what) until we calculate Y.

But if we calculate Y every time that we generate Another Point and do all the process to determine which is in the target range and which is in the negated range, your final speed will be some 150 Mkeys/s or some other Sub-optimal speed.

That is why the program check Both keys (without know the parity) to get more speed, This for random search in any 256 bit space is perfect because you are checking more keys in the same time.

Thanks, after thinking a bit it's not a significant finding. Any even numbered decimal private key will have a factor of 2, so I guess you can forget about all that. I have a small number of 13zb1hQbWV prefixes I've found in the 66 bit space, I will probably keep them to myself until after the puzzle is completed by somebody. 

On another note, I notice sometimes Keyhunt doing strange things like this, even when the range is specified. Any ideas?

[email protected]:/app/bitcrackrandomiser/keyhunt$  ./keyhunt -m vanity -v 13zb1hQb -r 3a86ef00000000000:3a86ef10000000000 -l compress -s 1 -t 60 -n 0x10000

• Version 0.2.230519 Satoshi Quest, developed by AlbertoBSD
• Mode vanity
• Added Vanity search : 13zb1hQb
• Search compress only
• Stats output every 1 seconds
• Threads : 60
• N = 0x10000
• Range
• -- from : 0x3a86ef00000000000
• -- to   : 0x3a86ef10000000000
• Bloom filter for 1 elements.
• Loading data to the bloomfilter total: 0.03 MB

Base key: 3a86ef0077ad20000     2 seconds: ~205 Mkeys/s (205710565 keys/s)
Vanity Private Key: fffffffffffffffffffffffffffffffebaaedce6af48a03817636e85556f0d7c
pubkey: 03056b43664b1aabcdb968796a502b1a81a30fbc76d7c46eeadce91d3ff11405c4
Address 13zb1hQb4i7T18v37e9LKwEqx1t7EhcgAd
rmd160 20d45a6a7598570779fd21913bb29777704d0182
Base key: 3a86ef00ab6da0000     7 seconds: ~205 Mkeys/s (205689239 keys/s)
Vanity Private Key: fffffffffffffffffffffffffffffffebaaedce6af48a03817636e82195f2a18
pubkey: 028bca9f9f5fe984858819330afc10a9c80cab1f2a756fda17033f811b20775cea
Address 13zb1hQbUbJxj9ZKag8n2nepFtmzRRSNc9
rmd160 20d45a6a761acbcc30d7a84bad85eb9dfce4286a
Base key: 3a86ef01b25980000     133 seconds: ~205 Mkeys/s (205687449 keys/s)

It's finding private keys to a prefix match outside of the range I specified. Let me know what you think and thanks in advance!

If you have a GPU look for Kanhavishva's BitCrack2, it has both xpoint mode and stride.

Sorry for the off-topic Alberto.

Hi thanks for ask, sadly the stride is not working as I expected for any mode , that was my first try but due the complexity of the current code is difficult implement it without do a mess or get invalid results.


Well all modes use bloom filter as first "Firter" to discard address that we aren't looking for. BSGS is a especial case where precalculated data help to boost the speed.

address/rmd160 and xpoint don't has that boost benefit because the way that bruteforce is performed is different.

The -z is not documented because it was an experiment I was trying many ideas just to see if some of them boost the speed in some way for address/rmd160 or xpoint but NONE of them works. Actually any -z value different than 1 bring a little less performance

Well It is not so simple, i already try it before but my first code was wrong



Nice finding, from a statistical point of view, is your data set Significant?

In the 66 bit space maybe there around of 12344 address that start with 13zb1hQbWV, so I don't know how many we require so demonstrate that those prime factors are relevant or not.

Another thing is that there is no relationship between the prime factors of a private key and the generated address prefix, I can found a lot of address that aren't related to 13zb1hQbWV and have those factors, so the number of "(about 1/3)" is just some statistical or probabilistic

According to some research that i just did the percentage of numbers that has 11 or 13 as factor is near to 20%, that may vary from one rank to another

I bet that half of your data set has 2 as prime factor and other 1/3 has 3 as prime factor no?

I really may consider to add the stride option if you share your data set with me in public or in private.

Hi Alberto

Would you consider adding a stride option that works in address and vanity mode?

My use case - I've found a good amount of 13zb1hQbWV prefix matches for puzzle 66 so far. When I convert their hex key into their base10 decimal number, I notice many of them (about 1/3) have a factor of 13 and/or 17. An example is 3FEE2509944801483 (13zb1hQbWVECopz4XMEYH8e2t2gX4v4Us3) = (decimal) 73706563070708421763 = 7 × 13 × 809962231546246393. What I would like to be able to do is start at a given key, increment by some stride value (in my case, 13 or 17), check that key for address/vanity match, and repeat to the end of the given range. Would be great if a decrement by x value stride option was available also.

I looked at the code but I have no clue how to make the changes, I'm sure it would take only a few minutes of your genius brain to add.

BitCrack has such a stride option and runs on GPU's however it only searches for full address matches, so there's no way for me to find prefix matches using it, Keyhunt I think it would be a nice add. Maybe there is a fork of vanitysearch out there with a stride option but I haven't been able to find it.

Thanks in advance, no worries if its not something you feel like adding, in that case I might be able to "chatgpt" it, haha.

cheers

Thanks

BSGS mode is for Public keys ONLY

RMD160 hash is different from a Public keys.

Please READ this link 4 Times before ask your next question: https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch04.html

If I RIPMED160 hash of my target address and use bags mode then how do I calculate the number which you have shown in your post above. Please explain. Thanks for your prompt reply. Appreciate it.

the RAM is only for BSGS

Can anyone suggest me, in keyhunt program how does one read the output and the .dat file (binary format) building up inside keyhunt folder. Thanks

Thanks for reply.

The 120 keys/address for the keyhunt documentation are examplest to test the speed. Please Read and Understand the documentation before running it without know what are you doing.


I need time to understand what are you doing, because right now Kangaroo its still a mystery for me. So i CANT say anything about what you write


Kehunt is for CPU only, so you GPU model doesn't have anything to do here.

For address there is no backwards mode, if you believe that your target is near of the end, THEN select a sub-range that is near of the desire range and not the whole range....

Hello, a question.

For wallet #120, when generating the Bitcoin address from the private keys found by Keyhunt, it does not reach the Bitcoin address presented for the wallet on the challenge website.

Shouldn't it be the same address?



# -----

### 120: Bitcoin address puzzle site: 17s2b9ksz5y7abUm92cHwG8jEPCzK3dLnT

Mempool transaction
https://mempool.space/pt/address/17s2b9ksz5y7abUm92cHwG8jEPCzK3dLnT


Private Key: 0000000000000000000000000000000000800000000000000000100000000000
Bitcoin address: 12L1pt6fnDbJJLsXCzGny11tzsRkG2Jt9n

https://privatekeys.pw/key/0000000000000000000000000000000000800000000000000000100000000000


Private Key: 0000000000000000000000000000000000800000000000000000200000000000
Bitcoin address: 1GmkjymA3vJrNXECbrRwZfCXrr1RPd6PK9

https://privatekeys.pw/key/0000000000000000000000000000000000800000000000000000200000000000


#-----

### 115: Bitcoin address puzzle site: 1NLbHuJebVwUZ1XqDjsAyfTRUPwDQbemfv

Private Key: 0000000000000000000000000000000000060f4d11574f5deee49961d9609ac6
Bitcoin address: 1NLbHuJebVwUZ1XqDjsAyfTRUPwDQbemfv   (it's ok)

Mempool transaction
https://mempool.space/pt/address/1NLbHuJebVwUZ1XqDjsAyfTRUPwDQbemfv

https://privatekeys.pw/key/0000000000000000000000000000000000060f4d11574f5deee49961d9609ac6

Good afternoon Alberto:

I have been studying BSGS, and Pollard's Kangaroo methods for a while now. I have made an observation trying to mix BSGS with the Kangaroo method that I believe could be helpful.

I have figured out you can use the concept of distinguished points used in the kangaroo method to improve BSGS.

Here is a simple example of what I have observed:

One of the big restraints in the BSGS is the available memory to store the database, each X coordinate you calculate (every jump or every step you make) goes against the database. The other big restraint is that each point has a lookup cost against the database. (1 Point = 1 search). I understand you use a bloom filter in your program to make the search on the database a lot faster and make the database as small as possible in order to fit in the RAM available.

Here is my idea: what about if you store only distinguished points in the database, this means only X coordinates with an amount of N leading zeroes. This has 3 big benefits, one, you can discard all the points that does not have N leading zeroes on the fly, with a very small cost. Second, only compare against the database the small X coordinates. Third, you will store less bits per X coordinates.

This will improve the speed of the algorithm because you will make the same amount of comparisons but most of them only discarding the bigger X's, and then compare only the small X coordinates not discarded.

The other big benefit is that your database won't be restrained anymore by RAM, instead use RAM to store only the distinguished points found and in a latter step, compare against a big stored database in a server. 

The draw-back is that you will spend more point computations building the database, but this is made only once.

By example a very simple case:

Case 1:
You set a database of 1024 X coordinates (baby steps), you can jump a distance of 2048 (because of symmetry) and each jump has to be compared using the bloom filter.
Cost : 1 jump of distance 2024 = 1 database search

Case 2:
You set N to be 8 bits, so you store only the X coordinates beginning with 8 leading zero bits. You search for the first 1024 distinguished points, with a mean search size of 256 points per distinguished point. To make the database, you have to search 1024*256 = 262.144 points to get the 1024 distinguished points needed. Now you can make  jumps of  262.144 * 2 = 524.288 (2 **19), and search for the next distinguished point after landing ( one very big jump, many small jumps).  You make the first jump 2**19, then find the next distinguished point ( with a step of one), then jump 2**19 again. On each step you discard the big X coordinates, and keep only the small X's, this small ones are the only you need to compare. So the mean jump length on average is the same (2**19/256) = 2048, but you only made 256 comparisons on average against the first byte of the coordinate ( a very small lookup cost) and stored temporarily only one small X coordinate that will be later compared against the database.

cost : To build the database calculate 2**18 points, then for 1 jump average 2024 distance = 1  leading zeroes comparison + 1/256 database search.

I 'm trying this idea using a slightly modified version of "Bitcrack", but it has been difficult for me because I'm new at cuda programming.

Does your implementation of the bloom filter takes this observation in to consideration?

Do you think this is a good idea?

Thanks

Hi all,
  I am newbie  to keyhunt. I have 32gb ram and rtx4070. While running the command line as ->
./keyhunt -t 8 -m address -f abc.txt -r  (from hexadecimal to hexadecimal) -q -s 10 -k 2048 -R
the speed is 5564110 keys/s. I wanna to scan backwards because I think the target address is nearest to back end of the range. Please suggest what is the most efficient command line I need to follow. Thanks

Thank You Very Much!!!

Sequential Mode: This mode searches for the private key in a sequential manner, from a starting point and incrementing step by step. It is straightforward but can be slow if the target key is far from the starting point.

Backward Mode: In this mode, the search starts from a specified point and moves backward. This can be useful if you have reason to believe the key might be located before a certain point.

Both Mode: This mode combines both forward and backward searching. The algorithm searches in both directions simultaneously, which can increase the chances of finding the key faster compared to only moving in one direction.

Random Mode: Instead of following a linear path, the search jumps to random positions. This mode can help in scenarios where the key is not expected to be near the starting point and can be located anywhere in the search space.

Dance Mode: This is a more advanced and less predictable search pattern, potentially combining aspects of the other modes in a dynamic way. The exact implementation details can vary, but the goal is to maximize the coverage of the search space and increase the likelihood of finding the key efficiently.