Quote from: albert0bsd on August 20, 2024, 01:15:54 PM

Quote from: benjaniah on August 20, 2024, 10:28:48 AM

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

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

Quote from: benjaniah on August 20, 2024, 10:28:48 AM

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.

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.

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. Grin

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!