Bitcoin puzzle transaction ~32 BTC prize to who solves it

[protest010]

Thanks for all your replies, i appreciate for it.

I still just wondering how many keys i can crack per second with Rtx4090?

There is a program which i tried before it's modified version of bitcrack which is synchronized with vanitygen which is working much faster than original bitcrack.

Did anyone tried it with Rtx4090?

[1715323247]

1715323247

[WanderingPhilospher]

Hello everyone.

I need a Python script that would check two text files, and if the text in the lines matches, then the script would write “Match found” and write the matching text to a new file. If there is no match, then it would write “No matches found.”

Can anyone help?

Something like this:

Code:

def check_files(file1, file2, output_file):
    with open(file1, 'r') as f1, open(file2, 'r') as f2:
        lines1 = f1.readlines()
        lines2 = f2.readlines()

    matches = [line for line in lines1 if line in lines2]

    with open(output_file, 'w') as out:
        if matches:
            print("Match found")
            for match in matches:
                out.write(match)
        else:
            print("No matches found")



check_files('file1.txt', 'file2.txt', 'matches.txt')

[curiousNoone]

Maybe disabling RBF would be a start, and using a high fee.

Yep, that's the solution. It is one-time try only.

This has been bugging me and put me off from searching 66.
Ok so say i found it can i make the fee high enough like in electrum and broadcast it a few minutes before the next block ?
This way i have a few mins to get in next block before the pub key is cracked. Is this possible.?
Otherwise what is the point ?

[WanderingPhilospher]

Maybe disabling RBF would be a start, and using a high fee.

Yep, that's the solution. It is one-time try only.

This has been bugging me and put me off from searching 66.
Ok so say i found it can i make the fee high enough like in electrum and broadcast it a few minutes before the next block ?
This way i have a few mins to get in next block before the pub key is cracked. Is this possible.?
Otherwise what is the point ?

Your tactic could work, but there is no way to know when the next block happens, it could be 2 minutes, it could be hours. You can play the average block time for sure, but even that is not 100%.

Some claim there is a way around it all, but I'm not sure how.

[ccinet]

I still don't understand, by whom it will be broken, I also wrote software and I am searching randomly.



What should we do to transfer, add the private key in online wallets and go to the transfer form, use phone apps, which wallet software should we use to withdraw the balance, or write a program for the Bitcoin transfer form or  Should we add its in Bitcoin core???

If you initiate a transaction you will reveal the public key. Since it belongs to a 66-bit public key, you can quickly find the private address with kangaroo or bsgs because you know the range and it is "narrow". Then you will start your transaction and generate a double expense. To win you will "bid" a higher transaction fee to get more confirmations faster.
If there is any mistake in this, someone correct me.

[aminsolhi]

I still don't understand, by whom it will be broken, I also wrote software and I am searching randomly.



What should we do to transfer, add the private key in online wallets and go to the transfer form, use phone apps, which wallet software should we use to withdraw the balance, or write a program for the Bitcoin transfer form or  Should we add its in Bitcoin core???

If you initiate a transaction you will reveal the public key. Since it belongs to a 66-bit public key, you can quickly find the private address with kangaroo or bsgs because you know the range and it is "narrow". Then you will start your transaction and generate a double expense. To win you will "bid" a higher transaction fee to get more confirmations faster.
If there is any mistake in this, someone correct me.

I am grateful to the members of this group and I thank them very much for providing good information and guidance. I ask many questions more for a deep understanding of the issue rather than seeking a solution myself; of course, my intention is not self-praise, I just can't be a bystander to the problems.

As far as I understand, you mean that powerful individuals and teams like mining pools or similar ones have very high processing power and can accomplish our efforts to search for block 66, which may take several years, in less than a day? And while we have requested the transfer of Bitcoin, they may also register it with a higher fee, and more people repeat this process, creating something like an auction?

Are they still unaware of the existence of the Bitcoin puzzle so they can think about it sooner?

[nomachine]

Maybe disabling RBF would be a start, and using a high fee.

Yep, that's the solution. It is one-time try only.

This has been bugging me and put me off from searching 66.
Ok so say i found it can i make the fee high enough like in electrum and broadcast it a few minutes before the next block ?
This way i have a few mins to get in next block before the pub key is cracked. Is this possible.?
Otherwise what is the point ?

That is the enigma. Maybe 66 is already hacked, but no one will make transaction first.

130 is safe

[Lugh1Man]

Hi All,

I've been reading this and other related topics for a few weeks and I'm trying to understand the complexity of the different algorithms and approaches.

For Pollard's Kangaroo algorithm, someone gave an estimate of 2^66.05 operations needed for solving #130 ( https://bitcointalk.org/index.php?topic=5244940.2740 not sure how they reached this conclusion, but from reading about the algorithm it has a similar complexity to BSGS). This equals ~7.6x10¹⁹ operations needed.
For BSGS, from reading about it, is has a complexity of O(n^1/2). Taking the square root of the range (2¹³⁰ - 2¹²⁹ - 1) equals ~2.6x10¹⁹ operations needed.

Is this correct? Is BSGS more efficient, or is it just a wrong way of calculating the efficiency?
I think I'm missing something in estimating the total "operations needed" for these algorithms. Is there a better/correct way of doing this?
Edit: -> Reading keyhunt's documentation, it says it can easily reach the speed of several peta-keys per second (10¹⁸), so I'm definitely missing something...


Considering HW limitations, I am still not familiar with how different Kangaroo implementations work, I see that the JeanLucPons' based on VanitySearch requires GPU power (I assume more cores means better, but not sure what is the requirement for VRAM, CPU, RAM).
For BSGS, seems like keyhunt is the best, and works better with more RAM and more CPU cores.
Am I missing anything? Are there any other/better tools available for searching the ranges with known public keys?

[aminsolhi]

Hi All,

I've been reading this and other related topics for a few weeks and I'm trying to understand the complexity of the different algorithms and approaches.

For Pollard's Kangaroo algorithm, someone gave an estimate of 2^66.05 operations needed for solving #130 ( https://bitcointalk.org/index.php?topic=5244940.2740 not sure how they reached this conclusion, but from reading about the algorithm it has a similar complexity to BSGS). This equals ~7.6x10¹⁹ operations needed.
For BSGS, from reading about it, is has a complexity of O(n^1/2). Taking the square root of the range (2¹³⁰ - 2¹²⁹ - 1) equals ~2.6x10¹⁹ operations needed.

Is this correct? Is BSGS more efficient, or is it just a wrong way of calculating the efficiency?
I think I'm missing something in estimating the total "operations needed" for these algorithms. Is there a better/correct way of doing this?


Considering HW limitations, I am still not familiar with how different Kangaroo implementations work, I see that the JeanLucPons' based on VanitySearch requires GPU power (I assume more cores means better, but not sure what is the requirement for VRAM, CPU, RAM).
For BSGS, seems like keyhunt is the best, and works better with more RAM and more CPU cores.
Am I missing anything? Are there any other/better tools available for searching the ranges with known public keys?

In fact, for block 66, a private key must be generated with the 81129638414569788207641586040831 number, and this process is slow with a CPU, but using a graphics processor speeds it up.

I have written a simple Python program below that randomly generates private key within the range of block 66, and compares its public key at every moment with the public key of block number 66. If found, it displays a message and saves it in the data.txt file in the root of the program.

Code:

import bitcoin
import ecdsa
import secrets
from timeit import default_timer as timer   
start = timer() 
t=""
for _ in range(47):# generate 47 character  ( 0 )
    t = t + "0"
def generate_private_key():
    p=str(secrets.choice(range(2, 4)))#  generate random( 2 or 3) for fist number
    return (t+p+secrets.token_hex(8))#return { 47 character ( 0 ) + random (2 or 3 ) +  generate random (16 character in hexadecimal)  }

def private_key_to_public_key(private_key):
    sk = ecdsa.SigningKey.from_string(bytes.fromhex(private_key), curve=ecdsa.SECP256k1)
    vk = sk.get_verifying_key()
    compressed_public_key = vk.to_string("compressed").hex()
    return compressed_public_key

def main():
    target_address = "13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so"  # this is Target wallet address , just p2pkh compressed
    while True:#
    #for _ in range(100000):#while True:
        private_key = generate_private_key()#secrets.randbelow(32))  # Generate a random private key
        public_key = private_key_to_public_key(private_key)  # Convert private key to compressed public key
        
        # Generate Bitcoin address from public key
        bitcoin_address = bitcoin.pubtoaddr(public_key)
        print(private_key,'  ',bitcoin_address)
        if (bitcoin_address == target_address):
            f = open("data.txt", "a")
            f.write('\nprivate key int: ' 
                    + private_key
                    +'\nBitcoin address: '
                    + bitcoin_address+'\n_________\n')
            f.close()
                    
            print(f"Found matching Bitcoin address for private key: {private_key}")
            break
    print("--- %s seconds ---" ,timer()-start)


if __name__ == "__main__":
    main()

[puzzlesolver]

There is no pattern of it.

Note: This guy has put decimal number of the well established bitcoin puzzle serially.

Just converted hexadecimal to decimal

https://privatekeyfinder.io/bitcoin-puzzle/

[WanderingPhilospher]

Hi All,

I've been reading this and other related topics for a few weeks and I'm trying to understand the complexity of the different algorithms and approaches.

For Pollard's Kangaroo algorithm, someone gave an estimate of 2^66.05 operations needed for solving #130 ( https://bitcointalk.org/index.php?topic=5244940.2740 not sure how they reached this conclusion, but from reading about the algorithm it has a similar complexity to BSGS). This equals ~7.6x10¹⁹ operations needed.
For BSGS, from reading about it, is has a complexity of O(n^1/2). Taking the square root of the range (2¹³⁰ - 2¹²⁹ - 1) equals ~2.6x10¹⁹ operations needed.

Is this correct? Is BSGS more efficient, or is it just a wrong way of calculating the efficiency?
I think I'm missing something in estimating the total "operations needed" for these algorithms. Is there a better/correct way of doing this?
Edit: -> Reading keyhunt's documentation, it says it can easily reach the speed of several peta-keys per second (10¹⁸), so I'm definitely missing something...


Considering HW limitations, I am still not familiar with how different Kangaroo implementations work, I see that the JeanLucPons' based on VanitySearch requires GPU power (I assume more cores means better, but not sure what is the requirement for VRAM, CPU, RAM).
For BSGS, seems like keyhunt is the best, and works better with more RAM and more CPU cores.
Am I missing anything? Are there any other/better tools available for searching the ranges with known public keys?

If you read Jean Luc’s kangaroo GitHub, you would see how I estimated the number of ops needed. Here is a link to it:

https://github.com/JeanLucPons/Kangaroo#how-it-works

It has links to academia papers on the algo.

The quick way to calculate is to take the bit range, 130, divide by 2, add 1.05.
130/2 + 1.05 = 2^66.05

While Kangaroo and BSGS are similar, they are different. Probabilistic versus deterministic.

Choose a mid range and run both programs, with your hardware/equipment, and compare results.

As far as I understand, you mean that powerful individuals and teams like mining pools or similar ones have very high processing power and can accomplish our efforts to search for block 66, which may take several years, in less than a day?

No, once you try to move the funds, the public key is exposed.
A single modern GPU can solve #66 in less than a minute, with a known public key.

[nomachine]

In fact, for block 66, a private key must be generated with the 81129638414569788207641586040831 number, and this process is slow with a CPU, but using a graphics processor speeds it up.

This is a demonstration and test of how slow Python is. Even if it's a few million keys per second.

Random sequence:

Code:

from multiprocessing.pool import Pool
from subprocess import check_output
from tqdm import tqdm
from tqdm.contrib.concurrent import process_map
import secp256k1 as ice
import math
import random
import sys

div=16384
start=0x20000000000000000
end=0x3ffffffffffffffff
rng=0x3ffffffffffffffff-0x20000000000000000
stepout=int(rng/div)
stepin=0x200000000
right='13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so'
sys.stdout.write("\033[01;33m")
print('[+] target: '+right)

def int_to_bytes3(value, length = None): # in: int out: bytearray(b'\x80...
	if not length and value == 0:
		result = [0]
	else:
		result = []
		for i in range(0, length or 1+int(math.log(value, 2**8))):
			result.append(value >> (i * 8) & 0xff)
		result.reverse()
	return bytearray(result)

def pvk_to_addr(pvk):

    return ice.privatekey_to_address(0, True, pvk)

global c
c = 0

def go(r):
    global c
    if c % 100 == 0:
        print(f'[+] {c:,} Keys\r'.replace(',', ' '), end='')
    c = c + 1
    by = int_to_bytes3(r, 32)
    pvk = int.from_bytes(by, byteorder='big')  # Convert bytearray to integer
    ad = pvk_to_addr(pvk)
    # print('\r'+ad,end='')
    if ad == right:
        print('found!')
        print(r)
        print(hex(r))        
        HEX = "%064x" % int(r)
        wifc = ice.btc_pvk_to_wif(HEX)
        print(wifc)
        print('\a')
        with open('found.txt', 'w') as f:
            f.write(str(r))
            f.write('\n')
            f.write(hex(r))
            f.write('\n')
            f.write(wifc)
            f.write('\n')
            f.flush()
        sys.exit(0)
    return

def n(a,b):
	return list(range(a,b))

s=int(rng/div)
pool = Pool(10)

u=1048576
while True:
	ra=random.randint(start,end-u)
	rb=ra+u
	print(f'\r[+] from: {hex(ra)} to: {hex(rb)} range: {hex(u)}={u}')
	#global c
	c=0
	pool.map(go, range(ra,rb), chunksize=32768)

pool.close()
pool.join()

Sequential sequence:

Code:

from multiprocessing.pool import Pool
from subprocess import check_output
from tqdm import tqdm
from tqdm.contrib.concurrent import process_map
import secp256k1 as ice
import math
import random
import sys

div=16384
start=0x20000000000000000
end=0x3ffffffffffffffff
rng=0x3ffffffffffffffff-0x20000000000000000
stepout=int(rng/div)
stepin=0x200000000
right='13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so'
sys.stdout.write("\033[01;33m")
print('[+] target: '+right)

def int_to_bytes3(value, length = None): # in: int out: bytearray(b'\x80...
	if not length and value == 0:
		result = [0]
	else:
		result = []
		for i in range(0, length or 1+int(math.log(value, 2**8))):
			result.append(value >> (i * 8) & 0xff)
		result.reverse()
	return bytearray(result)

def pvk_to_addr(pvk):

    return ice.privatekey_to_address(0, True, pvk)

global c
c = 0

def go(r):
    global c
    if c % 100 == 0:
        print(f'[+] {c:,} Keys\r'.replace(',', ' '), end='')
    c = c + 1
    by = int_to_bytes3(r, 32)
    pvk = int.from_bytes(by, byteorder='big')  # Convert bytearray to integer
    ad = pvk_to_addr(pvk)
    # print('\r'+ad,end='')
    if ad == right:
        print('found!')
        print(r)
        print(hex(r))        
        HEX = "%064x" % int(r)
        wifc = ice.btc_pvk_to_wif(HEX)
        print(wifc)
        print('\a')
        with open('found.txt', 'w') as f:
            f.write(str(r))
            f.write('\n')
            f.write(hex(r))
            f.write('\n')
            f.write(wifc)
            f.write('\n')
            f.flush()
        sys.exit(0)
    return

def n(a,b):
	return list(range(a,b))

s=int(rng/div)
pool = Pool(10)

u = 1048576
for ra in range(start, end - u + 1, u):
    rb = ra + u
    print(f'\r[+] from: {hex(ra)} to: {hex(rb)} range: {hex(u)}={u}')
    c = 0
    pool.map(go, range(ra, rb), chunksize=32768)


pool.close()
pool.join()

[albert0bsd]

Hi All,

I've been reading this and other related topics for a few weeks and I'm trying to understand the complexity of the different algorithms and approaches.

https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/

You are mixing operations per second and keys per second and those aren't the same.

In BSGS with a precalculated set of 100 million keys, you only need to do a single operation ( publcikey subtraction) to determine if a key is in some 100 million keys right, that is 1 single operation but it give you a speed of 100 million keys / time, that is the difference, while bsgs do some thousands of subtraction per second (operations) it will give you some petakeya/s (speed) it is different way to measure it.

[zahid888]

Please advise me on which wallet to use where the facility to enable and disable RBF (Replace-By-Fee) is available. My fully synchronized Bitcoin Core wallet has become corrupted, and IDK, Why Electrum has removed the RBF option.

[vhh]

Please advise me on which wallet to use where the facility to enable and disable RBF (Replace-By-Fee) is available. My fully synchronized Bitcoin Core wallet has become corrupted, and IDK, Why Electrum has removed the RBF option.

Electrum has removed the RBF option starting with version 4.4 . All transactions have now RBF enabled by default. You can check it here https://github.com/spesmilo/electrum/issues/8490

You can use Blue wallet to control the RBF option : https://bluewallet.io/

[AndrewWeb]

No, once you try to move the funds, the public key is exposed.
A single modern GPU can solve #66 in less than a minute, with a known public key.

So how do you safely move the funds from 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so ?

[Lugh1Man]

Hi All,

I've been reading this and other related topics for a few weeks and I'm trying to understand the complexity of the different algorithms and approaches.

https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/

You are mixing operations per second and keys per second and those aren't the same.

In BSGS with a precalculated set of 100 million keys, you only need to do a single operation ( publcikey subtraction) to determine if a key is in some 100 million keys right, that is 1 single operation but it give you a speed of 100 million keys / time, that is the difference, while bsgs do some thousands of subtraction per second (operations) it will give you some petakeya/s (speed) it is different way to measure it.

Thanks Alberto, this is indeed what I was missing. I'm trying to understand the exact purpose of the n and k parameters of keyhunt. Is n in this case the number of pre-calculated keys? I'm trying to understand the efficiency of the algorithm - how long it would take to finish a full scan of a given range. Is it as simple as range size (keys) divided by speed (keys/s reported by keyhunt)? I'm assuming not, since this is not a brute-force algorithm.

Every fifth range is 32 (2⁵) times bigger than the last (e.g. the range for #130 has 32x more keys than the one for #125). If I could benchmark my system on how fast it could solve a simpler BSGS puzzle (say #125), how do I extrapolate on how fast it would do with #130? I assume it's faster than 32x the time it takes for #125.

No, once you try to move the funds, the public key is exposed.
A single modern GPU can solve #66 in less than a minute, with a known public key.

So how do you safely move the funds from 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so ?

You can build a bot that monitors the mempool (pending transactions) to make sure that there's no one else trying to send your BTC to another address (since they can easily calculate the private key once you publish your transaction). If anyone else is trying to do that, you can send another transaction with a higher fee to out-bid the other parties, but this can create a vicious cycle where no one wins because you all keep increasing the fee for your own transactions until nothing is left.

[WanderingPhilospher]

Hi All,

I've been reading this and other related topics for a few weeks and I'm trying to understand the complexity of the different algorithms and approaches.

https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/

You are mixing operations per second and keys per second and those aren't the same.

In BSGS with a precalculated set of 100 million keys, you only need to do a single operation ( publcikey subtraction) to determine if a key is in some 100 million keys right, that is 1 single operation but it give you a speed of 100 million keys / time, that is the difference, while bsgs do some thousands of subtraction per second (operations) it will give you some petakeya/s (speed) it is different way to measure it.

Thanks Alberto, this is indeed what I was missing. I'm trying to understand the exact purpose of the n and k parameters of keyhunt. Is n in this case the number of pre-calculated keys? I'm trying to understand the efficiency of the algorithm - how long it would take to finish a full scan of a given range. Is it as simple as range size (keys) divided by speed (keys/s reported by keyhunt)? I'm assuming not, since this is not a brute-force algorithm.

Every fifth range is 32 (2⁵) times bigger than the last (e.g. the range for #130 has 32x more keys than the one for #125). If I could benchmark my system on how fast it could solve a simpler BSGS puzzle (say #125), how do I extrapolate on how fast it would do with #130? I assume it's faster than 32x the time it takes for #125.

Did you read his GitHub? He has ranges and keys to benchmark your speed.

And just because you could solve 120 in say a day, doesn’t mean you could solve 125 in 32 days. If the key is in the beginning of the range, before 120s, in relation, you’d solve faster than 32 days. If it was after, then more than 32 days.

Keep it easier,
If a key in the 120 bit range was in the 8s and it took you one day, if 124s key was in the Fs, it would take you longer than 16 days. Make sense?

To give a better, worse case scenario, determine your speed, then calculate time taken by taking the last possible check in a range, (based on how large your baby step file is) and divide it by your speed.

[frozenen]

If someone found #66 and withdrew with an extremely high transaction fee say 10k USD and then within 1 minute the scammers find the private key with kangaroo and submit their withdrawal with lets say 100k USD fee! Would the scammers still get it? Cause this means all the lower bit range puzzles are useless to even attempt.

[ccinet]

If someone found #66 and withdrew with an extremely high transaction fee say 10k USD and then within 1 minute the scammers find the private key with kangaroo and submit their withdrawal with lets say 100k USD fee! Would the scammers still get it? Cause this means all the lower bit range puzzles are useless to even attempt.

Let's say it is like this.
In my opinion there are no scammers, in bitcoin laws whoever owns the private address owns the coins, these are the rules that Satoshi proposed