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

kTimesG

member

Activity: 165

Merit: 26

Quote from: eggsylacer on May 12, 2024, 09:47:01 AM

Quote from: kTimesG on May 12, 2024, 06:39:45 AM

If I would be the creator I would laugh so hard about some of the things discussed here.

Guys, a logarithm is an abstract concept, not some math function.

You get a thing called a "base change". In this case we're dealing with a change of base of an element from some position in a finite field (private keys) to an element in the same position in a finite group (EC public keys) and the problem is to solve for the position without a way to go back from the latter to the first (which is assumed to be hard, but not yet proven). And this in the best case that we even have such an element, and not some fingerprint of it (an address), which makes the problem levels of more absurdly difficult. WTF is with the real numbers field log2 discussion, it makes no sense, we already know the ranges double in size at each step, of course any polynomial regression or whatever is a straight line. Dividing 1 by (2**64) is four levels of magnitude below a double-precision IEEE floating point, so what errors do you expect, they will always be after the 64-th zero decimal digit in reality. Nevermind the fact that there's an infinity of real numbers between any two real numbers, so an infinity of computations. Take 7 as a private key and try to solve back from [1/4, 1/8) interval, mission impossible.

This is not an analytical problem, it's a group theory problem.

log2 - It's just a way of representing numbers in a different way. I'll ask you again, do you know what you're talking about?

I hope you are joking. That is NOT what a logarithm is.

Number: 7
Representing 7 in different ways:
Base 10: 7
Base 2: 0111
Base 7: 10
Base 16: 0x07
Base 1:

Shall I go on?

Logarithm of 7 in the infinite field of real numbers:
Base 2: 2.8073549221... (infinite number of decimals) - it counts how many bits you need to represent value 7
Base e: 1.9459101490553132... (infinite number of decimals) - it counts how many natural numbers you need that, raised to this power, yields 7

Logarithm of 7 in some modular finite field with N = 3:
log(7) = Huh

mod 3 (oh no, this doesn't work, hmm... is it 0? 1? 2? damn, something is missing, maybe we didn't even define the neutral element yet? or not even an binary addition operator?)

So, do YOU know what you are talking about?

nomachine

member

Activity: 503

Merit: 38

Quote from: maylabel on May 12, 2024, 08:07:11 AM

That's what is give me hope... I know is hard but let's try
By doing this in my half broken casio make me fell like Kepler Grin

Let's kill Tycho Brahe Cheesy

As I said way before, my hope is not to find the *exactly* address, but reduce the range because my hardware and my computer skills are not the top-notch, and I can't compete with people with gpu tho

It's more likely to find a $1 million lotto ticket using Dowsing than to solve this Puzzle. Grin

eggsylacer

newbie

Activity: 8

Merit: 0

Quote from: kTimesG on May 12, 2024, 06:39:45 AM

If I would be the creator I would laugh so hard about some of the things discussed here.

Guys, a logarithm is an abstract concept, not some math function.

You get a thing called a "base change". In this case we're dealing with a change of base of an element from some position in a finite field (private keys) to an element in the same position in a finite group (EC public keys) and the problem is to solve for the position without a way to go back from the latter to the first (which is assumed to be hard, but not yet proven). And this in the best case that we even have such an element, and not some fingerprint of it (an address), which makes the problem levels of more absurdly difficult. WTF is with the real numbers field log2 discussion, it makes no sense, we already know the ranges double in size at each step, of course any polynomial regression or whatever is a straight line. Dividing 1 by (2**64) is four levels of magnitude below a double-precision IEEE floating point, so what errors do you expect, they will always be after the 64-th zero decimal digit in reality. Nevermind the fact that there's an infinity of real numbers between any two real numbers, so an infinity of computations. Take 7 as a private key and try to solve back from [1/4, 1/8) interval, mission impossible.

This is not an analytical problem, it's a group theory problem.

log2 - It's just a way of representing numbers in a different way. I'll ask you again, do you know what you're talking about?

maylabel

newbie

Activity: 24

Merit: 0

nomachine

member

Activity: 503

Merit: 38

maylabel

newbie

Activity: 24

Merit: 0

Quote from: kTimesG on May 12, 2024, 06:39:45 AM

If I would be the creator I would laugh so hard about some of the things discussed here.

Guys, a logarithm is an abstract concept, not some math function.

You get a thing called a "base change". In this case we're dealing with a change of base of an element from some position in a finite field (private keys) to an element in the same position in a finite group (EC public keys) and the problem is to solve for the position without a way to go back from the latter to the first (which is assumed to be hard, but not yet proven). And this in the best case that we even have such an element, and not some fingerprint of it (an address), which makes the problem levels of more absurdly difficult. WTF is with the real numbers field log2 discussion, it makes no sense, we already know the ranges double in size at each step, of course any polynomial regression or whatever is a straight line. Dividing 1 by (2**64) is four levels of magnitude below a double-precision IEEE floating point, so what errors do you expect, they will always be after the 64-th zero decimal digit in reality. Nevermind the fact that there's an infinity of real numbers between any two real numbers, so an infinity of computations. Take 7 as a private key and try to solve back from [1/4, 1/8) interval, mission impossible.

This is not an analytical problem, it's a group theory problem.

Funnier than that is the circles of apocalypse

I agree with you. It's so many problems, I will humongous lists if I start go in depth.
My idea is to see if the pseudo-randomicity of the numbers gave some clues, like I did as a work 10 years ago.
Its the only route I'm thinking tbh bc I have a old laptop and find a job is horrible rn.
But even than that, my jupyter is killing my patience and floating number problem is a REAL pain in the a**.

as a side note: I was also telling my date I was reviewing GF(n) to solve a puzzle and I confronted a quite skeptical reaction like "you are not a procrastinator person to do this as a hobby".... oh well Grin

nomachine

member

Activity: 503

Merit: 38

Quote from: maylabel on May 12, 2024, 04:58:52 AM

I can't find any way to add the rule backward (child structure to parent key)
I have zero idea how to do it Huh

.... even chatgpt and mistral said is impossible ( i have questions about it Roll Eyes

, take as a grain of salt)

And no, a potato pc can't do all this smiths... I'm saying because I have a simple potato laptop and god knows how bad is going

The result will always be the same, whether you use the range as a decimal number and generate random numbers there, or whether you use log(2) as a different notation. You could also chase the numbers through other algorithms. Some will work faster and that is the only advantage.

kTimesG

member

Activity: 165

Merit: 26

If I would be the creator I would laugh so hard about some of the things discussed here.

Guys, a logarithm is an abstract concept, not some math function.

You get a thing called a "base change". In this case we're dealing with a change of base of an element from some position in a finite field (private keys) to an element in the same position in a finite group (EC public keys) and the problem is to solve for the position without a way to go back from the latter to the first (which is assumed to be hard, but not yet proven). And this in the best case that we even have such an element, and not some fingerprint of it (an address), which makes the problem levels of more absurdly difficult. WTF is with the real numbers field log2 discussion, it makes no sense, we already know the ranges double in size at each step, of course any polynomial regression or whatever is a straight line. Dividing 1 by (2**64) is four levels of magnitude below a double-precision IEEE floating point, so what errors do you expect, they will always be after the 64-th zero decimal digit in reality. Nevermind the fact that there's an infinity of real numbers between any two real numbers, so an infinity of computations. Take 7 as a private key and try to solve back from [1/4, 1/8) interval, mission impossible.

This is not an analytical problem, it's a group theory problem.

maylabel

newbie

Activity: 24

Merit: 0

nomachine

member

Activity: 503

Merit: 38

So.....here is a new toy.

puzzle 66 private key is from
65.00000000000000 to
65.99999999999999 Log(2)

Code:

import math
import sys
import secp256k1 as ice


# Function to convert Log(2) to decimal number
def log2_to_decimal(log2_value):
    return 2 ** log2_value

# Range of Log(2) values
start_log2 = 65.00000000000000
end_log2 = 65.99999999999999

# Number of decimal places for Log(2)
decimal_places = 15

target_caddr = "13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so"

# Iterate through the range and calculate decimal numbers
for i in range(int(start_log2 * 10**decimal_places), int((end_log2 + 10**-decimal_places) * 10**decimal_places)):
    log2_value = i / 10**decimal_places
    decimal_number = log2_to_decimal(log2_value)
    HEX = "%064x" % int(decimal_number)
    dec = int(HEX, 16)
    caddr = ice.privatekey_to_address(0, True, dec) 
    message = "\r[+] {}".format(dec)
    messages = []
    messages.append(message)
    output = ''.join(messages) + "\r"
    sys.stdout.write(output)
    sys.stdout.flush()
    if caddr == target_caddr:
       wifc = ice.btc_pvk_to_wif(HEX)
       print(wifc)
       break

This experimental log(2) method skips decimal numbers on the fly as desired in "decimal_places" . . .
Maybe someone can guess on luck what the "decimal_places" number is (from 1 to 17) . Grin

eggsylacer

newbie

Activity: 8

Merit: 0

nomachine

member

Activity: 503

Merit: 38

Quote from: pbies on May 11, 2024, 05:51:52 PM

If you guys are saying that pubkey is enough to take over any puzzle tx,
then it can be done with any tx that is in mempool.

It is possible, but it requires knowledge of the private key range with a minimum precision width of Puzzle 30 scale, so that you could brute-force the private key on a potato PC. The key thing here is that we know the exact ranges of the keys for puzzles. And on too big like Puzzle 130, that factor doesn't help us either. Due to lack of hardware.

maylabel

newbie

Activity: 24

Merit: 0

pbies

full member

Activity: 297

Merit: 133

If you guys are saying that pubkey is enough to take over any puzzle tx,
then it can be done with any tx that is in mempool.

eggsylacer

newbie

Activity: 8

Merit: 0

I formulated the question: is it possible to create a number system in which:

1=1
2=3
3=7
4=8
5=21
6=49
.....

Also I have a question, how did the creator access the addresses above puzl#160 repeatedly? I.e. he was transferring btc from these addresses to smaller addresses. Did he really save every key to the address and "manually" (using an algorithm) spell them out?

eggsylacer

newbie

Activity: 8

Merit: 0

Quote from: abdenn0ur on May 04, 2024, 03:40:59 PM

Quote from: Tepan on May 04, 2024, 10:00:12 AM

wish me luck, current speed is 100K keys per sec.

100kk/s is very low.
You're better off using keyhunt by alberto
You may get +1Mk/s even on a potato CPU

Perhaps his algorithm works exponentially? That is, the time to find the key decreases exponentially.

eggsylacer

newbie

Activity: 8

Merit: 0

Quote from: tifosi87 on May 10, 2024, 03:19:01 PM

hi all i read the post since one year sorry for my english i found a interesting think but i does takes me further. in every elliptic curve like y^2= x^3+7 there is something interesting like :
if P(1,y1) - k times--> Q(-29/3 ,y2)
P(2,y3) --k times--> Q(-3,y2)
so on there is a simple math here where k is always too know independent from whcih curve we work .
i don't want to give more information this operation is 10 times faster then k*G= and find the x value

I think to solve the equation we need to introduce a third Z axis

eggsylacer

newbie

Activity: 8

Merit: 0

maylabel

newbie

Activity: 24

Merit: 0

Quote from: kTimesG on May 11, 2024, 04:20:08 AM

Quote from: tifosi87 on May 10, 2024, 03:19:01 PM

hi all i read the post since one year sorry for my english i found a interesting think but i does takes me further. in every elliptic curve like y^2= x^3+7 there is something interesting like :
if P(1,y1) - k times--> Q(-29/3 ,y2)
P(2,y3) --k times--> Q(-3,y2)
so on there is a simple math here where k is always too know independent from whcih curve we work .
i don't want to give more information this operation is 10 times faster then k*G= and find the x value

Too bad the points need to be on the curve. We already know about the endomorphisms.

I'd say any attempt to break a private key that involves more than a constant amount of scalar multiplications (no matter how well optimized by precomputed tables), has very few chances of success.
Any multiplication means, by definition, more than one addition, more time.

Random key -> multiply and match -> good luck waiting.

First level of magnitude reduction: don't do scalar multiplications.

Second wall to break is then the point addition (and there's one more after that, and finally one more after). I already said too much, but I believe there's something that can run around 20x in less time (fewer computations) if we know the public key and simplify the question. Some known details around secp256k1 help a lot.

Yeah I endorse what is kTimeG is saying.
the problems is way more deep than I even expected, honestly

I'm not specialist in secp256, not even close, but the sheer amount of calculation is above my capacities. Besides my Jupyter and R have an absolutely collapse trying to do the statistics

a simple example, for the puzzle 65 the coordinates are
X: 21769406468394979245979020739332080729679479243955596515614749275274212371227
Y:102907830890434238525231690377346540046672568029169549965500018466490455252476

you will understand very quick floating point problems, if you come from scientific field like me
besides all the shenanigans around binary calculation Huh

One website I found fantastic is https://learnmeabitcoin.com/
This person need a award because the site is amazing.
Have a lot of calculator and they try to simplify the max possible but honestly is absurdly convoluted.
But I admire their effort, is worth it to take a look

Another stuffs I was reading is this week was

https://pure.tue.nl/ws/portalfiles/portal/128510960/BEP_BSA_298_299_300_301.pdf
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3367674
https://engineering.purdue.edu/kak/compsec/NewLectures/Lecture7.pdf

On this papers you may can guess why K3ntina is trying to push this idea of the circle: its because of the nature of the calculation, sometimes they have a sqrt(2) have on the pi series expansion in the 3order almost the same decimals where some of the addresses can be build on it.
But again, correlation is not causation: k3ntina is suffering of apophenia... very common in conspiracy theorist

again I'm not bitcoin specialist, i'm scientist so I went to my route what is: statistics
Apparently even if is a HD and this are child wallets, the reality hass one detail: the onwer FORCED to have this structure.
This reminds me a lot of the case of the Profanity (article: https://medium.com/@rebryk/how-to-hack-a-vanity-address-generated-with-profanity-ffad61ecacd2).
Beside my cpu almost meltdown of trying to run that code, the idea from this case is is very simple, but on bitcoin has one caveat: we dont have the extended public key and is essential on this case.
so my best next guess is to try to see if the pseudo-random numbers interfere in the wallet construction beside the owner own interference.... and Im still learning but looks like has something on that could be use to reduce the range of the search

Btw, on the k3ntina offer, I also offer a zoom meeting to discuss about it Grin

kTimesG

member

Activity: 165

Merit: 26

Quote from: tifosi87 on May 10, 2024, 03:19:01 PM

hi all i read the post since one year sorry for my english i found a interesting think but i does takes me further. in every elliptic curve like y^2= x^3+7 there is something interesting like :
if P(1,y1) - k times--> Q(-29/3 ,y2)
P(2,y3) --k times--> Q(-3,y2)
so on there is a simple math here where k is always too know independent from whcih curve we work .
i don't want to give more information this operation is 10 times faster then k*G= and find the x value

Too bad the points need to be on the curve. We already know about the endomorphisms.

I'd say any attempt to break a private key that involves more than a constant amount of scalar multiplications (no matter how well optimized by precomputed tables), has very few chances of success.
Any multiplication means, by definition, more than one addition, more time.

Random key -> multiply and match -> good luck waiting.

First level of magnitude reduction: don't do scalar multiplications.

Second wall to break is then the point addition (and there's one more after that, and finally one more after). I already said too much, but I believe there's something that can run around 20x in less time (fewer computations) if we know the public key and simplify the question. Some known details around secp256k1 help a lot.

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