Bitcoin puzzle transaction ~32 BTC prize to who solves it

[alek76]

Someone said that the parity of the target private key does not matter  
This has implications for the choice of divisor.
If the private key is divisible by divide key without a remainder, then the divisor is correct. PrivKey % DivideKey = 0.
But because the target key is not known, the correct divisor can only be random.
The same applies to public keys, which also have parity.
Example of correct divisors for a test private key:
0x197D95F81F7BA421E829611A8F8BB1204 % 0x15B = 0

Code:

[i] NB: 0 DIVKey: 1 Inverse DivideKey: 1     
[i] 1 TRUE DIVIDER NB: 4 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x2 Result: 0xCBECAFC0FBDD210F414B08D47C5D8902 
[i] 2 TRUE DIVIDER NB: 62 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x7 Result: 0x3A439FEDFED17728EE15703CB5D194DC 
[i] 3 TRUE DIVIDER NB: 126 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x1 Result: 0x197D95F81F7BA421E829611A8F8BB1204 
[i] NB: 200 DIVKey: 10C Inverse DivideKey: 2DD9CA81E9131ABF0B7672A07A44C6AF8899965ECF27C0FF3D1A3724AED80BB     
[i] 4 TRUE DIVIDER NB: 329 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x2 Result: 0xCBECAFC0FBDD210F414B08D47C5D8902 
[i] NB: 400 DIVKey: 23C Inverse DivideKey: 51E6EFE35B4CFAA11E6EFE35B4CFAA117EDBBF8316F5AB35212C7A71F936F3C2     
[i] 5 TRUE DIVIDER NB: 418 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x15B Result: 0x12CE43D9BA45157E164076DAC9CF14C 
[i] 6 TRUE DIVIDER NB: 585 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x4 Result: 0x65F657E07DEE9087A0A5846A3E2EC481 
[i] NB: 600 DIVKey: 23E Inverse DivideKey: 4039164CB5F71484039164CB5F71483FE77978885DECC19E99607B9F4FE2CBB     
[i] NB: 800 DIVKey: 1C0 Inverse DivideKey: 6D24924924924924924924924924924899E043E4A2BAF6997935B04F767BB3D2     
[i] 7 TRUE DIVIDER NB: 809 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x373 Result: 0x763E70ED25521F5892DEADDA978CEC 
[i] 8 TRUE DIVIDER NB: 834 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x1 Result: 0x197D95F81F7BA421E829611A8F8BB1204 
[i] NB: 1000 DIVKey: DE Inverse DivideKey: B9A85C40939A85C40939A85C40939A84D81BA4D0CFD743C5DAAE799D7904C09F     
[i] 9 TRUE DIVIDER NB: 1062 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x15B Result: 0x12CE43D9BA45157E164076DAC9CF14C 
[i] 10 TRUE DIVIDER NB: 1072 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x2 Result: 0xCBECAFC0FBDD210F414B08D47C5D8902 
[i] 11 TRUE DIVIDER NB: 1127 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x15B Result: 0x12CE43D9BA45157E164076DAC9CF14C 
[i] 12 TRUE DIVIDER NB: 1169 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x2 Result: 0xCBECAFC0FBDD210F414B08D47C5D8902 
[i] NB: 1200 DIVKey: 14C Inverse DivideKey: 80C565C87B5F9D4D1BC2503159721ED743AFDC9C2231A3E05E2CE713F071A6FE     
[i] 13 TRUE DIVIDER NB: 1337 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x1C Result: 0xE90E7FB7FB45DCA3B855C0F2D746537 
[i] NB: 1400 DIVKey: 2C0 Inverse DivideKey: A28BA2E8BA2E8BA2E8BA2E8BA2E8BA2DBD141E710462D73192E306F16890FE86     
[i] 14 TRUE DIVIDER NB: 1477 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x2 Result: 0xCBECAFC0FBDD210F414B08D47C5D8902 
[i] 15 TRUE DIVIDER NB: 1542 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x4 Result: 0x65F657E07DEE9087A0A5846A3E2EC481 
[i] 16 TRUE DIVIDER NB: 1578 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x373 Result: 0x763E70ED25521F5892DEADDA978CEC 
[i] NB: 1600 DIVKey: 1EE Inverse DivideKey: 79C8084A9F9C8084A9F9C8084A9F9C7FE9E86E4447FBAEAF98EB545CE5A3A7DA     
[i] 17 TRUE DIVIDER NB: 1619 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x2B6 Result: 0x96721ECDD228ABF0B203B6D64E78A6 
[i] NB: 1800 DIVKey: 346 Inverse DivideKey: 50F46433527B6AEBD67415FEC72DD2C938973869F12AD2BF30BEDBE9EEBFE597     
[i] 18 TRUE DIVIDER NB: 1880 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x1C Result: 0xE90E7FB7FB45DCA3B855C0F2D746537 
[i] NB: 2000 DIVKey: 4A Inverse DivideKey: 2CF914C1BACF914C1BACF914C1BACF9112F534A510F48ADA1066AFBECAA1BF5B     
[i] Data Saved in file DivideKeys.txt 

It is impossible to find the correct divisor for a public key; you need a private key.

[1714323479]

1714323479

[1714323479]

1714323479

[1714323479]

1714323479

[mcdouglasx]

Someone said that the parity of the target private key does not matter  
This has implications for the choice of divisor.
If the private key is divisible by 2 without a remainder, then the divisor is correct. PrivKey % 2 = 0.
But because the target key is not known, the correct divisor can only be random.
The same applies to public keys, which also have parity.
Example of correct divisors for a test private key:
0x197D95F81F7BA421E829611A8F8BB1204 % 0x15B = 0

Code:

[i] NB: 0 DIVKey: 1 Inverse DivideKey: 1     
[i] 1 TRUE DIVIDER NB: 4 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x2 Result: 0xCBECAFC0FBDD210F414B08D47C5D8902 
[i] 2 TRUE DIVIDER NB: 62 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x7 Result: 0x3A439FEDFED17728EE15703CB5D194DC 
[i] 3 TRUE DIVIDER NB: 126 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x1 Result: 0x197D95F81F7BA421E829611A8F8BB1204 
[i] NB: 200 DIVKey: 10C Inverse DivideKey: 2DD9CA81E9131ABF0B7672A07A44C6AF8899965ECF27C0FF3D1A3724AED80BB     
[i] 4 TRUE DIVIDER NB: 329 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x2 Result: 0xCBECAFC0FBDD210F414B08D47C5D8902 
[i] NB: 400 DIVKey: 23C Inverse DivideKey: 51E6EFE35B4CFAA11E6EFE35B4CFAA117EDBBF8316F5AB35212C7A71F936F3C2     
[i] 5 TRUE DIVIDER NB: 418 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x15B Result: 0x12CE43D9BA45157E164076DAC9CF14C 
[i] 6 TRUE DIVIDER NB: 585 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x4 Result: 0x65F657E07DEE9087A0A5846A3E2EC481 
[i] NB: 600 DIVKey: 23E Inverse DivideKey: 4039164CB5F71484039164CB5F71483FE77978885DECC19E99607B9F4FE2CBB     
[i] NB: 800 DIVKey: 1C0 Inverse DivideKey: 6D24924924924924924924924924924899E043E4A2BAF6997935B04F767BB3D2     
[i] 7 TRUE DIVIDER NB: 809 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x373 Result: 0x763E70ED25521F5892DEADDA978CEC 
[i] 8 TRUE DIVIDER NB: 834 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x1 Result: 0x197D95F81F7BA421E829611A8F8BB1204 
[i] NB: 1000 DIVKey: DE Inverse DivideKey: B9A85C40939A85C40939A85C40939A84D81BA4D0CFD743C5DAAE799D7904C09F     
[i] 9 TRUE DIVIDER NB: 1062 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x15B Result: 0x12CE43D9BA45157E164076DAC9CF14C 
[i] 10 TRUE DIVIDER NB: 1072 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x2 Result: 0xCBECAFC0FBDD210F414B08D47C5D8902 
[i] 11 TRUE DIVIDER NB: 1127 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x15B Result: 0x12CE43D9BA45157E164076DAC9CF14C 
[i] 12 TRUE DIVIDER NB: 1169 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x2 Result: 0xCBECAFC0FBDD210F414B08D47C5D8902 
[i] NB: 1200 DIVKey: 14C Inverse DivideKey: 80C565C87B5F9D4D1BC2503159721ED743AFDC9C2231A3E05E2CE713F071A6FE     
[i] 13 TRUE DIVIDER NB: 1337 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x1C Result: 0xE90E7FB7FB45DCA3B855C0F2D746537 
[i] NB: 1400 DIVKey: 2C0 Inverse DivideKey: A28BA2E8BA2E8BA2E8BA2E8BA2E8BA2DBD141E710462D73192E306F16890FE86     
[i] 14 TRUE DIVIDER NB: 1477 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x2 Result: 0xCBECAFC0FBDD210F414B08D47C5D8902 
[i] 15 TRUE DIVIDER NB: 1542 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x4 Result: 0x65F657E07DEE9087A0A5846A3E2EC481 
[i] 16 TRUE DIVIDER NB: 1578 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x373 Result: 0x763E70ED25521F5892DEADDA978CEC 
[i] NB: 1600 DIVKey: 1EE Inverse DivideKey: 79C8084A9F9C8084A9F9C8084A9F9C7FE9E86E4447FBAEAF98EB545CE5A3A7DA     
[i] 17 TRUE DIVIDER NB: 1619 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x2B6 Result: 0x96721ECDD228ABF0B203B6D64E78A6 
[i] NB: 1800 DIVKey: 346 Inverse DivideKey: 50F46433527B6AEBD67415FEC72DD2C938973869F12AD2BF30BEDBE9EEBFE597     
[i] 18 TRUE DIVIDER NB: 1880 TestKey: 0x197D95F81F7BA421E829611A8F8BB1204 Divider: 0x1C Result: 0xE90E7FB7FB45DCA3B855C0F2D746537 
[i] NB: 2000 DIVKey: 4A Inverse DivideKey: 2CF914C1BACF914C1BACF914C1BACF9112F534A510F48ADA1066AFBECAA1BF5B     
[i] Data Saved in file DivideKeys.txt 

It is impossible to find the correct divisor for a public key; you need a private key.

everything is based on exploring with maths

Code:

x=2000000000000000
t=1185429467683753

A0=x-t
>>814570532316247

A1=t/5
>>237085893536750.6
A2=A0/5
>>162914106463249.4

A3=t-A1
>>948343574147002.4
A4= A0-A2
>>651656425852997.6


A5=A4-A1
>>785429467683753

A6=A3-A2
>>414570532316247

Even from divisions with results with fractions (floats), you can obtain integers with certainty.
If you use mathematics correctly.

[alek76]

Even from divisions with results with fractions (floats), you can obtain integers with certainty.
If you use mathematics correctly.

The comma can be moved in any direction, that’s not the issue. You need to work with integers. Can you do the same with the public key? Even if you can, it doesn't give you the range of the private key.

[digaran]

Everything is in division, forget about finding the exact divisor to just divide and land on a known key, you need to work with scalar and points side by side, meaning that you have to run 2 scripts (since I'm not a coder I do that), and then do the dividing PLUS, this is important, plus having a third operation which is subtraction, from there you can learn many things. As I have. Good luck guys, I have already found my tree in the middle of the ocean.😉

[lostrelic]

As I have. Good luck guys, I have already found my tree in the middle of the ocean.😉

Please enlighten us with your tree finding method

[digaran]

As I have. Good luck guys, I have already found my tree in the middle of the ocean.😉

Please enlighten us with your tree finding method

First you need to have several bully sharks attack you, then work hard to achieve something nobody expected from you, which is inventing a tree where there is none. (At least the world thinks there is no tree or even if there is, it'd take years of swimming to reach one.)

I'm telling a rhetoric story here, not everyone will understand it.
As for enlightening you, I already have, you just need to find the right key to do your EC operations with. The scripts which I gathered with the help of a few, can get you to your tree.

[mcdouglasx]

The comma can be moved in any direction

It's not just moving the comma, it's reducing the target.
from
1185429467683753
to
785429467683753

Can you do the same with the public key?

yes.

Even if you can, it doesn't give you the range of the private key.
 

If you perfect your division technique
and you manage to reduce enough, you could for example.

1185429467683753

If you manage to reduce to

1439467683753

1185429467683753-1439467683753
1183990000000000

obtaining the first 3 digits of your goal..Discarding the 3 digits that follow, which would be the error range.

Basically this technique is based on reducing pubs without losing the last digits of the pk so that when you subtract you identify the first digits.
Then, once you have the first digits, you have the basis to continue.

[alek76]

Everything is in division, forget about finding the exact divisor to just divide and land on a known key, you need to work with scalar and points side by side, meaning that you have to run 2 scripts (since I'm not a coder I do that), and then do the dividing PLUS, this is important, plus having a third operation which is subtraction, from there you can learn many things. As I have. Good luck guys, I have already found my tree in the middle of the ocean.😉

Absolutely right! But some “mathematicians” are trying to teach something new. The result of the division may be near the target key. And there are much fewer exact divisors, but they exist!
Your tree works, I know it. The result using the 64-bit example is:
BIT 64 key = (0x171cec757dceb3 * 0xAB0) - 0x63C
These calculations are made from a 64-bit public key. I do it a little differently, just two programs. You just need to change the algorithm, 3 is a lot of scripts. One program for calculations and one program for solving the results - probably two at most. Although it can be different.

[digaran]

The comma can be moved in any direction

It's not just moving the comma, it's reducing the target.
from
1185429467683753
to
785429467683753

Can you do the same with the public key?

yes.

Even if you can, it doesn't give you the range of the private key.
 

If you perfect your division technique
and you manage to reduce enough, you could for example.

1185429467683753

If you manage to reduce to

1439467683753

1185429467683753-1439467683753
1183990000000000

obtaining the first 3 digits of your goal..Discarding the 3 digits that follow, which would be the error range.

Basically this technique is based on reducing pubs without losing the last digits of the pk so that when you subtract you identify the first digits.
Then, once you have the first digits, you have the basis to continue.

Main question is, how can we guess the first few digits? If even if we guess the 4 first digits correctly, the fifth digit would cause a problem if we make a mistake.

Something to demonstrate, for example if we guess the last 2 hex chars of the target, we can divide by a 3 digit number, but if we do that, we'd need to generate 256 keys and can only divide up to 1024, so we'll have 256 keys divided by 1024, then we will have to generate 256 keys as a guess for each one of those first 256 keys, well  just now writing this I realize we can indeed guess the last 2 chars and divide by 1024 and continue until we reach a very small range easily brute force able. Or do we need to guess more than 2 ending characters to divide by 1024?
Disclaimer, I take no responsibility for any damages caused by my published studies, I am an independent researcher and publish my findings on public domain.  For transparency.

[citb0in]

Disclaimer, I take no responsibility for any damages caused by my published studies, I am an independent researcher and publish my findings on public domain.  For transparency.

Can you point us to your published studies? I'm really curious and looking forward reading them.

[nomachine]

Disclaimer, I take no responsibility for any damages caused by my published studies, I am an independent researcher and publish my findings on public domain.  For transparency.

Can you point us to your published studies? I'm really curious and looking forward reading them.

It's a waste of reading until he shows us the solved WIF. 

[btc11235]

Hi -- Is anyone here familiar with NBitcoin for .NET? I basically only know C# so I'm hoping someone can help me with this one step I'm stuck on...

I'm testing with puzzle #12 just to see if I can generate the right address from the now-known private key... Private key and funded address are listed as:

Code:

0000000000000000000000000000000000000000000000000000000000000a7b
1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot

However, the following code keeps giving me a different address:

Code:

var hex = "0000000000000000000000000000000000000000000000000000000000000a7b";
var privateKey = new ExtKey(hex);

// these all give me: "1JThwYZMjCqbpi3QPNAToGdbSLWoUdhdJi"

privateKey.GetPublicKey()
          .GetAddress(ScriptPubKeyType.Legacy, Network.Main)
          .ToString();

privateKey.PrivateKey
          .GetAddress(ScriptPubKeyType.Legacy, Network.Main)
          .ToString();

privateKey.PrivateKey
          .PubKey
          .GetAddress(ScriptPubKeyType.Legacy, Network.Main)
          .ToString();

privateKey.PrivateKey
          .GetScriptPubKey(ScriptPubKeyType.Legacy)
          .GetDestinationAddress(Network.Main)
          .ToString();

privateKey.PrivateKey
          .GetWif(Network.Main)
          .GetAddress(ScriptPubKeyType.Legacy)
          .ToString();

Thanks in advance... I was making really solid progress all morning, then hit this inability to generate an address I can reliably use to match against the known-funded addresses of the remaining puzzles, and without that I'm basically dead in the water... I can guess all the private key hashes I want, within the range I want (for puzzle #66 currently), but who cares if I can't verify whether I hit the right one?!

[btc11235]

Hi Legends_Never_Die -- Thx for the reply!

You are trying to generate a master private key > ExtKey.

Ah, I see. I'm afraid I've never heard of a "master private key" before...

Do you know how would I generate a... well, now I don't know what to call it... but a "regular" private key from a hex? I just need to give NBitcoin that hex and then get the expected address from it, and I was using this StackOverflow as an example, which is using `ExtPubKey` to generate a public key from some kind of hash, so I "extrapolated" (aka assumed) that `ExtKey` would be the private key version of that... But I guess that was wrong Although one of the overrides for `new ExtKey()` does take a `hex` param, so I really thought I was on the right track...

And I checked out that link to csharp.hotexamples.com you posted (thank you for that) but I can't seem to navigate that site very well to get to any other pages that might be helpful (I tried the search, but almost everything I tried gave me a 404)...

I do see this on that page:

Code:

var walletKey = new NBitcoin.Key();

...and I'm guessing that could be mean I just need to use a `Key()` instead of a `ExtKey()`...? but `Key()` doesn't seem to take a hex value at all... and `Key.Parse()` takes a WIF, but I'm not sure how to generate a WIF from a private key hex either, so, yeah, I'm still stumped...

why are you trying to build from scratch when there are ready to use open source tools, with great performance?

If you mean use an existing puzzle solver, well A) to learn all this stuff, but also B) I really don't know where to find existing ones...? And the code I've seen posted here all looks like C or C++ that I'm not very familiar with, so I wouldn't know how to modify any of it to do what I want...

Thanks again for the response, and let me know if you can help me get from a private key (in either decimal or hexadecimal form) to the funded address using C# ... doesn't even have to be with NBitcoin, that just seems to be the most popular Bitcoin lib for .NET


Did it! Thanks to this SO post I finally found:

https://stackoverflow.com/questions/74753526/get-private-key-from-a-biginteger-in-nbitcoin

So I can use the decimal version of that hex, 2683, and do this:

Code:

var bytes = new BigInteger(2683).ToByteArray();
Array.Resize<byte>(ref bytes, 32);
Array.Reverse(bytes);

new Key(bytes)
    .GetAddress(ScriptPubKeyType.Legacy, Network.Main)
    .ToString();

...which returns the expected (previously funded) address of "1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot", and the added bonus is that I don't have to convert the BigInteger numbers I already had into HEX strings after all 

[moderator's note: consecutive posts merged]

[digaran]

Here visit this other puzzle thread, there are all the intel you need about cracking tools, but may I interest you about a sets of earth shattering ultimate hack tools developed by myself by skiing on people's script and claiming them as mine? It's free to use you only have to cover my back, like when whiners start their routine whining, you just come here taking my side, Ok? I feel like cornered.😂
I'm currently working on a new thing, I'm trying to find ending characters or at least 2 last chars of a private key, it's really difficult but God willing if I manage to figure that out, I will do absolutely nothing with it just like I haven't followed up on changing a key in a way to make a composite number divisible by up to 2^240, though I know how to do it, but it only works for keys with at least first 28-32 characters being 0xf.

As I said before, if you try to divide 2 keys and subtract/add the results, you would either get their sum, which is sometimes less than 34-38 in hex, or you would actually get their subtracted value. Something interesting is the fact about dividing a key, has anyone managed to divide 1 through 15 by different divisor to see the left most characters of resulting scalar?  Yeah do that and you will realize the starting hex chars of your result depends on the ending chars of your target.

[nomachine]

I'm currently working on a new thing, I'm trying to find ending characters or at least 2 last chars of a private key, it's really difficult but God willing if I manage to figure that out......

Only 2 ?  

Code:

import sys
import os
import time
import secrets
import random
import binascii
import base58
import hashlib
import ecdsa
import multiprocessing
from multiprocessing import cpu_count

def generate_private_key_WIF(start, miss):
    return start + "".join(
        secrets.choice(
            "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
        ) 
        for _ in range(miss)
    ) 

def check_private_key(start, miss, target_binary): 
    while not STOP_EVENT.is_set():  
        private_key_WIF_str = generate_private_key_WIF(start, miss)
        if start[0] == '5':
            private_key_WIF = private_key_WIF_str
            first_encode = base58.b58decode(private_key_WIF)
            private_key_full = binascii.hexlify(first_encode)
            private_key = private_key_full[2:-8]
        if start[0] in ['L', 'K']:
            private_key_WIF = private_key_WIF_str
            first_encode = base58.b58decode(private_key_WIF)
            private_key_full = binascii.hexlify(first_encode)
            private_key = private_key_full[2:-10]
        private_key_hex = private_key.decode("utf-8")
        dec = int(private_key_hex[0:64], 16)
        dec_bytes = dec.to_bytes((dec.bit_length() + 7) // 8, 'big')
        private_key_bytes = b'\x00' * 32
        private_key_bytes = private_key_bytes[:-len(dec_bytes)] + dec_bytes
        signing_key = ecdsa.SigningKey.from_string(private_key_bytes, curve=ecdsa.SECP256k1)
        compressed_public_key = signing_key.get_verifying_key().to_string("compressed")
        sha256_hash = hashlib.sha256(compressed_public_key).digest()
        ripemd160_hash = hashlib.new('ripemd160', sha256_hash).digest()
        extended_private_key = b'\x80' + private_key_bytes + b'\x01'
        checksum = hashlib.sha256(hashlib.sha256(extended_private_key).digest()).digest()[:4]
        private_key_with_checksum = extended_private_key + checksum
        wif_compressed = base58.b58encode(private_key_with_checksum).decode()
        message = "\r[+] {} ".format(private_key_WIF_str) 
        messages = []
        messages.append(message)
        output = "\033[01;33m" + ''.join(messages) + "\r"
        sys.stdout.write(output)
        sys.stdout.flush()
        if ripemd160_hash == target_binary:
            t = time.ctime()
            sys.stdout.write(f"\n\033[01;33m[+] BINGO!!! {t}\n")   
            with open('winner.txt', 'a') as file:
                t = time.ctime()
                file.write('\n\nMatch Found: ' + t)
                file.write('\nPrivatekey (dec): ' + str(dec))
                file.write('\nPrivatekey (hex): ' + hex(dec)[2:])
                file.write('\nPrivatekey (wif): ' + wif_compressed)
                
            STOP_EVENT.set()  
            return  

if __name__ == '__main__':
    start = "KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZM21gaY8W"
    miss = 52 - (len(start)) 
    # Define the target as bytes
    target_hex = "52e763a7ddc1aa4fa811578c491c1bc7fd570137"
    target_binary = bytes.fromhex(target_hex)
    os.system("clear")
    t = time.ctime()
    sys.stdout.write(f"\033[01;33m[+] {t}\n")
    sys.stdout.write(f"\033[01;33m[+] Ending characters missing: {miss}\n")
    sys.stdout.write(f"\033[01;33m[+] Public Key Hash (Hash 160): {target_hex}\n")
    sys.stdout.flush()

    # Create a global STOP_EVENT
    STOP_EVENT = multiprocessing.Event()

    # Create a pool of worker processes
    num_processes = multiprocessing.cpu_count()
    pool = multiprocessing.Pool(processes=num_processes)

    # Start the worker processes with different starting points
    for i in range(num_processes):
        pool.apply_async(check_private_key, args=(start, miss, target_binary))

    # Close the pool and wait for all processes to complete
    pool.close()
    pool.join()

• Mon Oct 23 00:26:17 2023
• Ending characters missing: 10
• Public Key Hash (Hash 160): 52e763a7ddc1aa4fa811578c491c1bc7fd570137
• KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZM21gaY8WN2CdwnTG57
• BINGO!!! Mon Oct 23 00:26:20 2023

[digaran]

BINGO

Why are you brute forcing WIF? Don't you know going beyond public key generation is wasting time if you don't have enough hardware? It would be nice if you could write a script which could with 100% validity tell you the last 2 characters of a private key by operating with points.

I can find them when I know both keys, or when I only know the distance between 2 points, it also doesn't matter what the distance is, that's why working with all hexadecimal values is important to find out and study the behaviour of each character. After preliminary test, God willing I will post my method if I think it doesn't break the EC.  But funny thing is most of the things I post (ECC math related) I truly believe they "have" the potential but I just post them to see maybe an expert can get an idea out of it. Apparently I'm delusional until I'm not. By then it'd be too late to pay attention.

[nomachine]

BINGO

Why are you brute forcing WIF?

To demonstrate to you that even 10 is not a problem.
The problem is that we are not dealing here with 2, 6, 8 or 10 missing characters...
But with 18 specifically for Puzzle 66.....
It is useless, whatever method you use.

[citb0in]

Disclaimer, I take no responsibility for any damages caused by my published studies, I am an independent researcher and publish my findings on public domain.  For transparency.

Can you point us to your published studies? I'm really curious and looking forward reading them.

@digaran: the question unfortunately is still unanswered. Can you point us to your studies, please?

[vhh]

Something interesting is the fact about dividing a key, has anyone managed to divide 1 through 15 by different divisor to see the left most characters of resulting scalar?  Yeah do that and you will realize the starting hex chars of your result depends on the ending chars of your target.

These are natural behaviors when you're working on a curve over a finite field. You need to study them more (properties of curves over prime fields, pairings, embedding degree, etc) in order to avoid attributing a magical aura to every result that pops out.

[digaran]

BINGO

Why are you brute forcing WIF?

To demonstrate to you that even 10 is not a problem.
The problem is that we are not dealing here with 2, 6, 8 or 10 missing characters...
But with 18 specifically for Puzzle 66.....
It is useless, whatever method you use.

I'm not talking about missing characters or puzzle 66, I'm talking about a way to determine last characters of a private key by working with points.

These are natural behaviors when you're working on a curve over a finite field. You need to study them more (properties of curves over prime fields, pairings, embedding degree, etc) in order to avoid attributing a magical aura to every result that pops out.

There is no magical aura, and there is no natural behaviour, everything depends on group order, working with points without working on scalar is pointless, in reality we don't need to work with points alone, but since we don't know the private key we work with points.

E.g, if you divide 16577/7 = 2368.142857, divide 16477/7 =
2353.857143, now dividing 16576/7 = 2368, now all we need to do is finding what key results in 0.142857 and 0.85143 when divided, and by what number. After that having all keys between 2353 and 2368 saved for comparing is easy.  This is just an example.