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

Reduced what exactly, addresses? You don't have public key, so reducing whatever you think you reduced is not gonna work. But hey, I wish you are up to something and really hope to find the keys you are looking for.

Dear friend,  based on developer community, we experience, what in developer mind, only they create for that for gpu, rest just see 1 or 2 pages back lot of basic coder still working on python at CPU level, just see their ideas, script in python back in 1 or 2 pages, albertobsd max created ecctools in c,  even he is good coder for gpu too, but not him or other gpu coder able to create basic ecc tools for gpu, don't take much aspectation for gpu coder community, let world run at python and CPU ,

I haven't tested it on 65 because my code is still for the CPU, 65 would take a long time to confirm it works, but on a GPU up to 68 will be possible. 

Well, let's go, in the next post I will explain all the logic, if anyone wants to give support please feel free if it makes sense. 

#66 I mean I am interested in your "software" but I don't see how these numbers are possible with just 300Mk/s even if you reduced 86% of #66
Are you able to test on #65 as I think #30 is a bit small?
The range I am searching which I have confidence in but have not shared is less than that at 1342426695300956160 out of 36893488147419107000 keys but even this is like 20 years with 3x RTX3080s so I don't understand how #66, #67 and #68 can be found in 1 week without pub key, could you share more info?

Just for comparison purposes, I tested it with puzzle 30:

we know the range is 20000000:3fffffff
total of 536,870,911 possible keys

I reduced it to approximately 77,000,000 or -85.66%

based on the same calculations I suppose the 66 is reduced to about 27 trillion keys

My code currently runs on the CPU, but we all know that for the next puzzles it needs to be made to run on the GPU, if anyone with CUDA knowledge is interested in splitting 50/50 we can work together.
I guarantee that with a rate of 300 Mk/s we break the 66, 67 and 68 in one week

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.