I deleted my initial report after Alberto said it was fine, I felt so dumb lol.  I exactly meant what you posted. I think I was not able to explain it well, thanks for your attention.

Hi Alberto,

1/ Is there anyway to fix Xpoint mode? it seems like Xpoint compress mode calculate-y as well.
2/ Aside that when the solution is found, it prints in terminal and write on file only in uncompress format even if the flag is compress.

Hi Alberto, why does xpoint compress mode calculate y? and why after finding a target public key it prints as uncompress format in terminal and keyfound.txt? I guess calculating y would decrease the speed. thanks!

I found almost 18 prefix (13zb1hQ) with 0x28 private key. I always knew the taget very likely to be there, starts wit 28, even tried to spend days bruteforcing 0x28 range but was not successful to find the key. It was just gut feeling but I'm sure no math trick/prime number pattern/algorithm is applied to puzzles without public key otherwise sha256/hash160 and secp256k1 are broken.

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?

root@C.12292023:/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!
[/quote]

Stride will not help you in address mode, its a simple math, those prime numbers you found in address prefix are irrelevant as a pattern since multiple hashes from private key for generating address would kill any correlation. stride is used to make a collision between a sequential subgroup to a distributed targets based on a pattern, useful in BSGS or Xpoint, like when you use key negation and know the exact distance between targets, then you need to look for a very large prime number that is close to d/n (distance/sequential search(-n)).

for your second question, the Keyhunt behavior is not strange, that's the nature of compress mode, it checks both side of the elliptic curve for any given key.

Stride will not help you in address mode, its a simple math, those prime numbers you found in address prefix are irrelevant as a pattern since multiple hashes from private key for generating address would kill any correlation. stride is used to make a collision between a sequential subgroup to a distributed targets based on a pattern, useful in BSGS or Xpoint, like when you use key negation and know the exact distance between targets, then you need to look for a very large prime number that is close to d/n (distance/sequential search(-n)).

for your second question, the Keyhunt behavior is not strange, that's the nature of compress mode, it checks both side of the elliptic curve for any given key.

I want to add that having Stride with Xpoint kinda works like Pollard Kangaroo, we can try some prime numbers to find collision between -n value for sequential search and -Stride value. One of them would be wild Kangaroo, the other would be the tame one. Its all about finding good prime numbers. BSGS is not going to work for puzzle 130 even with high end CPU and 1TB RAM. This algorithm is not efficient for 130 bits, someone need to get extremely lucky.

Thanks for quick response. I believe Xpoint + Stride could solve puzzle 130 much faster than bsgs even if Stride drops the performance of Xpoint. Hopefully you find a way and make some time to implement it for Xpoint.

By the way one of comments above was about Stride combination with Vanity, another guy was talking about it. In my opinion there is no relation between a prime number and vanity search based on the address characters. Multiple hashes happens from private key to generate an address. There is no reason for address to have a correlation with private key in terms of Stride and prime number. Those hashes kill any relation. The only point of having Stride is working with public key to target the X array. Using Stride in any other mode is useless and waste of time. Someone might get lucky using Stride and find the key but based on mathematics, there is no relation.

Another question, in github "changelog" you said you added bloom filter for address as well, I thought it was only for bsgs to create hash tables, how does bloom filter can help to speed up the address mode and rmd160.?
Also whats the "-z" multiplier in your code? Thanks!

Hi Alberto, I see some Stride development in your code, does it work with Xpoint mode? I got some idea. I tried to flag it with -I 0xprimenumber but it didnt work. Checked some previous github issues, I noticed it used to work with addrsss, rmd160 and xpoint but somehow you shut it down. Would like to see if you can have it back on. Thank you and I appreciate all you have done for this research.

Hi Alberto, I'm aware of BSGS algorithm and importance of k as 2^x to be optimized and efficient on math part but if the available RAM is somewhere between 2^x and we pick a non square k number, obviously it would hit the key in sequential search but I'm wondering if it miss the key in random search. I have a thread-ripper pro 96 cores, 192 threads, 512GB RAM but not possible to max it out. can go around 490GB, I'm pretty confused to pick a k number, would be a waste to use 256GB instead of 490GB. I appreciate your opinion in this matter. Does the higher speed mean more efficiency?