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

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?

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  

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.

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.

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

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


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) .  

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.

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.

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?

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

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

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 

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 

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.

ok hi there, k3ntINA, we need so many kind of skills with this, still this could be the only skill needed,
to solve it right, and some, some kind of skills you are showing,
but merely few get the picture, get it, what is your youtube channel, or the link
if you have posted it,

This puzzle is exactly created to test such ideas. You don't need to prove yourself to anyone. just solve puzzle 130# by this algorithm. that's enough