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

If you manage to solve puzzles 66, 67 and 68, what guarantees would we have that someone would see your code? If you already have the code, why do you want sponsorship? Personally, if I invest in a project, I do it on my own. If I have positive results, I will take my profit from there. So, I just wish you luck and that's it. I can't trust you and I think that most of the members on this forum would have no reason to trust you.

unfortunately by posting the code people with more knowledge will gain an advantage, so first I'll break down the 66, 67 and 68 puzzle before explaining how it works.

Cool project, keeping an eye on this one!
Btw what project? 🤣 first show us what you got, then we'll talk about support, in case you haven't noticed, people are here to find money not give it away.😉

I'm developing brute force software following a slightly more coherent logic, I'll post the code soon. 

support the project: 
1JamesJ2H2myei94NswaBATqEsBhATENSU

Without source code, there is no trust in your application. It is not known what kind of application you are distributing.

An update of my "solve66" tool for puzzle #66 is available!

If you cannot understand that, you do not know about Maths, if you think that I am somehow lost in what I speak and you think the solution is in the same ECC, I will shut up, but surely you would read on me later when I publish the PK of the puzzle.
Meanwhile, suppose you are right

Ok, how do you know the result is -800? And whatever the result, it's not invalid, but what if the key is 1890? You'd be searching from 700 to 800 in hopes of finding you imaginary -800, while the actual result is 110, far away from your searching range. I guess you haven't figured out a way to  validate whether your target is greater than 1500 or not, once you figure that out, you can base your future calculations on the fact that your target is greater or smaller than 1500.

E.g. if the key is 1650, multiply by 3 to get 4950, divide by 2 to get 2475, subtract your target from 2475 to get 825, which is half of your target.
Or just subtract 1 divide by 2, to name a few methods.



So the expert mathematician would use Y and then adds 1? I wonder about the logic in doing that, he might be crazy if he thinks that he can use a different algorithm to find secp256k1 keys faster. Are you sure this "good mathematician" knows about mod n in secp256k1 curve?
Anyways, when searching for unkown keys, doesn't matter if the keys are greater than n or not, because you don't have the pk to check, though if we use  standard implementation then we can be sure all keys are valid since they are all calculated mod n, whatever you do, public keys are always mod p, otherwise you get invalid public keys.

When we are talking about bitcoin's curve, you can NOT use different values expecting the results to work on bitcoin keys.

no bro, I don't move the key without differences, as if I were using simple additions and subtractions, I reduce many bits (the beautiful thing about maths, things happen as if it were magic), my problem is that my algorithm is not perfect (yet, or so I want to believe) I have not found a way to reduce more without the need to create thousands of keys, and also that I was born in a poor country and my resources to scan that bit limit me. therefore it is not like you say that there is no difference, there are differences, only you do not know it.

You are making yourself a professional user, even though no one of us are.

Even if you divide, multiply, add, subtract a key million of times to get back to the targeted key, you'll not find an single answer for the new values. Because they will still be represented as 255 bits, so the complexity did not changed at all. You just moved the targeted key from A to B, with absolutely the same complexity.

I recommend the python module ICE secp256k1 has no N limits, it will give you the exact results even when these results are negative or over the imposed limit. An example, the Bitcoin module, gives erroneous results when it comes to negative values ​​or above the imposed limit. Let's remember that numbers are infinite and that a program only recognizes from 1-10, for example, does not mean that you cannot add 4+7 or that 11 does not exist.

bro honestly you are not good for maths, sorry about that, you do not think with mathematics you talk about invalid key as if the discrete logarithm and its request depended on the parameters that were imposed on the curve as a standard, the goal is to get any of pk, you can not only find a key by subtracting and dividing.

X=115792089237316195423570985008687907852837564279074904382605163141518161494337
Y=115792089237316195423570985008687907852837564279074904382605163141518161494336
If X represents a zero in the calculations of your library, a good mathematician would logically use Y and add 1 to the result.

Like

(Y-pk)+1

The goal is to find some key, it doesn't matter if it is invalid for the bitcoin standard, because knowing the pk of any of them will know the original pk you are looking for. If you limit your mind thinking about the parameters that satoshi imposed, you will not achieve

example: suppose you want to find an unknown key that we call Z Z= 1200 if we know that its range is between 1000:2000 if we subtract 2000 we will get -800 wow yes, an invalid key?? should i care The answer is no, because if we find the value -800, even if it represents an invalid key, we will know that the original pk is 1200.

if you want to find puzzle #66 in slow mode. I leave the code here.

When I say misinformation, now I know you are misinformed, this key :
is an invalid key, but mod n it is the same as G or 0x1. You see, whatever you add to n, it's like adding to zero, if you add 5 to n, what you get is just 5. So no, they are not all the same, if you convert the key above to WIF no wallet will accept it because it has a wrong format. All pk are mod n.

I used 0-10 as an example but they are really:0-115792089237316195423570985008687907852837564279074904382605163141518161494337


[/code]

I used 0-10 as an example but they are really:115792089237316195423570985008687907852837564279074904382605163141518161494337

How exactly did you come up with those numbers? Since when 3=7?
If you don't know how it works don't spread misinformation!

This is -n private key of 0x7,
And this is +n private key of 0x7,
Now where is 3 here?
If you divide 7 by 2, you will have -n of 0x3, which you will obtain by subtracting 4 from N =

One useful trick is dividing an odd key without having any remainder, that is dividing by 2 then adding n/2, or just subtract 1 from pk then divide by 2.

The only advantage we have regarding the range of keys is that we know the exact range for each one of them yet we can't do anything about it.

Do you have any tricks to reduce the range bit by bit? Well there is one, subtraction is the key, but you'd need to know what to subtract from your key. 😉

I'm sorry, but if pk = 3; then pk -  10 =/= 7, pk - 10 = -7, very different.

for new users!
 Imagine the elliptic curve as a constant repetition of patterns where the negative or positive sign does not matter. example in a curve composed of 0-10 (in reality it is a huge number) the private key of 1 equals ...-19,-11,-9,-1, 1,9, 11, 19... to infinity in both directions.
 Any of those combinations work for all the others.
That is to say, a public key has copies of itself represented with different numbers but on paper they are the same and if you have the private key of 1, you have pk 9, pk 2 you have pk 8....

public key = pub
private key=pk

so if we have
pk=3
we apply

pk-10= 7
3=7 for the example, both pk's are mirrors.

Having said this, we understand that there is no way to know the range of a pk, if it is a pk - or positive. however there are mathematical tricks to reduce the size of these pk until finding a reasonable range to apply brute force.

A new version of my "solve66" tool for puzzle #66 is available!