Bump , Still trying to solve

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.

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.

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.

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

Its a yes no thing, as mentioned here.

We can link miners everywhere/anywhere and grow the MK/S, as for now we cant check key count honesty. We can only determine based on what you input in this software.



We haven't decided if this handler tool will be open source or not. So far the only thing that is OS is the merge tool built off bitaddress.org

To clarify we can do certain difficulties for free in some instances that's up to 7 digits usually in under 5 mins

1Philipma1957's (case insensitive) Difficulty is 36446121614608900096 would take about 130 years with 12000 mk/s for one result that may not even be correct

if it Wasn't splitkey 130~ years on the first try. If you double the the key count, you can half the time estimate.

1Philipma (case insensitive) Difficulty is 3,220,618,963,203 we could get one result every 5 mins. ~ @12000 mk/p

for example just testing it to snag the difficulty

PubAddress: 1PhiLiPMAXUoMbCBqZCJbiVYzjAyQYF9zL
Priv (WIF): p2pkh:L2piDYLuwW4TrYVKtEVQ5kPsBuVFQDRzqeLgwFnUVqzQTV2CF1zV
Priv (HEX): 0xA7314E00BE8FDCCF7C5A7AA2F2BB5AB5672037018A25DEF960503B9D299177F9

got a hit with 1 of 3 machines with the software installed, (wasnt splitkey)

1Philipma19 (case insensitive) Difficulty is 1910834162192214300 putting out 1 result every 10 days or so,

 (we go for master key not the others we check your pubkey vs our partialpriv in another headless html pruned version of bitaddress.org)

So 10 digits is doable , this testing was done on one rig, we have 3 in test with 2 more to add , start tossing in 24 x a4000's and 11x a 4500's  we could slim these estimates down a lot ,

Our plan for 9+ digits was to just rent 16x sxm4 lamda rigs,  

We've debated releasing an opensource splitkey vanity handler for "Pooling" software does callback with key estimates and we provide discount based on the contributed keyspersecond.

Not case sensitive , but 1PHiLiPMA is going to be fastest route to find

Kinda like mining rig rentals with some slick workarounds for validations instead of full blown pools.  

We would autoconfigure your arguments via cli wmic or smi ect and run your results against a database of card speeds that are logged in a database

We have to figure out this difficulty/pivot stuff for precise accuracy though.

If you wanted to run your speeds for me I could give you more accurate estimates based on what I know,

VanitySearch.exe already compiled. with that kind of gear you could surely get 1PhiLiPMA before you go to bed.

Our quotes are broken right now until I get help figuring out the the broken formula in the main post adding the extra *58 operation.

Our quote for 1PHiLiPMA says difficulty=294,545,08,795,143,700 but 1PHiLiPMA is really 51,529,903,411,245 So we have 1 *58 operation too many in the code above.

Vanitygen gives slightly different values for some:

For future reference, I used this:

If it's never more than that, you could just ignore it. I assume you have more than 5% margin for the service you're planning, so it should still be profitable.
Or maybe you can test for instance 1000 rounds, and see how many keys you have to search through. If you do this often enough, you should get an accurate estimate.

testing with 12000mk/s (1 rig)
1111111=         281474976710656 Under a day ~$80
11111111=    72057594037927936 (96 days) ***
11111113=      2988734397852220 About 2 weeks ~$650
111111113= 173346595075428800   240 days ***
1111111MM=10054102514374868992 36 years ***
with the entire farm's applied we can confidently estimate half the time at about 24000 mk/s
We haven't plugged in the entire farm yet to see total key counts to accurately quote times against total keys per second.


***
 with problems like these we would rent lambda A100 x16 sxm4 systems to knock em out  we wouldn't splitkey in this case just set you up to find it yourself on rental and youll find it in less time.
we'd charge a percentage for non split key and you revoke ssh key after we set you up considering you know about the trailing numbers being X256 time's more difficult we could assume you can operate a remote server, again this service is geared towards retails investor's not script manipulators or trailing number seekers that can do it on their own. Odds are we are going to deny trailing 1 orders,its to difficult to make the client side calculator work in this instance and c# starts struggling/breaks.
We will probally just do email request for these pivots and trailing 1's orders   

The part where I was asking about pivots
1QLbz6
VS=264,104,224
1QLbz7
VS=264,104,224
VG=837,596,142 (true difficulty)

3.165 ~ difference 
I've been asking all along for help with the pivots. But no one has answers to the witchcraft involved. So the above formula's excludes it/pivots.
Since  Vanitysearch doesn't factor them in I dont know how to tell. 
I tried figuring out how PCRE does it but im not savvy in how it was wrote.
Aside from Nonce , no ones even bothered or acknowledged me asking about pivots or admitted JLVS is wrong on calculations involving pivots.