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

Hey hey now, it's not cool talking to a colleague like that, soooo is obvious you are making fun of his speed, lets say the script is so fast that it flashes on the screen very fast, and lets leave it at that.
Instead of smearing each other, lets develop an algorithm to show the world *who we are.

---

Proposal untested :
Subtract 2 from target, set as target2, set original key as target1, subtract n/2 from target1 and perform point torsion on it, subtract 1 from target2 then perform point torsion on it, now either sub or add the results together, check to see if you get any results.
Yesterday I managed to definitively find the value of last char of unknown keys, but I forgot it after going to get some coffee. 😐
I can't manage testing anything right now cause I resent myself for that.

Proposal 2 : normal division not using torsion, halve the target first, set as target2, original point as target1, divide both by starting range = n/2-100, end range = n/2+100, then add/sub results, check for a solution.

P2-2 : we need to find a way to get a composite number, even if it's as large as 255bit, remember do everything over scalar first, if our key is :
Key inverse, -n :
Set T1 and T2, do the division sub/add, with n/2-100 etc, check the result.
I know you will see the distance between them being divided, but try to divide one of the results which has many trailing zeros, divide by power of 2, until you reach to fractions, you will see that there is a possibility to do the same with unknown keys. Try these, I know you can find something, after all you taught me how to do point operations on EC. 😉

You know where to find my test scripts on project development. (Ground breaking etc).lol

---

*= who are we really? We will deal with this identity crisis later.😂

Print ALL the keys on screen is stupid and slow

Soooo nomachine, how fast is fast?
How fast can your script on your PC solve a 60 bit key?
You say it’s fast, just not fast enough to solve puzzles over 60, so how fast is fast?

That's the first test script...You have a pm. Let's not bother others with technicalities here. 

I just tried your previous program (for puzzle 15) that is using openssl...

It works ok  but only for puzzle 15...

I edited the code with differend rmd160 hashes  and changed the  value int puzzle = 15  to a different puzzle but then it counts endlessly and never finds a solution.

If i want to try this program for different puzzles what parameters i need to change in the code

Why numbers at all?

Let's say we have a Puzzle 65, 64, 63 private keys in bytes:

and so on....

Do you see how many leading zeros there are and how small the end is in bytes?

b'\x00' * 23 (twenty-three zeroes) + 9 bytes

You need to generate the last 9 bytes to get full WIF (from 66 to 71 bits).

 I went one step further now. To represent hash160 directly in the vector as bytes and

 
 compare them directly afterwards without any conversion to hex.

This works fast as hell.  It is SO fast that you can barely see the numbers on the display. Flashing characters on the screen....
But it's not fast enough for Puzzles over 60...Need GPU....

Let's back to earth...

At some point I had an idea (probably very stupid cause i'm complete nood in maths)

In few program (like keyhunt, bitcrack) there is an option  called STRIDE.

As I understand that option simply defines a step (it skips given value) in searching for private key.

Normally scanning a large range (like puzzle 66) is impossible with home computer. But when we use quite high stride we can search the whole range in matter of seconds. (of course it will skip massive amount of keys)

And here is my thought: Let's say we have a 66 bit private key. Such key must be a multiple of smaller number. What if we use STRIDE option big enough to very fast scan the whole range and that stride value would be a number that multiplied is our private key ?

Now, some may say ... but how do you know which exactly STRIDE value use ?  And here my only answer is to write a program that would randomly generate STRIDE with given length (long enough to fast scan the whole range) and constantly seeking the range with new stride.

Can it work ? Or am i missing something here (i am sure i am missing something)

It might be possible mathematically speaking :

https://arxiv.org/pdf/2302.06639.pdf

Technologically speaking....

We don't have the hardware (arithmetic circuits) available for "126 133 Cat Qubits"  

I'm afraid this is the whole point where all that cryptography works. If you would be able to crack it in an easy way - it would be useless.

Maybe you are some kind of mathematical genius and you will discover something new ... But i guess there is a bunch of much smarter people than you trying to resolve such problems and since larger puzzles are still on their places they didn't invented anything new.

Agreed, with current tools it's the same as before, extremely difficult to solve the DLP, but one has to penetrate deep into the unknown territories of math and elliptic curves, then you will realize everything is in the group order N, for each curve you'd need to find the weaknesses of N instead of G, or P.

---

Just to show one example, take this key  :
When you first look at it, what do you think would happen if you divide it by 2? Normally you'd say a key with 31 leading zeros. But in reality the result mod n is :
Can you see the difference? There are also other hidden properties, keys etc.
One thing you should think about, is there a way to reduce a number to a perfect composite number and then easily dividing that composite number to reach a range close to 2^65? I believe with a certain subtraction tricks, we can do that, I have done it, but I know the key so it doesn't count, I want to know how to operate with 2 unknown points without knowing the distance between them, whether or not we can reach a composite point as a result of either subtraction and or division.  Like : 59, if we know the range, we could subtract it from 100 to have 41, now all we need is to subtract 9 from 41 to get to 32, and now we can safely divide 32 by 2 a few times to reach 8, where 8 is our desired small range where we can brute force under an hour. The question is, how can we determine that 9 is the right key to reach 32? By operating with scalar mod n of course, first we study and learn then we go for our targets in points.

^^^^^ This is the best and logical answer on this forum ^^^^^^

Most people here just wasting their time trying to solve things that are unsolvable with current hardware (at least hardware available to them).

Even using blind random cracking - realistically it's not gonna be solved in any sane amount of time.

If you think realistically there are at least 10,000 programmers trying to solve the Puzzle 66 at the same time.
The result is visible on the blockchain:
https://www.blockchain.com/explorer/addresses/btc/13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so
They are helpless for now to solve any Puzzle from 66 and above  that does not have a Public Key displayed.
And if they have,  everything above 130 it is simply impossible to solve without huge investments that do not pay off.
So it doesn't really matter here if you know how to code or not. We are all equal in the face of an unsolvable problem.



Don't try to do that on shared services. Even if you have a large load on dedicated servers,  it can happen that you get banned from the same.

---

Anyone knows anything with more fire power than sage cell or google colab etc? I'm running some scripts on them but they can't handle the load, I'm trying to find lambda and beta for different curve parameters, mapping points from secp256k1 to a 128 bit curve to see if it can be done.  
I was thinking, why there is no such infrastructure like sage cell, or Gcolab etc already available for blockchain/Bitcoin developers to use?
Should we all appeal to our beloved dragon to sponsor something like that?  I think if we all collectively ask nicely he will make it happen, right? 😉

---

[Digaran's note, consecutive posts merged due to another post being removed from between my posts.] 😉

Ok.

I'm working on Kangaroo Twimi algorithm on  hash160.
I don't know if it will work, but this is an idea.
It uses two EC_POINT objects (K and W) and iteratively moves them around the elliptic curve by adding random steps until they land on the same point.
When the Kangaroo and Wallaby points collide, the algorithm returns the discrete logarithm k.

rest is similiar as Bytea HASH160 Search from here :
https://bitcointalksearch.org/topic/m.63029958

100% OpenSSL code...

sincerely i have not investigated much in this technique, due to lack of time.
I only know that dividing by 5 with this technique, you will not worry about floating numbers.
I have applied the technique in 2 rounds and everything seems to be on the right track.
honestly do not know how many rounds are possible, but in my opinion it is a good idea.

we obtain.
target=1185429467683753
  R=      545429467683753

I'm not talking about missing characters or puzzle 66, I'm talking about a way to determine last characters of a private key by working with points.

There is no magical aura, and there is no natural behaviour, everything depends on group order, working with points without working on scalar is pointless, in reality we don't need to work with points alone, but since we don't know the private key we work with points.

E.g, if you divide 16577/7 = 2368.142857, divide 16477/7 =
2353.857143, now dividing 16576/7 = 2368, now all we need to do is finding what key results in 0.142857 and 0.85143 when divided, and by what number. After that having all keys between 2353 and 2368 saved for comparing is easy.  This is just an example.

These are natural behaviors when you're working on a curve over a finite field. You need to study them more (properties of curves over prime fields, pairings, embedding degree, etc) in order to avoid attributing a magical aura to every result that pops out.

@digaran: the question unfortunately is still unanswered. Can you point us to your studies, please?

To demonstrate to you that even 10 is not a problem.
The problem is that we are not dealing here with 2, 6, 8 or 10 missing characters...
But with 18 specifically for Puzzle 66.....
It is useless, whatever method you use.

Why are you brute forcing WIF? Don't you know going beyond public key generation is wasting time if you don't have enough hardware? It would be nice if you could write a script which could with 100% validity tell you the last 2 characters of a private key by operating with points.

I can find them when I know both keys, or when I only know the distance between 2 points, it also doesn't matter what the distance is, that's why working with all hexadecimal values is important to find out and study the behaviour of each character. After preliminary test, God willing I will post my method if I think it doesn't break the EC.  But funny thing is most of the things I post (ECC math related) I truly believe they "have" the potential but I just post them to see maybe an expert can get an idea out of it. Apparently I'm delusional until I'm not. By then it'd be too late to pay attention.