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

casinotester0001

member

Activity: 196

Merit: 67

Quote from: zahid888 on August 31, 2022, 05:01:59 AM

Quote from: saatoshi_rising on April 27, 2017, 01:41:08 AM

Quote from: sabbybibi on March 13, 2017, 11:17:30 AM

This puzzle is very strange. If it's for measuring the world's brute forcing capacity, 161-256 are just a waste (RIPEMD160 entropy is filled by 160, and by all of P2PKH Bitcoin). The puzzle creator could improve the puzzle's utility without bringing in any extra funds from outside - just spend 161-256 across to the unsolved portion 51-160, and roughly treble the puzzle's content density.

If on the other hand there's a pattern to find... well... that's awfully open-ended... can we have a hint or two? Cheesy

I am the creator.

You are quite right, 161-256 are silly. I honestly just did not think of this. What is especially embarrassing, is this did not occur to me once, in two years. By way of excuse, I was not really thinking much about the puzzle at all.

I will make up for two years of stupidity. I will spend from 161-256 to the unsolved parts, as you suggest. In addition, I intend to add further funds. My aim is to boost the density by a factor of 10, from 0.001*length(key) to 0.01*length(key). Probably in the next few weeks. At any rate, when I next have an extended period of quiet and calm, to construct the new transaction carefully.

A few words about the puzzle. There is no pattern. It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty). It is simply a crude measuring instrument, of the cracking strength of the community.

Finally, I wish to express appreciation of the efforts of all developers of new cracking tools and technology. The "large bitcoin collider" is especially innovative and interesting!

Here is the creators first and last post..

saatoshi_rising created Bitcoin puzzle transaction
naakamoto_rising created a puzzle too? Bitcoin address linked to Bitcoin genesis address https://bitcointalksearch.org/topic/bitcoin-address-linked-to-bitcoin-genesis-address-5367558

Quote from: naakamoto_rising on August 24, 2022, 07:28:23 AM

Code:

-----BEGIN BITCOIN SIGNED MESSAGE-----
https://news.bitcoin.com/online-sleuths-believe-satoshi-nakamotos-bitcoin-stash-is-a-blockchain-treasure-hunt-meant-to-be-found/
-----BEGIN SIGNATURE-----
1s1wZLBTjFZJi8DrN1kogV9ZxRZxwvKQJ
HMoLqUcrjx22an/MrY4uy2z9Nowz4Ag9x3kzsbqz+FaNDSgkH+boXhWUyEkhq4bX8c24Ju+RHwWGltWKopRcg9k=
-----END BITCOIN SIGNED MESSAGE-----

or are they the same person Huh

zahid888

member

Activity: 272

Merit: 20

the right steps towerds the goal

Quote from: saatoshi_rising on April 27, 2017, 01:41:08 AM

Quote from: sabbybibi on March 13, 2017, 11:17:30 AM

This puzzle is very strange. If it's for measuring the world's brute forcing capacity, 161-256 are just a waste (RIPEMD160 entropy is filled by 160, and by all of P2PKH Bitcoin). The puzzle creator could improve the puzzle's utility without bringing in any extra funds from outside - just spend 161-256 across to the unsolved portion 51-160, and roughly treble the puzzle's content density.

If on the other hand there's a pattern to find... well... that's awfully open-ended... can we have a hint or two? Cheesy

I am the creator.

You are quite right, 161-256 are silly. I honestly just did not think of this. What is especially embarrassing, is this did not occur to me once, in two years. By way of excuse, I was not really thinking much about the puzzle at all.

I will make up for two years of stupidity. I will spend from 161-256 to the unsolved parts, as you suggest. In addition, I intend to add further funds. My aim is to boost the density by a factor of 10, from 0.001*length(key) to 0.01*length(key). Probably in the next few weeks. At any rate, when I next have an extended period of quiet and calm, to construct the new transaction carefully.

A few words about the puzzle. There is no pattern. It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty). It is simply a crude measuring instrument, of the cracking strength of the community.

Finally, I wish to express appreciation of the efforts of all developers of new cracking tools and technology. The "large bitcoin collider" is especially innovative and interesting!

Here is the creators first and last post..

Evillo

member

Activity: 185

Merit: 15

Two things you should never abandon: Family & BTC

Quote from: citb0in on August 30, 2022, 02:53:17 AM

Quote from: GR Sasa on August 26, 2022, 07:56:58 AM

The reason why puzzle 65 was cracked because the owner of the puzzle revealed the public key of every 5 bit address. For example puzzle 2^65, 2^70, 2^75, 2^80 they're all increasing 5 bits in difficulty but it's public key is revealed which makes it of course easier to attack and get it's key. When the public key of those are revealed people were able to crack them by the help of algorithms like Kangaroo, or BSGS.

Puzzle 161 to 256 were not cracked, but the owner took its coin and added them up for the unsolved parts of the puzzles. He did this because he knew cracking 256 bits is impossibly hard and also since Bitcoin address is only 160 bits.

Hope that answers your question

Hey, sorry for late reply but thanks a bunch for this nice explanation

Do we know the owner, who is that? And why did he reveal the pubkey for every 5 bit addresses, what was the reason therefore and do you have a link where I can find this information where he/she published it? Does that mean that if anyone gets my pubkey for a certain adress he is likely able to crack my privkey for that address? When gets a pubkey of an address disclosed and why? What countermeasures are best-practice therefore, how could one protect against this

Hopefully anyone can address this questions. Thanks in advance.

We don't know the owner, he only posted in this thread in its early years, just go back in this thread's pages .. He thanked the community for trying to create great cracking tools.. so he most likely did this whole puzzle thingy to test the community strength of cracking BTC .. he also revealed public keys to see if knowing the public key can make any difference in minimizing cracking difficulty.. obviously, it made a huge difference ..coz knowing the public key turned out to make a 115 bit key with a known public key easier to crack than a 64 bit key with hidden public key (thanks to Pollard's kangaroo) .. however, this doesn't make cracking a random btc address any easier (you know, the address with a fully randomized 256 bit private key that android or pc wallet software generates for you) because the most you can crack with a public key nowadays is 119 bit .. if you wanna try it on 256 bit, you would spend billions of years and still not succeed . So yeah, a typical btc address is safe and sound with or without its public key exposed

citb0in

hero member

Activity: 630

Merit: 731

Bitcoin g33k

Quote from: GR Sasa on August 26, 2022, 07:56:58 AM

The reason why puzzle 65 was cracked because the owner of the puzzle revealed the public key of every 5 bit address. For example puzzle 2^65, 2^70, 2^75, 2^80 they're all increasing 5 bits in difficulty but it's public key is revealed which makes it of course easier to attack and get it's key. When the public key of those are revealed people were able to crack them by the help of algorithms like Kangaroo, or BSGS.

Puzzle 161 to 256 were not cracked, but the owner took its coin and added them up for the unsolved parts of the puzzles. He did this because he knew cracking 256 bits is impossibly hard and also since Bitcoin address is only 160 bits.

Hope that answers your question

Hey, sorry for late reply but thanks a bunch for this nice explanation

Do we know the owner, who is that? And why did he reveal the pubkey for every 5 bit addresses, what was the reason therefore and do you have a link where I can find this information where he/she published it? Does that mean that if anyone gets my pubkey for a certain adress he is likely able to crack my privkey for that address? When gets a pubkey of an address disclosed and why? What countermeasures are best-practice therefore, how could one protect against this

Hopefully anyone can address this questions. Thanks in advance.

GR Sasa

member

Activity: 194

Merit: 14

Hey citb0in,

People are stuck on puzzle 64 because this is the most far we can go (yet). If Bitcoin price goes up again like last year, i'll definitely rent, steal if possible and have a big high-end Army GPUs and hope that i solve it and buy my dream car.

The reason why puzzle 65 was cracked because the owner of the puzzle revealed the public key of every 5 bit address. For example puzzle 2^65, 2^70, 2^75, 2^80 they're all increasing 5 bits in difficulty but it's public key is revealed which makes it of course easier to attack and get it's key.

when the public key of those are revealed people were able to crack them by the help of algorithms like Kangaroo, or BSGS.

Puzzle 161 to 256 were not cracked, but the owner took its coin and added them up for the unsolved parts of the puzzles. He did this because he knew cracking 256 bits is impossibly hard and also since Bitcoin address is only 160 bits.

Hope that answers your question

citb0in

hero member

Activity: 630

Merit: 731

Bitcoin g33k

Just stumbled across this thread and read with great curiosity about this puzzle of transaction 08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15. I have not read all the pages of the thread but the following question came to my mind while reading through. Why is everyone stuck on puzzle 64? The next puzzle, 65, has also been cracked. Apparently, the difficulty of cracking the puzzle is always increased. How can it be that the apparently most difficult puzzles are 256, 255, 254, ... up to and including 161 have been cracked?

Evillo

member

Activity: 185

Merit: 15

Two things you should never abandon: Family & BTC

Reading all the way back from first page .. it was amusing to see the development of this topic .. people were all about trying to solve "a math formula" in order to predict all puzzle bits (puzzle creator had it all the way until 256 bits then changed his mind after remembering that trying to crack anything over 160 bits is a fantasy) .. it was funny most ppl back then thought that cracking even 50 bits would take "decades" .. until the almighty bitcrack and kangaroo came into existence .. i wonder how this thread would look like in 10 years from now

Evillo

member

Activity: 185

Merit: 15

Two things you should never abandon: Family & BTC

Quote from: GR Sasa on July 30, 2022, 11:05:41 AM

Puzzle 64 beating everyone? No! Just wait for GR Sasa's GPU'S Army to come. They will go far beyond 64 bits.

Nice! However, i find it a little bit unbelievable that you only waited all those years to provide such a huge claim as a response to a random post on the puzzle thread .. i wonder how much longer it might take until someone else comes here and claim they invented quantum computers that will beat the entire puzzle range.

Btw, it's already written some where on github that you need 256 TESLA V100 to cover puzzle #120 (same #64 difficulty if using kangaroo) .. and even then, you would need two months to solve it .. good luck to your army 😘

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: GR Sasa on July 30, 2022, 11:05:41 AM

Puzzle 64 beating everyone? No! Just wait for GR Sasa's GPU'S Army to come. They will go far beyond 64 bits.

And exactly how many GPUs does your army have, and what models are they?

Without a Bitcrack build with major improvements, you will need an extraordinary number of [NVIDIA] GPUs to even get 20 miles within #64's gate.

There are loop unrolls that can be made in the SHA256 and RIPEMD160 modules, because the number of blocks as input to these hash functions is constant.

GR Sasa

member

Activity: 194

Merit: 14

Puzzle 64 beating everyone? No! Just wait for GR Sasa's GPU'S Army to come. They will go far beyond 64 bits.

Evillo

member

Activity: 185

Merit: 15

Two things you should never abandon: Family & BTC

Puzzle #64 is beating everyone .. this tells us that even if it gets solved, moving on to puzzle #66 and trying to solve it is practically impossible .. let alone trying to crack 67, 68 69 etc..

This is it guys, only 64 and 120 are to be cracked (hardly) .. every other puzzle is there to stay unsolved forever.. unless owner decides to reveal public keys of all the small ranges, which will not happen, as it would defeat the purpose of the puzzle

Jolly Jocker

jr. member

Activity: 49

Merit: 1

Quote

Will it work with Python?

If "NO" - perhaps there is an option for working with Python?

This code is programmed in Python 3.x ...

You need this for this code as import.. https://github.com/iceland2k14/secp256k1

iparktur

jr. member

Activity: 119

Merit: 1

Quote from: Jolly Jocker on June 22, 2022, 05:16:32 AM

Quote

Sorry, what exactly is happening in this?

Another form of random with "FLOAT"

That's actually quite simple.. the 64-bit area is divided into decimal places. From 0.000001 to 1.000000 captures the entire range.. The size of the steps is set using the decimal places. This can be varied, the more decimal places, the smaller/finer the steps...

Will it work with Python?

If "NO" - perhaps there is an option for working with Python?

Jolly Jocker

jr. member

Activity: 49

Merit: 1

Quote

Sorry, what exactly is happening in this?

Another form of random with "FLOAT"

That's actually quite simple.. the 64-bit area is divided into decimal places. From 0.000001 to 1.000000 captures the entire range.. The size of the steps is set using the decimal places. This can be varied, the more decimal places, the smaller/finer the steps...

cookiebro

newbie

Activity: 7

Merit: 1

Quote from: Jolly Jocker on June 08, 2022, 04:14:15 PM

BTC FLOAT SCAN #64

another way of scanning..

Code:

import time
import random
import secp256k1 as ice
from time import sleep

t = time.ctime()
print('',t)

print('\n\n * BTC FLOAT SCAN #64 *\n')
print('\n |=========CURRENT===LINE=========||=====CNT====||=FLOAT=||=LOOP=|\n\n')
sleep(1)
print(' scanning...',end='\r')

def range_with_floats(start, stop, step):
while stop > start:
yield start
start += step

a=9223372036854775807
b=9223372036854775808
#=========================================
c = 1000000
d = 3846
group_size = c
#=========================================
e = 0.0000031115691002
f = 1.0000000000000000
g = 0.000001
#=========================================
total=0
loop=0
for x in range_with_floats(e, f, g):
loop += 1
for i in range(d):
x += 0.00026
xx = x
x1 = int(a * x + b)
key_int = x1
P = ice.scalar_multiplication(key_int)
current_pvk = key_int + 1

Pv = ice.point_sequential_increment(group_size, P)

for t in range(group_size):
this_btc = ice.pubkey_to_address(0, True, Pv[t*65:t*65+65])
total+=1
if this_btc.startswith('16jY7'): # 16jY7q
print(' ',hex(current_pvk+t)[2:],(this_btc)[:12] + '... ',str(total).zfill(12),'','{0:.5f}'.format(xx),'',str(loop).zfill(6),end='\r')

if this_btc == '16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN':
file=open(u"BTC.Target.Info.txt","a")
file.write('\n ' + this_btc + ' | ' + hex(current_pvk+t))
file.close()
sleep(1)
exit()

P = Pv[-65:]
current_pvk += group_size

Sorry, what exactly is happening in this?

Jolly Jocker

jr. member

Activity: 49

Merit: 1

BTC FLOAT SCAN #64

another way of scanning..

Code:

import time
import random
import secp256k1 as ice
from time import sleep

t = time.ctime()
print('',t)

print('\n\n * BTC FLOAT SCAN #64 *\n')
print('\n |=========CURRENT===LINE=========||=====CNT====||=FLOAT=||=LOOP=|\n\n')
sleep(1)
print(' scanning...',end='\r')

def range_with_floats(start, stop, step):
while stop > start:
yield start
start += step

a=9223372036854775807
b=9223372036854775808
#=========================================
c = 1000000
d = 3846
group_size = c
#=========================================
e = 0.0000031115691002
f = 1.0000000000000000
g = 0.000001
#=========================================
total=0
loop=0
for x in range_with_floats(e, f, g):
loop += 1
for i in range(d):
x += 0.00026
xx = x
x1 = int(a * x + b)
key_int = x1
P = ice.scalar_multiplication(key_int)
current_pvk = key_int + 1

Pv = ice.point_sequential_increment(group_size, P)

for t in range(group_size):
this_btc = ice.pubkey_to_address(0, True, Pv[t*65:t*65+65])
total+=1
if this_btc.startswith('16jY7'): # 16jY7q
print(' ',hex(current_pvk+t)[2:],(this_btc)[:12] + '... ',str(total).zfill(12),'','{0:.5f}'.format(xx),'',str(loop).zfill(6),end='\r')

if this_btc == '16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN':
file=open(u"BTC.Target.Info.txt","a")
file.write('\n ' + this_btc + ' | ' + hex(current_pvk+t))
file.close()
sleep(1)
exit()

P = Pv[-65:]
current_pvk += group_size

POD5

member

Activity: 251

Merit: 10

Keep smiling if you're loosing!

Quote from: Feron on May 31, 2022, 12:11:28 PM

funny coincidence 63 puzzle 7cce5efd : accf6808

Code:

from tqdm import tqdm
import secp256k1 as ice
for x in tqdm(range(4000000)):
xx = str(x)
ke = ice.checksum(xx).hex()
#cc = ice.privatekey_loop_h160(10,0,True,xx).hex()
if (ke).endswith("7cce5efd"):
  print(xx,x)
if "7cce5efd" in (ke):
  f=open("kkk.txt","a")
  f.write(str(xx)+"-"+(ke)+"\n")
  f.close()

scanner for this method

Code:

import secp256k1 as ice
for xa in range(400000):
for xb in range(400000):
  x1 = str(xa)
  x2 = str(xb)
  k1 = ice.checksum(x1).hex()
  k2 = ice.checksum(x2).hex()
  xx = int(k1+k2,16)
  ke = ice.privatekey_loop_h160(1,0,True,xx).hex()
  if (ke).endswith("48a4"):
   print(xx,k1+k2,ke)
  if "3ee4133d991f52fdf6a25c9834e0745ac74248a4" in (ke):
   f=open("von.txt","a")
   f.write(str(xx)+"-"+(ke)+"\n")
   f.close()

I like your way of coding.
But where is the coincidence and why do you choose 400000?
Hmm, ok, I think I got it... Not! Grin

Evillo

member

Activity: 185

Merit: 15

Two things you should never abandon: Family & BTC

Quote from: WanderingPhilospher on May 30, 2022, 12:19:01 PM

Quote from: Evillo on May 30, 2022, 10:59:13 AM

We need a strong random search repo .. coz i think searching in ranges is useless (including random range search).. pure random search is the only way .. the only thing that "might" beat extreme randomness is randomness itself .. think about it, you might open a random search bat file to search for the easiest puzzle and find it immediately .. or you can open it and it keeps running for centuries without luck .. but at least you know you could get lucky with randomness ..on the other hand, searching in ranges GUARANTEES you'll stay stuck for a long while especially if the puzzle prv key turns out to be located way far in the range .. i tried keyhunt for cpu but it's too slow .. also tried random bitcrack search but i hate the fact that it creates sample points to start searching from .. it's exactly like random range search not a pure random one .. could not find any software that utilizes gpu for absolute random search

For GPU, it would be slower than normal search. Example, a sequential search for keyhunt will be much faster than a random search. I have modified keyhunt and vansearch to do random search, but it's still somewhat sequential. If you have 1 million threads on a GPU each one has to rekey, well key 1 is random and then starts going sequential until last thread sets it's random key, and then the whole process starts over. I will dig up old files (at some point) and look at the code again. Granted the 1 millionth key takes less than 5 seconds, but during those 5 seconds, the other keys are in sequential mode.
But at the same time, if you are searching random ranges, you have the same chance of finding the key immediately. And that's what most pools are designed to do; create all ranges in the 64 bit range, and assign those randomly.

Yeah thanks for pointing that out .. i overlooked the price you must pay for absolute randomness .. Rotor-cuda for example shows it very clearly when you run it with a setting of rekeying every 1b key .. counter shows a drop in speed of over 100m key/s during rekey before it climbs back up again after rekey is done ..imagine the rekey after every single key .. overhead would be devastating .. so i guess we have to stick to random ranges after all

Feron

jr. member

Activity: 67

Merit: 1

funny coincidence 63 puzzle 7cce5efd : accf6808

Code:

from tqdm import tqdm
import secp256k1 as ice
for x in tqdm(range(4000000)):
xx = str(x)
ke = ice.checksum(xx).hex()
#cc = ice.privatekey_loop_h160(10,0,True,xx).hex()
if (ke).endswith("7cce5efd"):
  print(xx,x)
if "7cce5efd" in (ke):
  f=open("kkk.txt","a")
  f.write(str(xx)+"-"+(ke)+"\n")
  f.close()

scanner for this method

Code:

import secp256k1 as ice
for xa in range(400000):
for xb in range(400000):
x1 = str(xa)
x2 = str(xb)
k1 = ice.checksum(x1).hex()
k2 = ice.checksum(x2).hex()
xx = int(k1+k2,16)
ke = ice.privatekey_loop_h160(1,0,True,xx).hex()
if (ke).endswith("48a4"):
print(xx,k1+k2,ke)
if "3ee4133d991f52fdf6a25c9834e0745ac74248a4" in (ke):
f=open("von.txt","a")
f.write(str(xx)+"-"+(ke)+"\n")
f.close()

WanderingPhilospher

full member

Activity: 1162

Merit: 237

Shooters Shoot...

Quote from: Evillo on May 30, 2022, 10:59:13 AM

We need a strong random search repo .. coz i think searching in ranges is useless (including random range search).. pure random search is the only way .. the only thing that "might" beat extreme randomness is randomness itself .. think about it, you might open a random search bat file to search for the easiest puzzle and find it immediately .. or you can open it and it keeps running for centuries without luck .. but at least you know you could get lucky with randomness ..on the other hand, searching in ranges GUARANTEES you'll stay stuck for a long while especially if the puzzle prv key turns out to be located way far in the range .. i tried keyhunt for cpu but it's too slow .. also tried random bitcrack search but i hate the fact that it creates sample points to start searching from .. it's exactly like random range search not a pure random one .. could not find any software that utilizes gpu for absolute random search

For GPU, it would be slower than normal search. Example, a sequential search for keyhunt will be much faster than a random search. I have modified keyhunt and vansearch to do random search, but it's still somewhat sequential. If you have 1 million threads on a GPU each one has to rekey, well key 1 is random and then starts going sequential until last thread sets it's random key, and then the whole process starts over. I will dig up old files (at some point) and look at the code again. Granted the 1 millionth key takes less than 5 seconds, but during those 5 seconds, the other keys are in sequential mode.
But at the same time, if you are searching random ranges, you have the same chance of finding the key immediately. And that's what most pools are designed to do; create all ranges in the 64 bit range, and assign those randomly.

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