Pages:
Author

Topic: Prefix Difficulty Calculator c# assistance please! Base code included in post. - page 2. (Read 527 times)

hero member
Activity: 882
Merit: 5829
not your keys, not your coins!
VanitySearch doesn't calculate this correctly. (I've basically learned all I know on B58 off JLVS deconstruction)
Vanitygen does , however I don't understand how the conclusions are met,
https://github.com/samr7/vanitygen/blob/master/pattern.c
what in the witchcraft is PCRE? (https://www.pcre.org/original/doc/html/pcre_exec.html)
PCRE is simply a regex library. The function names like vg_regex_context_add_patterns also suggest this. So it doesn't appear like PCRE is witchcraft, as for the rest, it possibly is. Grin I don't have experience with prefix calculators, though it's a fun topic that I've always wanted to get into to make my own vanity addresses locally.
hero member
Activity: 1430
Merit: 513

If, however, you would search for "tt", the difficulty drops by 75% because you're now searching for 4 different prefixes:
Code:
./vanitygen 1tt  
Difficulty: 78508
./vanitygen -i 1tt
Difficulty: 19627
./vanitygen 1tt 1TT 1tT 1Tt
Next match difficulty: 19627 (4 prefixes)


Perfectly explained.

In other words, if you have case sensitive difficulty X, case insensitive difficulty will be X/(2^(number of [a-z] characters)).
1t 1T - 2^1 = 2 possibilities
1tT 1TT 1tt 1tT = 2^2 = 4 possibilities
1TTT 1TTt 1TtT 1Ttt 1tTT 1tTt 1ttT 1ttt = 2^3 = 8 possibilities etc.

so 1-9 and o,i & L are excluded right?
so as 1oojoo1 -i really is simply put = 444223305269
Thanks, maybe I was overthinking it.
solution= Diff/(2^(number of [a-z] characters)
so 1oojoo1= 888446610539
with -i/-c = 444223305269

Moving on from the case insensitive formula questions here's a different issue I'm encountering.

PawGo, I know how the script works I came up with it and overgril parsed it up, but somethings wrong with it because it excludes 16/32 pivots and it's doing a wrong operation /58 and *58 somewhere in it.  , I need to understand the pivots better
why does.

1QLbz6=264,104,224
but due to a pivot I don't understand
1QLbz7=837,596,142

VanitySearch doesn't calculate this correctly. (I've basically learned all I know on B58 off JLVS deconstruction)
Vanitygen does , however I don't understand how the conclusions are met,
https://github.com/samr7/vanitygen/blob/master/pattern.c
what in the witchcraft is PCRE? (https://www.pcre.org/original/doc/html/pcre_exec.html)
can you help me simplify this in the same way you did this  
Quote
X/(2^(number of [a-z] characters))

If I'm using JLVS calculation method and come to the conclusion  that 1QLbz7 = 264,104,224 thats a miscalculation and will cost me.


legendary
Activity: 952
Merit: 1367

If, however, you would search for "tt", the difficulty drops by 75% because you're now searching for 4 different prefixes:
Code:
./vanitygen 1tt  
Difficulty: 78508
./vanitygen -i 1tt
Difficulty: 19627
./vanitygen 1tt 1TT 1tT 1Tt
Next match difficulty: 19627 (4 prefixes)


Perfectly explained.

In other words, if you have case sensitive difficulty X, case insensitive difficulty will be X/(2^(number of [a-z] characters)).
1t 1T - 2^1 = 2 possibilities
1tT 1TT 1tt 1tT = 2^2 = 4 possibilities
1TTT 1TTt 1TtT 1Ttt 1tTT 1tTt 1ttT 1ttt = 2^3 = 8 possibilities etc.
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
most searchers user a /2 formula for case insensitive
 for example
1oojoo1 =888446610539
but
-c 1oojoo1 =444223305269
but in this case only 1/6 can be decreased
leaving 16.6666666667% of the prefix able to be divided by 2
(8.3333333333) therefore a reduction of 8.3333333333% of the initial 888446610539 difficulty
this means the adjusted difficulty is truly 74037217544 (I think Huh) with a case insensitive option applied.
Your math is wrong. I use vanitygen instead of VanitySearch, and as far as I know it shows correct difficulties.
I'll explain with a very short test so the difference in difficulty is easy to see:
Code:
./vanitygen 1t
Difficulty: 1353
./vanitygen 1T
Difficulty: 1353
./vanitygen -i 1t
Difficulty: 676
This makes sense, right? Searching case insensitive doubles the chance of finding a match, so the difficulty drops 50%.
Adding a "o" (which doesn't change when you search case insensitive) means the change in difficulty is still 50%:
Code:
./vanitygen 1to
Difficulty: 78508
./vanitygen 1To
Difficulty: 78508
./vanitygen -i 1to
Difficulty: 39254
If, however, you would search for "tt", the difficulty drops by 75% because you're now searching for 4 different prefixes:
Code:
./vanitygen 1tt   
Difficulty: 78508
./vanitygen -i 1tt
Difficulty: 19627
./vanitygen 1tt 1TT 1tT 1Tt
Next match difficulty: 19627 (4 prefixes)

PawGo's list shows the exceptions: prefixes starting with certain characters are less likely to occur.
hero member
Activity: 1430
Merit: 513
-snip

Quote
1QLbz6
VS=264104224
SK=3864628649984
1QLbz7
VS=264104224
SK=3864628649984
(But neither are right true difficulty on this is 837,596,142)
His estimates are wrong as they get more complex with pivots. he focused on length.
*we are only focusing on legacy for now until its mastered.
**went ahead and soft announced the service here so people can see what kind of equity has gone into it and see its already been executed and not a side thought. I figured it wouldn't hurt to ask for help in there either , I've seen some of the brightest minds on BCT in that one topic.
legendary
Activity: 952
Merit: 1367
Wait, maybe I am missing something. If you want to have the same results as in VanitySearch why do not you reuse their algorithm?
For example
Code:
it->difficulty = pow(2, 5*(prefix.length()-4));
for bech32 or
Code:
it->difficulty = pow(256, prefix.length() - 1);
For p2sh

You will find that calculations in https://raw.githubusercontent.com/JeanLucPons/VanitySearch/master/Vanity.cpp

Then there are minor updates if you search for several etc, but base values are like above.
hero member
Activity: 1430
Merit: 513
Hi,
It is very simple script, what do you need exactly? Description how it works?

Let's define 2 groups:
G1 = characters "234567890ABCDEFGHIJKLMNOPQ"
G2 = characters "RSTUVWXYZabcdefghijklmnopqrstuvxyz"

Ignore the first character.
Check second character: if it belongs to G1, set value as 23; it it belongs to G2, set value as 1354, if it is "1" set value as 256

Check each character, from 3rd to the end, and:
if character is "1", and there were only "1"s from the 3rd position, multiply value * 256. It there was already other character than "1", multiply value by *58
if character belongs to group G1, multiply value by * 23 (and remember that there was other value than "1", so multiplier for "1" is changed)
if character belongs to group G2, multiply value by * 58 (and remember that there was other value than "1", so multiplier for "1" is changed)

or you have results and want to find formula to produce them?
Please, explain what is your problem
The above code is an attempt to solve the difficulty calculation for Vanity wallets.
The code is pretty close, but not quite there.
I'd like to know if someone has any idea, or perhaps working sample (any language allowed) to calculate this difficulty.
I've found several posts detailing how to calculate it, but they've all been speaking in tongue soo far (or gave incomplete answers).

We designed this script to attempt a lazy calculation of difficulty but are learning what we reverse engineered was also inaccurate. VanitySearch
So here is a list of sample difficulties with the above script labeled SK against Vanity Search difficulties labeled VS.
we are missing multiple marks such as pivots against 1QLbz6 and 1QLbz7
Please note we expect about a %4.35 error ratio and this is fine.

Fact Check Difficulty
1Chicken
VS=888446610539
SK=50783635853696
1BiLL
VS=4553521
SK=260279408
11111
VS=4294967296
SK=98784247808
111111
VS=1099511627776
SK=25288767438848
1RR
VS=78509
SK=77372
1Ric
VS=4487576
SK=4553521
1Rick1
VS=15318045009
SK=15096205664
1BtcTo
VS=264104224
SK=15096205664
1btcto
VS=15318045009
SK=15096205664
1BtcToon
VS=888446610539
SK=50783635853696
1btctoon
VS=51529903411245
SK=50783635853696
12311
VS=4553521
SK=2602794081
1QLbz6
VS=264104224
SK=3864628649984
1QLbz7
VS=264104224
SK=3864628649984
(But neither are right true difficulty on this is 837,596,142)

Also, we could really use a difficulty division formula based on caseable & non-caseable characters.

We plan to use the solution for a pricing structure and time estimation on a vanity wallet service designed for retail investors. We've made it so easy to use, that children whom can read and follow directions can use it.
We will also be giving away in some cases up to 7 digit wallets absolutely free based on difficulty, that is why this part of our process is so important to us. We cannot have people submitting work for 11111111 and be inaccurate in pricing and estimated time.

edit to clarify the service is splitkey for legacy wallets only.
legendary
Activity: 952
Merit: 1367
Hi,
It is very simple script, what do you need exactly? Description how it works?

Let's define 2 groups:
G1 = characters "234567890ABCDEFGHIJKLMNOPQ"
G2 = characters "RSTUVWXYZabcdefghijklmnopqrstuvxyz"

Ignore the first character.
Check second character: if it belongs to G1, set value as 23; it it belongs to G2, set value as 1354, if it is "1" set value as 256

Check each character, from 3rd to the end, and:
if character is "1", and there were only "1"s from the 3rd position, multiply value * 256. It there was already other character than "1", multiply value by *58
if character belongs to group G1, multiply value by * 23 (and remember that there was other value than "1", so multiplier for "1" is changed)
if character belongs to group G2, multiply value by * 58 (and remember that there was other value than "1", so multiplier for "1" is changed)

or you have results and want to find formula to produce them?
Please, explain what is your problem
hero member
Activity: 1430
Merit: 513
Bump , Still trying to solve
hero member
Activity: 1430
Merit: 513
We could really use some help with this
Needs accurate output, somewhere *58 or /58 adds a wrong operation
case insensitive /2 disabled for 1-9 i,o and L and implemented for the rest?
or some type of workaround that's accurate.

explanation on the case insensitive argument  
most searchers user a /2 formula for case insensitive
 for example
1oojoo1 =888446610539
but
-c 1oojoo1 =444223305269
but in this case only 1/6 can be decreased
leaving 16.6666666667% of the prefix able to be divided by 2
(8.3333333333) therefore a reduction of 8.3333333333% of the initial 888446610539 difficulty
this means the adjusted difficulty is truly 74037217544 (I think Huh) with a case insensitive option applied.

I really am out of my league on this the following formulas have been reversed engineered to the best of our ability and is obviously still incorrect.
I'd like to credit OverGril for helping me attempt to solve this we are trying to create a service thats mostly free to all but we need more pinpoint accuracy in order to do this.

Help us figure this out so we can plug it into a input field and output a true difficulty so we can do accurate time estimates.

PM me accurate solution/formula for a reward

Code:
-snipped after solved
Pages:
Jump to: