Hello
I would like to share with you one thing I found recently - maybe you will give me a hint how to use it in the most effective way.
Recently I published my WIF Solver (
https://github.com/PawelGorny/WifSolver) with several ways to 'attack' problem of missing characters. I would like to talk about method called JUMP. Please let me describe the method and then I will ask a question.
In the example in my project I use WIF L5EZftvrYaSud_____zTqLcHLNDoVn7H5HSfM9BAN6tMJX8oTWz6 (taken from a very helpful site learnmeabitcoin.com).
So, let's take the WIF and replace missing characters by '1', we will get:
L5EZftvrYaSud11111zTqLcHLNDoVn7H5HSfM9BAN6tMJX8oTWz6 and try to decode it. We will get a hex string, starting with '80' + priv key + compression flag + checksum. Lets call it hexInit
As we see, compression flag is incorrect - so something is wrong... Go on.
I focus on fact that for any correct WIF generated from the initial one, after decoding there must be a flag '01' and given checksum. Now, let's jump to the first missing character on the right. We may say, that when we iterate Base58 characters in fact we increase our hex number (08+priv+01+checksum) by 58^34. But I realized that adding 58^34 to hexInit will change the last bytes - checksum and compression. I asked myself - is there a combination which will set '01' + expected checksum again (I mean not only in the real WIF which we look for?).
So I add 58^34 several times and yes! WIF: L5EZftvrYaSud1111uzTqLcHLNDoVn7H5HSfM9BAN6tMJX8oTWz6 produces desired ending.
(in fact I check existence of flag '01' and not the full checksum, but last 7 characters - I found that the 8th character from right could be different)
We have our WIF which we may use as a starter for calculations.
The other question is - is there a fixed length of jump? And question is again yes - for this case length is 64.
Which means that we may now forget about working on WIF and instead start working on 'numbers'.
Let's take number starter = 80ef235aacf90d9f4a9df7ba29006cad4ec1c6610833d3a8587b4d7c662e5ce97a0166557e53 and increase it, but not by 58^34 (like it would be in brute force method - just a next Base58 character) but by 64*(58^34) - we have our jump 240921c8be82fd68a2a77fba0089f71029354609c90000000000 - as we see last 10 characters are 0, so it will not change the end of 'decoded' hex string.
This way we save some time, because we do much less number of additions.
[By the way, I also checked what are then possible characters on 34th, 33rd, 32nd... position), and we may find that we have 29*29*29... correct combinations, which is much more optimistic that 58*58*...]
Now, my question is:
Replacing missing letters by 111 -> zzzz, +- with correction for a 'valid' starter/finish, we may find a target range [starter, finish]. And we know that we may use jump as a number to add, which makes our range not 'continuous' but sparse (we may think about it like about islands). Is there any method 'smarter' than brute-force iteration? We may make an assumption that we look for pubkey, not address if it helps.
Of course we may change our variables, remove unneeded characters and pass is to BitCrack (
it would have keyspace start=ef235aacf90d9f4a9df7ba29006cad4ec1c6610833d3a8587b4d7c662e5ce97a and stride=240921c8be82fd68a2a77fba0089f71029354609c9) and then search for address. But is there any better way?
start:
ef235aacf90d9f4a9df7ba29006cad4ec1c6610833d3a8587b4d7c662e5ce97a
end:
ef235aacf90d9f4ab3fedd0341bb04f1bd6de2b22006062c40d74b022f965fee
jump:
240921C8BE82FD68A2A77FBA0089F71029354609C9
(diff: 160722da414e57a2fba781a9ec325dd3c589ce9c01397674) - full range
diff/jump = 9c7cd4 - number of strides to do
result:
ef235aacf90d9f4aadd8c92e4b2562e1d9eb97f0df9ba3b508258739cb013db2
pubkey:
02b4632d08485ff1df2db55b9dafd23347d1c47a457072a1e87be26896549a8737
Show Posts
