 Show Posts
|
|
Pages: [1] 2 »
|
Hi! I am looking into this challenge and wondering.. Could be the address of some puzzles was generated from an uncompressed public key? from what I know you can't tell if the address is compressed or uncompressed by just looking at it.. or am overthinking it? :/
Overthinking it. If you read back through the history of this challenge, the creator stated they were compressed. And all keys found thus far have been found using compressed format. well I hope so, but I don't remember that I have encountered a statement from the creator of this puzzle that explicitly says the addresses are compressed. I started to question it indeed when I see this challenge laying around for years with no progress.. a lot of questions arises.. maybe a lot of people are doubting it.. anyway, I will spend some time here... My recollection was it was a temp account and he basically stated the format was intended to be sort of a benchmark of what is possible to brute force. |
|
|
|
if both results is the same X that is collision right? yes Thank you WanderingPhilospher Who can find out they have a collision? How did they find from some testing? I had not been here when started the puzzle Well, Collisions work from DPs and as on wikipedia "the similarity between a visualisation of the algorithm and the Greek letter lambda ( λ ). The shorter stroke of the letter lambda corresponds to the sequence { x i }, since it starts from the position b to the right of x. Accordingly, the longer stroke corresponds to the sequence { y i }, which "collides with" the first sequence (just like the strokes of a lambda intersect) and then follows it subsequently. " You know you have a collision if two different kangaroos start to output the same value. Say K1 output 1,3,5,8,9 and K2 output 2,4,5,8,9 we know that between K1 and K2 after 3 or 2 they collide. We then can then refer to the tame kangaroo and correlate the input value of the wild one or as JeanLucPons put it himself "The program uses 2 herds of kangaroos, a tame herd and a wild herd. When 2 kangoroos (a wild one and a tame one) collide, the key can be solved". the actual outputs are valid public keys and the inputs are valid private keys. |
|
|
|
Hi I have been interested in the puzzle for several months and after months of scanning and learning I found a site that seems to have scanned all the range' in #64 puzzle's keyspace (from 2^63 till 2^64-1 decimal, 0x8000 0000 0000 0000 - 0xFFFF FFFF FFFF FFFF) and he find nothing. https://hashkeys.club/64/. How is possible? Sorry for google translate. Can someone explain to me!  As I told before, this puzzle is not true. don't waste your time and money.. there is someone that wants us to be buzzy with something that doesn't exist. that is my conclusion.  The puzzle is not true EVEN though people have found keys within the puzzle?! Every key from 1 to 63 bits has been found and every key that is a multiple of 5 has been found, up to 115 bits...but yeah, it's not true. Where do you people come from and/or where do you get your information from that helps you draw conclusions?! I believe he meant the context of it being a puzzle specifically . It is a random distribution so far as we know only solvable via Kangaroo in some cases or brute force otherwise. |
|
|
|
Ok, that's 1,4 billion k/s.
Makes sense.
Yes, Around 1.4 Billion peak. it fluctuates but not wildly. |
|
|
|
what would be the cheapest gpu's (but still acceptable speed) that I could purchase for participating in this puzzle?
please any recommendations
You need to understand that is not the right question. here is my previous post on this subject: https://bitcointalk.org/index.php?topic=1306983.msg59904434#msg59904434or in summary: "you need 2724 2080ti approximately to do puzzle 64 in one month with bitcrack. 1362 if you correctly guess which half of the range it is in. or in other words 1,830,035 optimal 2080ti hours for $24,000. mine is a founder edition and can hit 1,400,000,000 Mk/s with -b 4532 -t 32 -p 584." running One 2080ti 24/7 is not really advisable. running 2724 is not worth $24,000. a 3070 might be similar to my 2080ti and according to some data I have ~954 3090s would do it in a month. so to wrap it up 1. you have to first guess a lucky number and hope it's close. 2. get as efficient (modern NVIDIA for cuda) a card as you can 3. stick with it for months ...just for the slim chance of getting it. some 'attempts' have been made at pooling resources but stick with it for months still applies |
|
|
|
you write the code and i have resource to run i have 16 tesla A100 gpus with it we can scan unto 23 TKey/s
Holy shit! how you got 16 Tesla's A100 GPUS? aren't they expensive? i guess each one cost +10k$? Have you tested the speed of all the teslas GPUS? 23 TKey/s? in which programm Vanitysearch? I have tested it on CuBitcrack i don't own it. i have it with HPC and yes it can scan 23 TKey/s Pm me, we can crac1,2 puzzles if you have fast hdd, lot of memory, and CUDA. I can downgrade pubkey 120 to 90 bit, but we need crack2^30 pubkey for get privkey... How exactly did you find this 1 out of 536,870,912 2^90 segments of puzzle 120? |
|
|
|
That's 3 Trillion key/s. This is crazy. I thought it was easier than that. But anyways If i knew where it is in the 32 ranges, i'd definitely crack it. But since there's 32 of them, and each range will take one month, it'll impossible to do because of electricity cost. Your right though. I wish we had an special weird algorithm to somehow get the public key of address 64.  perhaps some people will hopefully invent in the future such programs.. I'm glad we have what we do, your puzzle would of been puzzle 2^53 solved 2017-09-04 16:23, 1 years 0 months 16 days before the launch of the 2080ti. 53,'180788E47E326C','15K1YKJMiJ4fpesTVUcByoz334rHmknxmT','9007199254740991','020faaf5f3afe58300a335874c80681cf66933e2a7aeb28387c0d28bb048bc6349' someday...... |
|
|
|
you need 2724 2080ti approximately to do puzzle 64 in one month with bitcrack.
so in 2 months 2724 2080tis would get you ~$75,000.
I can send you 2724 ranges for puzzle 64 if you would like.
Wow 2724 2080Ti to do puzzle 64 in one month? Damn, i thought of like 50-100 would be more than enough. In what speed can this be in one month achievable? That's definitely not worth it. Nono, it's okay, well i can't have 2724 GPUs anyway. that's way too much than i expected. 3,812,571,113,117 Keys Per Second Sustained For One Avg Month. so 4 TK/s doubling every puzzle well it's more nuanced. here are 32 ranges ['8000000000000000:8400000000000000', '8400000000000000:8800000000000000', '8800000000000000:8c00000000000000', '8c00000000000000:9000000000000000', '9000000000000000:9400000000000000', '9400000000000000:9800000000000000', '9800000000000000:9c00000000000000', '9c00000000000000:a000000000000000', 'a000000000000000:a400000000000000', 'a400000000000000:a800000000000000', 'a800000000000000:ac00000000000000', 'ac00000000000000:b000000000000000', 'b000000000000000:b400000000000000', 'b400000000000000:b800000000000000', 'b800000000000000:bc00000000000000', 'bc00000000000000:c000000000000000', 'c000000000000000:c400000000000000', 'c400000000000000:c800000000000000', 'c800000000000000:cc00000000000000', 'cc00000000000000:d000000000000000', 'd000000000000000:d400000000000000', 'd400000000000000:d800000000000000', 'd800000000000000:dc00000000000000', 'dc00000000000000:e000000000000000', 'e000000000000000:e400000000000000', 'e400000000000000:e800000000000000', 'e800000000000000:ec00000000000000', 'ec00000000000000:f000000000000000', 'f000000000000000:f400000000000000', 'f400000000000000:f800000000000000', 'f800000000000000:fc00000000000000', 'fc00000000000000:ffffffffffffffff'] one of them has it and would be found in a month with ~86 2080tis I like the kangaroo method JeanLucPons did a great job implementing Pollard's Lambda (Kangaroo) so that if we had the public key It would take less than a minute with one 2080ti. |
|
|
|
Now kangaroo found problem same BitCrack both range search is very large
kangaroo method still works but is stuck with a very large range of search
I do simple easy tests on both 120 bit and 160 bit (and 256) with keyspace (under 32 bit wide) nearby it is still found key
but when used with a very large rank and nowhere is key store, so kangaroo is stunned
Kangaroo and BSGS are both O root n complexity root 120 is 2^60 2^60 is 1,152,921,504,606,846,976. Can the discrete logarithm be computed in polynomial time on a classical computer? someday, but not tomorrow. |
|
|
|
Please tell me that you are joking. You will be spending more money on GPUS than the reward you could potential get.
No, i'm not joking. My company that i work in has currenly free GPUs for free renting. That's what i thought. I thought of solving puzzle 64 to 69 with the help of free GPUs. you need 2724 2080ti approximately to do puzzle 64 in one month with bitcrack. 1362 if you correctly guess which half of the range it is in. or in other words 1,830,035 optimal 2080ti hours for $24,000. mine is a founder edition and can hit 1,400,000,000 Mk/s with -b 4532 -t 32 -p 584. puzzle 66 is 4 times larger than 64 puzzle 67 is 8 times larger than 64 puzzle 68 is 16 times larger than 64 puzzle 69 is 32 times larger than 64 puzzle 120 with the Kangaroo method is approximately the same difficulty and would yield ~$50,000. puzzle 125 is 10x puzzle 120 so in 2 months 2724 2080tis would get you ~$75,000. I can send you 2724 ranges for puzzle 64 if you would like. |
|
|
|
Hi, is there a way to find private key range from the public key, (Start and Stop range) ? Can someone point me to the right direction
For any random private key this is not (yet?) possible, in the case of the puzzle the creator initially put an amount of btc correlating to the bit length of the corresponding key. Like 0.64 btc to puzzle 64 (16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN) |
|
|
|
paniker this is meaning that you can change the n's
modular elliptic curve
Total of all the wallets n is the last number. n= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (In Dec)
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (In HEX)
Half way of n n//2 = 57896044618658097711785492504343953926418782139537452191302581570759080747169
57896044618658097711785492504343953926418782139537452191302581570759080747169 Lenght Bits = 255
very nice and thanks to boris.. you still here..
yes I am still here, this was the only thing I have found so far. Half way of n n//2 is wrong, check in above posts, mention clearly formula for div thankx do you mean the last "6" , 115792089237316195423570985008687907852837564279074904382605163141518161494337 ? There seems to be some confusion here. the largest possible private key is 115792089237316195423570985008687907852837564279074904382605163141518161494336 or in hex FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140 Zero cannot be a private key therefor there are 115,792,089,237,316,195,423,570,985,008,687,907,852,837,564,279,074,904,382,605,163,141,518,161,494,336 valid private keys It turns out there are only 57,896,044,618,658,097,711,785,492,504,343,953,926,418,782,139,537,452,191,302,581,570,759,080,747,168 valid public x coordinates It really is not straight forward to grasp as it took me time though it happens at half of the largest key which is 57896044618658097711785492504343953926418782139537452191302581570759080747168 or in hex 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 you see 57.........168 and 57.........169 have both the same public x coordinate and opposite y parity (fancy word for even/odd) removing the lead 03 or 02 It turns out that every public x coord from 1 to 57.........168 is exactly equal to the public x coord at the same spot in the sequence from 115........336 to 57.........169 finally, if you search every private key from 1 to 57,896,044,618,658,097,711,785,492,504,343,953,926,418,782,139,537,452,191,302,581,570,759,080,747,168 (exactly half the normal range) for a public x coord (the majority of a compressed public key) you would find it whether or not the original private key was larger or smaller than 57.........169 however a leading 03 would be 02 and vice versa therefor the limitation doesn't apply to the resulting addresses. In a sense the only thing we care about a private key with this equation is the position of the xcoord's "foundkey" 1 + (115........336-foundkey) or 115........336 - (foundkey-1) depending on which side of 57.........168.5 the foundkey is as we can infer the other and deduce the private key. In other words this would cut the time of brute forcing any public key in half provided you are searching the full range of 1 to 115........336. 57.........168 is still a lot of private keys so bitcoin is not exactly broken.....yet. Also with regards to the y value, What I mean when I say "it is trivial to calculate the y" value I am referencing the following information I had apparently left out, from the spec of Secp256k1 p = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F = 2^256 - 2^32 - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1 (115792089237316195423570985008687907853269984665640564039457584007908834671663) the aforementioned "twins" that share a public x coord also share a y coords in the manner that they are linked together as adding the two y coords together = p (115792089237316195423570985008687907853269984665640564039457584007908834671663) therefor it can be computed as following p - y1 = y2 deriving from my earlier code you can try it with this: for x in range(100000): s1 = secrets.randbelow(max) k = Key.from_int(s1) k._public_key = k._pk.public_key.format(compressed=False) s2 = twin(s1,k.pub_to_hex()) t = Key.from_int(s2[0]) t._public_key = t._pk.public_key.format(compressed=False) out = bool(115792089237316195423570985008687907853269984665640564039457584007908834671663 == int(t.pub_to_hex()[66:],16)+int(k.pub_to_hex()[66:],16)) print(out) if not out: print("Boris Is Wrong") break |
|
|
|
paniker this is meaning that you can change the n's
modular elliptic curve
Total of all the wallets n is the last number. n= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (In Dec)
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (In HEX)
Half way of n n//2 = 57896044618658097711785492504343953926418782139537452191302581570759080747169
57896044618658097711785492504343953926418782139537452191302581570759080747169 Lenght Bits = 255
very nice and thanks to boris.. you still here..
yes I am still here, this was the only thing I have found so far. Half way of n n//2 is wrong, check in above posts, mention clearly formula for div thankx do you mean the last "6" , 115792089237316195423570985008687907852837564279074904382605163141518161494337 ? There seems to be some confusion here. the largest possible private key is 115792089237316195423570985008687907852837564279074904382605163141518161494336 or in hex FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140 Zero cannot be a private key therefor there are 115,792,089,237,316,195,423,570,985,008,687,907,852,837,564,279,074,904,382,605,163,141,518,161,494,336 valid private keys It turns out there are only 57,896,044,618,658,097,711,785,492,504,343,953,926,418,782,139,537,452,191,302,581,570,759,080,747,168 valid public x coordinates It really is not straight forward to grasp as it took me time though it happens at half of the largest key which is 57896044618658097711785492504343953926418782139537452191302581570759080747168 or in hex 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 you see 57.........168 and 57.........169 have both the same public x coordinate and opposite y parity (fancy word for even/odd) removing the lead 03 or 02 It turns out that every public x coord from 1 to 57.........168 is exactly equal to the public x coord at the same spot in the sequence from 115........336 to 57.........169 finally, if you search every private key from 1 to 57,896,044,618,658,097,711,785,492,504,343,953,926,418,782,139,537,452,191,302,581,570,759,080,747,168 (exactly half the normal range) for a public x coord (the majority of a compressed public key) you would find it whether or not the original private key was larger or smaller than 57.........169 however a leading 03 would be 02 and vice versa therefor the limitation doesn't apply to the resulting addresses. In a sense the only thing we care about a private key with this equation is the position of the xcoord's "foundkey" 1 + (115........336-foundkey) or 115........336 - (foundkey-1) depending on which side of 57.........168.5 the foundkey is as we can infer the other and deduce the private key. In other words this would cut the time of brute forcing any public key in half provided you are searching the full range of 1 to 115........336. 57.........168 is still a lot of private keys so bitcoin is not exactly broken.....yet. |
|
|
|
paniker this is meaning that you can change the n's
modular elliptic curve
Total of all the wallets n is the last number. n= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (In Dec)
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (In HEX)
Half way of n n//2 = 57896044618658097711785492504343953926418782139537452191302581570759080747169
57896044618658097711785492504343953926418782139537452191302581570759080747169 Lenght Bits = 255
very nice and thanks to boris.. you still here..
yes I am still here, this was the only thing I have found so far. |
|
|
|
I found a method to find any private key within 2^255 bit space. Is that new?
Tell us if you've already decided to brag  Upd. Better yet, just prove it. I generated a random key. Here is the public key for it 0337aff652dd11e2870636b0c4ce4fb324f4b0df45e70f7d8c77d15fcc9ae73525 I would have to know the key for 0237aff652dd11e2870636b0c4ce4fb324f4b0df45e70f7d8c77d15fcc9ae73525 as it would we below ~2^255 if 0337aff652dd11e2870636b0c4ce4fb324f4b0df45e70f7d8c77d15fcc9ae73525 is above. |
|
|
|
I found a method to find any private key within 2^255 bit space. Is that new?
Can you tells us more about it?)) Absolutely, so it seems that the amount of valid public x-coords is exactly half the amount of private keys. So as the theory is any key in the full range (1-115792089237316195423570985008687907852837564279074904382605163141518161494336 ~2^256) either it is less than half (57896044618658097711785492504343953926418782139537452191302581570759080747168) or has the same x coordinate as one that does (above 57896044618658097711785492504343953926418782139537452191302581570759080747169). I have a mathematical function to find the resulting twin on either side. I really do like the work that has been done here on the Kangaroo software so I will provide my python function for reference of finding said twin so long as you know 1 of 2 private keys you will know both. ~2^255 is still a very large number. In the case of uncompressed keys you still have to compute the y coord after but it is trivial. (using the bit library for python as the function is not intensive) from bit import Key import secrets def twin(i, pubhex): max = 115792089237316195423570985008687907852837564279074904382605163141518161494336 if len(pubhex) == 66: publichex = str(pubhex)[2:66] if i < 57896044618658097711785492504343953926418782139537452191302581570759080747169: twin = max - (i-1) if str(pubhex)[:2] == '02': twinprefix = '03' return [twin,f'{twinprefix}{publichex}'] elif str(pubhex)[:2] == '03': twinprefix = '02' return [twin, f'{twinprefix}{publichex}'] elif i > 57896044618658097711785492504343953926418782139537452191302581570759080747168: twin = 1 + (max-i) if str(pubhex)[:2] == '02': twinprefix = '03' return [twin,f'{twinprefix}{publichex}'] elif str(pubhex)[:2] == '03': twinprefix = '02' return [twin,f'{twinprefix}{publichex}'] elif len(pubhex) == 130: publichex = str(pubhex)[2:66] if i < 57896044618658097711785492504343953926418782139537452191302581570759080747169: twin = max - (i-1) return [twin,f'uncomp,{publichex}'] elif i > 57896044618658097711785492504343953926418782139537452191302581570759080747168: twin = 1 + (max-i) return [twin, f'uncomp,{publichex}'] max = 115792089237316195423570985008687907852837564279074904382605163141518161494336 for x in range(100): q = secrets.randbelow(max) k = Key.from_int(x) t = twin(x,k.pub_to_hex()) pt = t[0] ptpub = Key.from_int(pt).pub_to_hex() print(t[1],ptpub) ''' # Or you can do this for x in range(1000): x = secrets.randbelow(max) k = Key.from_int(x) t = twin(x,k.pub_to_hex()) pt = t[0] ptpub = Key.from_int(pt).pub_to_hex() assert t[1] == ptpub ''' ''' # for uncompressed for x in range(100000): x = secrets.randbelow(max) k = Key.from_int(x) k._public_key = k._pk.public_key.format(compressed=False) t = twin(x,k.pub_to_hex()) pt = Key.from_int(t[0]) # this next line is not nessicary as we format the response without the leading '04' pt._public_key = pt._pk.public_key.format(compressed=False) ptpub = pt.pub_to_hex() assert t[1] == f'uncomp,{str(ptpub)[2:66]}' ''' |
|
|
|
|
I found a method to find any private key within 2^255 bit space. Is that new?
|
|
|
|
|
Unfortunately, I believe that he has passed away much like Hal Finney.
Though they are not the same person.
He loved what he did BTC.
|
|
|
|
|
as per someones suggestion earlier in the thread here is a list of the currently known private keys in relation to their accompanying range sizes in percentages.
sorted = [0.0, 0.06, 0.08, 0.09, 0.1, 0.12, 0.13, 0.17, 0.18, 0.19, 0.22, 0.23, 0.27, 0.28, 0.31, 0.32, 0.33, 0.35, 0.36, 0.38, 0.4, 0.43, 0.44, 0.45, 0.46, 0.49, 0.5, 0.51, 0.53, 0.57, 0.62, 0.63, 0.64, 0.65, 0.66, 0.67, 0.68, 0.69, 0.7, 0.72, 0.75, 0.82, 0.87, 0.91, 0.92, 0.95, 0.96, 0.97] (48 unique values)
sorted (raw) = [0.0, 0.0, 0.00390625, 0.0693586707348004, 0.08560360020207014, 0.09034376966231544, 0.10738698705333893, 0.1279296875, 0.13666732696611916, 0.17072322126477957, 0.1777045763192291, 0.1875, 0.19316889756160655, 0.2273166453323929, 0.23364647093694657, 0.23667356096793157, 0.2734375, 0.287109375, 0.2887251778456132, 0.31005859375, 0.3125, 0.3166639075566309, 0.32627265442988573, 0.33485841751098633, 0.3586072690006503, 0.3638877868652344, 0.36981157668053144, 0.3876168823447197, 0.4023493269008403, 0.43391395367944174, 0.43408918380737305, 0.44051053281873465, 0.45348233016493467, 0.4588522112899227, 0.46112229085167655, 0.4621429443359375, 0.4927569553256035, 0.5, 0.5018395352846268, 0.5149424275913058, 0.5157241821289062, 0.53125, 0.57196044921875, 0.6253847479820251, 0.63983154296875, 0.6439841804320401, 0.6453061435604468, 0.6466464996337891, 0.6571150545548307, 0.6618142630904913, 0.6678542153963616, 0.6681841164827347, 0.6797900857488876, 0.6847959722838368, 0.6949864005878701, 0.6960085034370422, 0.7005655069250736, 0.7200322151184082, 0.7278327941894531, 0.75, 0.75, 0.7513186500162874, 0.8217038442259545, 0.82421875, 0.8256312850098766, 0.8285546544961626, 0.8289294721848898, 0.8725002169265093, 0.9185453074950023, 0.9244143441319466, 0.9500958897872267, 0.9580019181594253, 0.9689828764301732, 0.9780104756355286]
the missing points would be these ranges:
['8147ae147ae14800:828f5c28f5c29000', '828f5c28f5c29000:83d70a3d70a3d800', '83d70a3d70a3d800:851eb851eb852000', '851eb851eb852000:8666666666666800', '8666666666666800:87ae147ae147b000', '88f5c28f5c28f800:8a3d70a3d70a4000', '8e147ae147ae1800:8f5c28f5c28f6000', '91eb851eb851f000:9333333333333000', '9333333333333000:947ae147ae147800', '947ae147ae147800:95c28f5c28f5c000', '9999999999999800:9ae147ae147ae000', '9ae147ae147ae000:9c28f5c28f5c2800', '9eb851eb851eb800:a000000000000000', 'a000000000000000:a147ae147ae14800', 'a147ae147ae14800:a28f5c28f5c29000', 'a51eb851eb852000:a666666666666800', 'a666666666666800:a7ae147ae147b000', 'ab851eb851eb8800:acccccccccccd000', 'af5c28f5c28f6000:b0a3d70a3d70a000', 'b1eb851eb851f000:b333333333333000', 'b47ae147ae147800:b5c28f5c28f5c000', 'b5c28f5c28f5c000:b70a3d70a3d70800', 'bc28f5c28f5c2800:bd70a3d70a3d7000', 'bd70a3d70a3d7000:beb851eb851eb800', 'c28f5c28f5c29000:c3d70a3d70a3d800', 'c51eb851eb852000:c666666666666800', 'c666666666666800:c7ae147ae147b000', 'c7ae147ae147b000:c8f5c28f5c28f800', 'ca3d70a3d70a4000:cb851eb851eb8000', 'cb851eb851eb8000:ccccccccccccd000', 'ccccccccccccd000:ce147ae147ae1000', 'ce147ae147ae1000:cf5c28f5c28f6000', 'dae147ae147ae000:dc28f5c28f5c2800', 'dd70a3d70a3d7000:deb851eb851eb800', 'deb851eb851eb800:e000000000000000', 'e147ae147ae14800:e28f5c28f5c29000', 'e28f5c28f5c29000:e3d70a3d70a3d800', 'e3d70a3d70a3d800:e51eb851eb852000', 'e51eb851eb852000:e666666666666800', 'e666666666666800:e7ae147ae147b000', 'e7ae147ae147b000:e8f5c28f5c28f800', 'ea3d70a3d70a4000:eb851eb851eb8000', 'eb851eb851eb8000:ecccccccccccd000', 'ecccccccccccd000:ee147ae147ae1000', 'ee147ae147ae1000:ef5c28f5c28f6000', 'f0a3d70a3d70a000:f1eb851eb851f000', 'f1eb851eb851f000:f333333333333000', 'f333333333333000:f47ae147ae148000', 'f70a3d70a3d71000:f851eb851eb85000', 'f851eb851eb85000:f999999999999800', 'fd70a3d70a3d7000:feb851eb851eb800', 'feb851eb851eb800:ffffffffffffffff']
though that does not help much each range in the 63bit key range would take approximately 18,000 hours on Bitcrack with 1400Mk/s
|
|
|
|
Which b? Between which 2 and H?  well I have the alphabet backwards so 2 H b would be the correct order 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz |
|
|
|
|
