WhyFhy (OP)
|
|
March 30, 2022, 10:55:29 PM Last edit: April 08, 2022, 01:07:28 PM by WhyFhy |
|
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 ) 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
|
|
|
|
WhyFhy (OP)
|
|
April 04, 2022, 10:38:06 PM |
|
Bump , Still trying to solve
|
|
|
|
PawGo
Legendary
Offline
Activity: 952
Merit: 1385
|
|
April 05, 2022, 06:47:55 AM Last edit: April 05, 2022, 07:27:38 AM by PawGo |
|
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
|
|
|
|
WhyFhy (OP)
|
|
April 05, 2022, 06:48:08 PM |
|
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.
|
|
|
|
PawGo
Legendary
Offline
Activity: 952
Merit: 1385
|
|
April 05, 2022, 07:15:08 PM |
|
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 it->difficulty = pow(2, 5*(prefix.length()-4)); for bech32 or it->difficulty = pow(256, prefix.length() - 1); For p2sh You will find that calculations in https://raw.githubusercontent.com/JeanLucPons/VanitySearch/master/Vanity.cppThen there are minor updates if you search for several etc, but base values are like above.
|
|
|
|
WhyFhy (OP)
|
|
April 05, 2022, 07:42:00 PM Last edit: April 06, 2022, 01:05:28 AM by WhyFhy |
|
-snip
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.
|
|
|
|
LoyceV
Legendary
Offline
Activity: 3444
Merit: 17452
Thick-Skinned Gang Leader and Golden Feather 2021
|
|
April 06, 2022, 08:01:49 AM |
|
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 ) 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: ./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%: ./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: ./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.
|
|
|
|
PawGo
Legendary
Offline
Activity: 952
Merit: 1385
|
|
April 06, 2022, 08:23:13 AM Last edit: April 06, 2022, 11:48:29 AM by PawGo Merited by BlackHatCoiner (1), WhyFhy (1) |
|
If, however, you would search for "tt", the difficulty drops by 75% because you're now searching for 4 different prefixes: ./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.
|
|
|
|
WhyFhy (OP)
|
If, however, you would search for "tt", the difficulty drops by 75% because you're now searching for 4 different prefixes: ./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.cwhat 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 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.
|
|
|
|
n0nce
|
|
April 07, 2022, 12:31:57 PM |
|
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.
|
|
|
|
philipma1957
Legendary
Offline
Activity: 4256
Merit: 8603
'The right to privacy matters'
|
|
April 07, 2022, 06:50:36 PM |
|
If, however, you would search for "tt", the difficulty drops by 75% because you're now searching for 4 different prefixes: ./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.cwhat 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 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. Curious as to the amount of gear has to run to do what you do. Also Could a remote miner be added? Ie I have a rig with 11x rtx a4500 cards and 1x rtx a5000 cards. could it pool to your setup? I also have 2 rigs with 12x rtx a4000 cards I know your state is nowhere near NJ but if the project could allow remote rigs to tie in you could do 10 or 12 custom vs 7
|
|
|
|
WhyFhy (OP)
|
|
April 08, 2022, 01:00:51 AM |
|
Curious as to the amount of gear has to run to do what you do. Also Could a remote miner be added? Ie I have a rig with 11x rtx a4500 cards and 1x rtx a5000 cards. could it pool to your setup? I also have 2 rigs with 12x rtx a4000 cards I know your state is nowhere near NJ but if the project could allow remote rigs to tie in you could do 10 or 12 custom vs 7
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.
|
|
|
|
WhyFhy (OP)
|
|
April 08, 2022, 03:20:03 AM Last edit: April 08, 2022, 01:23:24 PM by WhyFhy |
|
On a side note, I think I've solved the site calculator heres a breakdown excluding the pivot witchcraft (to me) PLEASE tell me if I'm wrong and point me in the right direction, if I'm right the site will go live soon with accurate(affordable) pricing -snipped edit solved
|
|
|
|
LoyceV
Legendary
Offline
Activity: 3444
Merit: 17452
Thick-Skinned Gang Leader and Golden Feather 2021
|
|
April 08, 2022, 09:11:58 AM |
|
11 = 256 111 = 65536 256 * 256 1111 = 16777216 256 * 256 * 256 1111A = 264104224 1354 * 58 * 58 112 = 1354 23*58 11a = 78509 1354 * 58 11R = 78509 1354 * 58 11RRa = 264104224 1354 * 58 * 58 * 58 1aa = 78509 1354 * 58 1AA = 1354 23 * 58 1AAz = 78509 23 * 58 * 58 1zAA = 4553521 1354 * 58 * 58 1AzA = 78509 23 * 58 * 58 1AA1AA = 264104224 23 * 58 * 58 * 58 * 58 1zz1zz = 15318045009 1354 * 58 * 58 * 58 * 58 1zz11z = 15318045009 1354 * 58 * 58 * 58 * 58 1111zz = 888,446,610,539 1354 * 58 * 58 * 58 * 58 *58 (If trailing 1's with a R-z add a * 58 operation) 1111AA = 15318045009 1354 * 58 * 58 * 58 * 58 1ABCDE = 264104224 23 * 58 * 58 * 58 * 58 1ABCDz = 264104224 23 * 58 * 58 * 58 * 58 1oiL = 4553521 1354 * 58 * 58 Vanitygen gives slightly different values for some: 11: Difficulty: 256 111: Difficulty: 65536 1111: Difficulty: 16777216 1111A: Difficulty: 259627881 112: Difficulty: 1335 11a: Difficulty: 78508 11R: Difficulty: 78508 11RRa: Difficulty: 264104224 1aa: Difficulty: 78508 1AA: Difficulty: 1330 1AAz: Difficulty: 77178 1zAA: Difficulty: 4553521 1AzA: Difficulty: 77178 1AA1AA: Difficulty: 259627881 1zz1zz: Difficulty: 15318045009 1zz11z: Difficulty: 15318045009 1111zz: Difficulty: 888446610538 1111AA: Difficulty: 15058417127 1ABCDE: Difficulty: 259627881 1ABCDz: Difficulty: 259627881 1oiL: Difficulty: 4553521
|
|
|
|
WhyFhy (OP)
|
|
April 08, 2022, 01:02:05 PM |
|
-snip Vanitygen gives slightly different values for some: Loyce thank you so much for checking those out! I expected about a %4.35 variation max due to rounding differences sometime base numbers are different too. such as 23/24(4.35%) , and 1330/1334/1354 (1.80%) but reading below I think we can reduce the error rate down to 1.8% overall. These rounding differences only really show themselves when dividing the difficulty. for example 264,181,648/58^3= 1354 (My method) or /4 for 23.34 264104224/58^3= 1,353.60318176227 (VS) /4 for 23.33 259627881/58^3= 1,330.660753823445 (VG) /4 for 22.94 260,474,520/58^3= 1335 or /4 23.01 what VG should show given they use 1335 as R-z difficulty From what I see I think I can cancel out 4.35% error rate and reduce it down to about 1.7539591597%(using 13XX) or 1.743679163 (using 22.94-23.34) I typo'd 1111A = 264104224 1354 * 58 * 58 * 58 forgot a * 58 operation Another reason this is important that it reflects onsite near the same as the searcher programs is the handler software can use any prefix finding software. Thank you guys for the help , if we can figure out the whole pivot thing VG talks about that would be cool too but I wont push my luck
|
|
|
|
LoyceV
Legendary
Offline
Activity: 3444
Merit: 17452
Thick-Skinned Gang Leader and Golden Feather 2021
|
|
April 09, 2022, 11:05:24 AM |
|
Loyce thank you so much for checking those out! For future reference, I used this: for prefix in `cat /tmp/list | cut -d' ' -f1`; do echo -n "$prefix: "; ./vanitygen -n $prefix | grep Diffi; done I expected about a %4.35 variation max due to rounding differences 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.
|
|
|
|
RoxxR
|
|
April 10, 2022, 08:20:46 AM |
|
splitkey looks like a really nice service!
out of curiosity, please can you give a quote and time estimate for these prefixes: 1111111 11111111 11111113 111111113 1111111MM
|
|
|
|
WhyFhy (OP)
|
|
April 10, 2022, 06:07:36 PM |
|
splitkey looks like a really nice service!
out of curiosity, please can you give a quote and time estimate for these prefixes: 1111111 11111111 11111113 111111113 1111111MM
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
|
|
|
|
LoyceV
Legendary
Offline
Activity: 3444
Merit: 17452
Thick-Skinned Gang Leader and Golden Feather 2021
|
|
April 10, 2022, 06:34:37 PM |
|
11111111= 72057594037927936 (96 days) *** 111111113= 173346595075428800 240 days *** This can't be right, right? The second one has only 2.4 times higher difficulty than the first. According to vanitygen, it should be 5.7 times more difficult. According to vanitygen, 1113 is 69 times more difficult than 111, but 111113 is only 3.5 times more difficult than 11111. I don't get it.
|
|
|
|
WhyFhy (OP)
|
|
April 10, 2022, 09:47:43 PM |
|
11111111= 72057594037927936 (96 days) *** 111111113= 173346595075428800 240 days *** This can't be right, right? The second one has only 2.4 times higher difficulty than the first. According to vanitygen, it should be 5.7 times more difficult. According to vanitygen, 1113 is 69 times more difficult than 111, but 111113 is only 3.5 times more difficult than 11111. I don't get it. 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.
|
|
|
|
|