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