Pages:
Author

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

newbie
Activity: 25
Merit: 0
is it clear how many percent of puzzle 66 scanned from 0%?
If there is such a this information, then we dont scan the scanned range...
jr. member
Activity: 37
Merit: 1
34Sf4DnMt3z6XKKoWmZRw2nGyfGkDgNJZZ
Brother, if we find the 66th puzzle, please share how we can withdraw it to our own wallet without risk and which program we will use. Don't let people's labor go to waste, and don't let thieves steal people's labor.
member
Activity: 316
Merit: 34
It is enough to mark the tx as without RBF and the winner gets it all!

Stop spreading bs.
with RBF or without RBF, in both case transaction will attempt by many peoples, where running bots for find PK,
but safe and secure way i know , how to perform tx without fear of stolen, i have tested different solutions, and found correct way,
pbies writes 50% correct, but in his testing, others simple get pubk within sec's, and will cancel your tx, as its exist at fair away blocks, and will generate new tx, with rbf or without rbf, and new race will start
lot of viewer and poster's have some satoshi, can play test, simple create new tx without rbf, and use an other system with electrum, load PK, and simple cancel tx from other system, and create new one tx with new addr from 2nd system, you will see results, for proofe my words, when some of you test, and back to ask me alternate way to fearless tx creation
jr. member
Activity: 37
Merit: 1
34Sf4DnMt3z6XKKoWmZRw2nGyfGkDgNJZZ
Can someone with definite knowledge about this subject write? Can anyone with definite knowledge write about it? Let's say we found puzzle 66 and wanted to withdraw it to our own wallet. and we completed the transaction. Because the public key was exposed, it took seconds to find the wallet's private key. Can someone spend the money in this wallet? Doesn't the money in this wallet come to my wallet? SOME friends say that even if we find the wallet, someone else will steal the bitcoins. Is there such a thing? Then there is no point in searching for low puzzles? HOW TO WITHDRAW MONEY IN THE MOST SAFE WAY, IF WE FIND THE LOW PUZZLES
full member
Activity: 244
Merit: 126
It is enough to mark the tx as without RBF and the winner gets it all!

Stop spreading bs.
newbie
Activity: 6
Merit: 0
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.

Correct, but I won't call it a "scammer", perhaps just a leech.  And it won't be found within 1 minute. It will be found within a few seconds. The leech will still get 6 bitcoins, so even 200k RBF won't be too far fetched, as he'll get double his money back.
I feel sorry for people who enthusiastically tried puzzle 66 for many months or even a year or two, without realizing even if they found the private key there's no way in hell they will be able to withdraw it because unless you have 20/30/40k sitting around to gamble on the RBF lottery, you're not getting those funds.

The reason this did not happen before is because puzzle 65 and lower had very little to no reward money in it, so it was not worth the bidding war, but this all changes when the puzzle creator decided to put 6+ BTC in each puzzle. Now there's more people sitting and waiting with bots than people trying to solve.
newbie
Activity: 4
Merit: 0

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.

Yes, I've been reading the README, the code, and the description of the algorithm on wikipedia and other publications. I can't yet connect all the dots, but this helps, thanks!

So, is the n parameter the size of the range "chunk" you are looking at one at a time per thread (still unsure what k does)?
newbie
Activity: 14
Merit: 0
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


So 66,67,68,69, maybe others in the 70s ? have all become hot potatoes now.

Now it just becomes bragging rights and thats it.
Too many people will place higher fees unless you are very lucky.
How sad its become.
newbie
Activity: 33
Merit: 0
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
newbie
Activity: 20
Merit: 0
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.
full member
Activity: 1078
Merit: 219
Shooters Shoot...
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 (25) 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.
newbie
Activity: 4
Merit: 0
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 (25) 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.
jr. member
Activity: 43
Merit: 1
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 ?
vhh
newbie
Activity: 12
Merit: 2
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/
member
Activity: 260
Merit: 19
the right steps towerds the goal
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.
hero member
Activity: 862
Merit: 662
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.

member
Activity: 286
Merit: 15
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()
full member
Activity: 1078
Merit: 219
Shooters Shoot...
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.6x1019 operations needed.
For BSGS, from reading about it, is has a complexity of O(n1/2). Taking the square root of the range (2130 - 2129 - 1) equals ~2.6x1019 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 (1018), 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.



Quote

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.
newbie
Activity: 6
Merit: 0
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/
newbie
Activity: 14
Merit: 0
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.6x1019 operations needed.
For BSGS, from reading about it, is has a complexity of O(n1/2). Taking the square root of the range (2130 - 2129 - 1) equals ~2.6x1019 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()
Pages:
Jump to: