Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 186.

delta[trix]

newbie

Activity: 4

Merit: 0

Quote from: citb0in on August 10, 2023, 11:26:09 AM

Quote from: delta[trix] on August 10, 2023, 11:07:11 AM

But it seems to be something automated by the puzzle's creator itself, I looked at some transactions.

Be more specific, please

If you look at the transactions in wallet 66, and a few others, you will see that it appears to be something automated, sending small transactions with numbers that I believe might provide some clues in decimal/hexadecimal or binary code as to where the private key could be located. However, this is just an assumption.

james5000

jr. member

Activity: 69

Merit: 2

To mathematicians, there is a way to divide one point by another point on the elliptic curve.

citb0in

hero member

Activity: 630

Merit: 731

Bitcoin g33k

Quote from: delta[trix] on August 10, 2023, 11:07:11 AM

But it seems to be something automated by the puzzle's creator itself, I looked at some transactions.

Be more specific, please

delta[trix]

newbie

Activity: 4

Merit: 0

Quote from: Minase on August 10, 2023, 10:58:17 AM

Not at all, just dust or some people sending small amounts.
Have looked at the past addresses and no such hint was given

But it seems to be something automated by the puzzle's creator itself, I looked at some transactions.

Minase

member

Activity: 72

Merit: 43

Not at all, just dust or some people sending small amounts.
Have looked at the past addresses and no such hint was given

delta[trix]

newbie

Activity: 4

Merit: 0

I have a small curiosity about these occasional small incoming transactions in wallet 66. Could they be some clue about the key's location, or is it just something random?

elvis13

newbie

Activity: 26

Merit: 2

james5000
How to run it in Ubuntu?
Write a command.

james5000

jr. member

Activity: 69

Merit: 2

muticore mode added to python code

https://github.com/Jamerson1000/million-python

citb0in

hero member

Activity: 630

Merit: 731

Bitcoin g33k

Quote from: james5000 on August 08, 2023, 03:39:24 PM

Quote from: citb0in on August 08, 2023, 03:35:20 PM

you should get rid of the bad idea that a ratio of 40/60 or vice-versa of zeros and ones exists. That is simply absurd. Pure waste of time. With the method mentioned here you would never have discovered the puzzles 11,12,13,14,17,18,19,24,25,31,48,49,51,56,57.

please what method do you suggest then? I observed many calculating, looking for errors etc... one or two try to improve, after all I'm not quite right, but it is something new and clearly an advantage in the search.

this method is just as useless as the previous proposed ones. It's all right for ideas to come in, but you should get caught up in it and chase after something that makes no sense in this context. It is exactly the same as the clumsy attempt to guess the position of the searched key within the searched bit range. It is simply impossible, because there are always outliers (as the past and thus our existing knowledge proves). People try to create a pattern, in the process they get lost in the chaos Wink

james5000

jr. member

Activity: 69

Merit: 2

Quote from: citb0in on August 08, 2023, 03:35:20 PM

you should get rid of the bad idea that a ratio of 40/60 or vice-versa of zeros and ones exists. That is simply absurd. Pure waste of time. With the method mentioned here you would never have discovered the puzzles 11,12,13,14,17,18,19,24,25,31,48,49,51,56,57.

please what method do you suggest then? I observed many calculating, looking for errors etc... one or two try to improve, after all I'm not quite right, but it is something new and clearly an advantage in the search.

citb0in

hero member

Activity: 630

Merit: 731

Bitcoin g33k

you should get rid of the bad idea that a ratio of 40/60 or vice-versa of zeros and ones exists. That is simply absurd. Pure waste of time. With the method mentioned here you would never have discovered the puzzles 11,12,13,14,17,18,19,24,25,31,48,49,51,56,57.

james5000

jr. member

Activity: 69

Merit: 2

Quote from: vneos on August 08, 2023, 04:16:07 AM

I wrote a simple script for solving puzzle 66: https://github.com/allinbit/btc_puzzle

If it could be ported to gpu then it would be faster but I don't know anything about it.

one more problem in this method is the keys repeat Embarrassed

albert0bsd

hero member

Activity: 862

Merit: 662

Quote from: al3xcjc on August 08, 2023, 02:31:28 PM

The generated private key is then used to create a public key and subsequently generate a Bitcoin address.

That is exactly what scalar multiplication means...

albert0bsd

hero member

Activity: 862

Merit: 662

My only sugestion for you get more speed is to work with some precalculated table of publickeys for some specific number of bits...

Lets to said that we want to process subranges of of 3 o 4 bytes [24 or 32 bits] (Less significative bits)
if the target puzzle is 66 bits you will have some main range of [42 or 34 bits] (Most significative bits)

Code:

[Main range 42 or 34 bits][Subrange 24 or 32 bits]

if you want to have Ratio from 40% to 60% that means you only need 33 +/6 bits in "1"

So that +/- 6 variations of bits maybe only need to checked in each subrange... or only +/- 4 bits in the subrange and +/- 2 bits in the main rarange

Example for a Subrange of 3 Bytes [24 bits], half is 12 bits +/- 4 will be checked all those with from 8 bits to 16 bits in "1"

For this example we need to calcualte all the publickeys under 24 bits that its privatekeys have only bewteen 8 to 16 bits in "1",
2^24 are 16777216 keys, you will only need to stetore (Surprise) 94 % of them in memory

Once that you already have that table in memory you only need is to Select a KEY from the Main range and performe a Point Addition againts all the previous table

That should gain some speed...

al3xcjc

newbie

Activity: 1

Merit: 0

Quote from: james5000 on August 08, 2023, 09:08:02 AM

Quote from: vneos on August 08, 2023, 04:16:07 AM

I wrote a simple script for solving puzzle 66: https://github.com/allinbit/btc_puzzle

If it could be ported to gpu then it would be faster but I don't know anything about it.

Your code uses scalar multiplication for all the keys, making it even slower.
The code is interesting, although for the processor it can take a long time, it needs to be on the video card itself.

No, the code doesn't directly involve scalar multiplication for generating private keys. Instead, it generates private keys by randomly shuffling bits to create a binary string, which is then converted to a hexadecimal representation. The generated private key is then used to create a public key and subsequently generate a Bitcoin address.

In the context of Bitcoin, scalar multiplication is a fundamental operation used in elliptic curve cryptography (ECC). Scalar multiplication is used to derive a public key from a private key, and it's a core operation in generating Bitcoin addresses. However, the code doesn't explicitly perform scalar multiplication. It generates private keys in a way that doesn't directly reflect the typical method used in Bitcoin.

Here's how scalar multiplication is generally used in Bitcoin address generation:

A private key is randomly generated using a secure random number generator.
Scalar multiplication is performed on the elliptic curve with the private key and a predefined generator point to compute the corresponding public key point.
The x-coordinate of the resulting public key point is used to create a Bitcoin address.
In the code, the process of generating private keys is unrelated to scalar multiplication. Instead, it generates private keys through a random bit shuffling approach, converts them to hexadecimal format, and then processes them to create public keys and Bitcoin addresses.

james5000

jr. member

Activity: 69

Merit: 2

Using my method with multiprocessing, I reach #30 in that time.

Code:

Found!
030d282cf2ff536d2c42f105d0b8588821a915dc3f9a05bd98bb23af67a2e92a5b
Time: 0 h, 14 m, 37 s

Using the VNEOS software, I obtained the time and it also provides us with the private key.

Code:

000000000000000000000000000000000000000000000000000000003d94cd64
hash160: d39c4704664e1deb76c9331e637564c257d68a08
Target hash found!
Time: 0 h, 5 m, 0 s

this is very very good, congratulations, buddy!!!! Grin

however, I got lucky; I ran it again with the same parameters, and the time was...

Code:

000000000000000000000000000000000000000000000000000000003d94cd64
hash160: d39c4704664e1deb76c9331e637564c257d68a08
Target hash found!
Time: 0 h, 10 m, 8 s

even though it's faster, the time varies a lot. Scalar multiplication isn't very slow, but as you mentioned, it's a lottery. Someone might get lucky on #66. Cheesy

just a suggestion to make parameter swapping easier.

Code:

import hashlib
import ecdsa
import random
from multiprocessing import Process, Event

def binary_to_hex(bin_string):
    return hex(int(bin_string, 2))[2:].zfill(len(bin_string) // 4)

def worker(key_size, num_ones, stop_event):

    target_hash = "20d45a6a762535700ce9e0b216e31994335db8a5"

    while True:
        if stop_event.is_set():
            break

        bits = ['0'] * (key_size - num_ones) + ['1'] * (num_ones - 1)
        random.shuffle(bits)

        bits.insert(0, '1')
        private_key_bin = ''.join(bits)

        private_key_bin = '0' * (256 - key_size) + private_key_bin
        private_key_hex = binary_to_hex(private_key_bin)

        sk = ecdsa.SigningKey.from_string(bytes.fromhex(private_key_hex), curve=ecdsa.SECP256k1)
        public_key = sk.get_verifying_key().to_string().hex()

        compressed_public_key = '02' + public_key[0:64] if int(public_key[-2:], 16) % 2 == 0 else '03' + public_key[0:64]
        compressed_public_key_bytes = bytes.fromhex(compressed_public_key)

        ripemd160_hash = hashlib.new('ripemd160')
        ripemd160_hash.update(hashlib.sha256(compressed_public_key_bytes).digest())
        hashed_compressed_public_key = ripemd160_hash.digest().hex()

        if hashed_compressed_public_key == target_hash:
            print(private_key_hex)
            print("hash160:", hashed_compressed_public_key)
            print("Target hash found!")

            stop_event.set()
            break

def main():
    num_processes = 4
    processes = []
    stop_event = Event()

    for _ in range(num_processes):
        process = Process(target=worker, args=(66, 35, stop_event))
        processes.append(process)

    for process in processes:
        process.start()

    for process in processes:
        process.join()

    if stop_event.is_set():
        for process in processes:
            process.terminate()

if __name__ == '__main__':
    main()

james5000

jr. member

Activity: 69

Merit: 2

Quote from: vneos on August 08, 2023, 04:16:07 AM

I wrote a simple script for solving puzzle 66: https://github.com/allinbit/btc_puzzle

If it could be ported to gpu then it would be faster but I don't know anything about it.

Your code uses scalar multiplication for all the keys, making it even slower.
The code is interesting, although for the processor it can take a long time, it needs to be on the video card itself.

james5000

jr. member

Activity: 69

Merit: 2

Quote from: vneos on August 08, 2023, 12:49:41 AM

Let's outline what james5000 does from a mathematical point of view:

For puzzle 66, we have 66 binary digits, and following james5000's idea, we can set the number of digits of 0s and 1s within a specific range(the digits of 0 and 1 shall not exceed 41% of the 66 digits):

Code:

Number of 0    Number of 1
      27                  39
      28                  38
      29                  37
      30                  36
      31                  35
      32                  34
      33                  33
      34                  32
      35                  31
      36                  30
      37                  29
      38                  28
      39                  27

Now let's calculate the key space possibilities:

For a 66-bit binary number, where 0 has 27 bits and 1 has 39 bits, since the leftmost bit is fixed to be 1, we have 65 bits left to fill with 38 ones (since one 1 is already used for the leftmost bit) and 27 zeros.

Now, think of this as trying to choose locations for the 38 ones out of the remaining 65 bits. Once the positions for the ones are determined, the positions for the zeros are also fixed.

The number of ways to choose 38 locations out of 65 is given by the combination formula or "n choose k", represented as n!/(k!(n-k)!)

In this case, n = 65 and k = 38, so we got 65!/(38!x27!)

This formula calculates the number of ways to arrange 38 ones in a 65-bit string.

We then apply the formula to the remaining combinations, the probability of all keys is::

Code:

65!/(38!x27!) + 65!/(37!x28!) + 65!/(36!x29!) + 65!/(35!x30!) + 65!/(34!x31!) + 65!/(33!x32!) + 65!/(32!x33!) + 65!/(31!x34!) + 65!/(30!x35!) + 65!/(29!x36!) + 65!/(28!x37!) + 65!/(27!x38!) + 65!/(26!x39!)

Which equal to 3.287737502x10^19, is smaller than 2^65 and about 44.56% of 2^66. That means we only need to search 44.56% of the original key space to potentially find the private key for puzzle 66!

I don't know if my calculation process is correct. If there are any errors, please point them out. Thank you.

exactly that, there is no way to be greater than 2^65 as the friend said yesterday

vsv68

newbie

Activity: 8

Merit: 0

vneos
frozenen
zahid888
lordfrs
citb0in

Guys, tell me, can you read? I already provided you a free python script that will show the exact number of combinations to iterate over, given a specific number of ones in the key:

https://bitcointalksearch.org/topic/m.62662714

I even gave a specific example where the discussed method works worse than a simple sequential enumeration!

but you stubbornly continue to write all sorts of garbage...

If you are too lazy to run the script, here are some results:

Code:

KEY_SIZE = 30
ONES = 14
Combinations: 67863915

KEY_SIZE = 30
ONES = 16
Combinations: 77558760


KEY_SIZE = 66
ONES = 30
Combinations: 2507588587725537680

KEY_SIZE = 66
ONES = 31
Combinations: 3009106305270645216

KEY_SIZE = 66
ONES = 32
Combinations: 3397378086595889760

KEY_SIZE = 66
ONES = 33
Combinations: 3609714217008132870

you will need to try a huge number of incorrect combinations before you find the right key.

citb0in

hero member

Activity: 630

Merit: 731

Bitcoin g33k

Quote from: lordfrs

Therefore, when there are 14 bits being 0 and 16 bits being 1 in a 30-bit number, there are a total of 1,073,741,824 different combinations.

2^14*2^16 = 1,073,741,824 2^15*2^15 = 1,073,741,824 2^a*2^b = 1,073,741,824 (where a+b=30) 2^30 = 1,073,741,824

no matter of ones and zeros

Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 186. (Read 229859 times)