Bitcoin puzzle transaction ~32 BTC prize to who solves it

[digaran]

basically by changing Gx, Gy for example by pubkey of pk #1000
the sequence of the curve would be 1000,2000,3000,4000...
and you will wonder what happens with 1001,1002,1003...1999.
for that you subtract 1, 1000 times from the target and store it in the database.

If you search for 10924, and subtract 1000 times 1, the database would look like this: 10923,10922,10921...10000...9999,9998.
therefore you would find the pk 10000 in 10 steps, and you would know that your target is in the range 10000-10999

So the database is our actual target and some of it's offsets and we select a known key and add it as target so the script adds or subtracts from our known key until it lands on any one of the keys stored in database?

Is data base file loaded into the RAM? How many keys per second can we generate and compare at the same time?
This looks good as an idea, but in reality the performance is not what we need. Thanks for explanation.

it also feels like why am I sharing my hard work with those who have such negative thoughts about me,

Some say football some say soccer!  Why is this hard work of yours in a downloadable file with closed source binaries?

Share this hard work which seems to be magically correct and accurate by posting the ranges as a text file. Then we might discuss about you being a scammer or dishonest or both after that.

[1714886753]

1714886753

[1714886753]

1714886753

[1714886753]

1714886753

[1714886753]

1714886753

[_Counselor]

increase the search speed of the Pubkeys, dividing the search range.

First of all, let me make it clear that this script is slow and basic, I did it like this in order to explain the range division method.

If you want to apply it quickly, modify keyhunt or other c++ code before compiling to make it work with this method.

The method consists in changing the parameters of the curve by x,y of a higher point (for the script I used pk#100).
by default the curve uses pubkey #1
what works in sequence 1,2,3,4....
pubkey #100
which works in sequence 100,200,300,400....

if we want to find pk# 3922
in a range of 2000:6000
in the traditional way we would need to advance +1900 pubkeys
In this method we will only need 19 pubkeys (1900/100).

the database is done by subtracting 1 consecutively from the target pubkey (in my case I need to subtract( 1), 100 times because I chose pubkey pk# 100 as divisor.

The trick is in your ability to use fast databases, the more pubkey you store in the database, the higher the divisor will be, therefore the search range is smaller.

I currently don't have what it takes to code in C++ using the quick search methods, my resources are limited to the basics.
I currently don't have an up-to-date pc to do the relevant tests (the disadvantages of the third world).

However, later I will share faster methods, ECC tricks.

So basically, you talk about stride option in already existing tools.

[GR Sasa]

I actually believe and like zahid888 to be an honest man.

especially when he almost cracked #64 year ago, he almost landed on the correct key, but didn't managed to get it.

So, zahid you can be the next one who gets 66!

Edit: /quote I only needed to scan 588 more ranges to achieve 100% completion of scanning.

Do you mean that after scanning those ranged, according to your calculation the #66 key should be guaranteed found?

[zahid888]

What senseless thing have I said? What do you think? Has puzzle 66 only been searched by me or others just recently? (after the solution of puzzle 64)?.. ohh come on, If I, alone, can manage to scan 1.5% of the keys, how can you ignore the fact that there are millions of hunters here who are much more powerful than me, who might not even peek into threads like these? I personally know some individuals like that, who even shared scanned ranges with me during puzzle 64, which later turned out to be completely authentic.

Anyway, whom am I sharing all these things with? someone who starts his journey with collecting the drops from the faucet and manages only few hashes to mine with USB. My concern with the old folks here is about those developers, when some people used to click on free faucets every hour to gather small amounts, these developers had already created auto bots for these task. When people were collecting small amounts through USB mining, these developers and miners successfully solved solo blocks. I'm talking about such unique developers in this crowd, not finger-waggers. Anyway, no more arguments. I am indifferent to anyone who may have been hurt by my words. Thanks @GR Sasa for your best wishesh.
I know that people won't scan such large ranges; I don't care. My scanning is ongoing between these ranges. However, if someone does scan, please inform me about the proof of work so that there's no overlap in these ranges. Or perhaps I should consider making the repository private🤔

I actually believe and like zahid888 to be an honest man.

especially when he almost cracked #64 year ago, he almost landed on the correct key, but didn't managed to get it.

So, zahid you can be the next one who gets 66!

Edit: /quote I only needed to scan 588 more ranges to achieve 100% completion of scanning.

Do you mean that after scanning those ranged, according to your calculation the #66 key should be guaranteed found?

As I mentioned before, only one file has put me in a 50-50 situation

[citb0in]

in the mean time you could have posted the scanned ranges here into this thread in case you really want to support the community

[mcdouglasx]

increase the search speed of the Pubkeys, dividing the search range.

First of all, let me make it clear that this script is slow and basic, I did it like this in order to explain the range division method.

If you want to apply it quickly, modify keyhunt or other c++ code before compiling to make it work with this method.

The method consists in changing the parameters of the curve by x,y of a higher point (for the script I used pk#100).
by default the curve uses pubkey #1
what works in sequence 1,2,3,4....
pubkey #100
which works in sequence 100,200,300,400....

if we want to find pk# 3922
in a range of 2000:6000
in the traditional way we would need to advance +1900 pubkeys
In this method we will only need 19 pubkeys (1900/100).

the database is done by subtracting 1 consecutively from the target pubkey (in my case I need to subtract( 1), 100 times because I chose pubkey pk# 100 as divisor.

The trick is in your ability to use fast databases, the more pubkey you store in the database, the higher the divisor will be, therefore the search range is smaller.

I currently don't have what it takes to code in C++ using the quick search methods, my resources are limited to the basics.
I currently don't have an up-to-date pc to do the relevant tests (the disadvantages of the third world).

However, later I will share faster methods, ECC tricks.

So basically, you talk about stride option in already existing tools.

Skipping the keys or searching n times is not the same as changing the curve.

[digaran]

Some elliptic curve magic ahead!

Public key for 2^256 in secp256k1 :

Code:

03dd3625faef5ba06074669716bbd3788d89bdde815959968092f76cc4eb9a9787

Private key :

Code:

000000000000000000000000000000014551231950b75fc4402da1732fc9bebf

Public key divided by 2 :

Code:

02b23790a42be63e1b251ad6c94fdef07271ec0aada31db6c3e8bd32043f8be384

Private key : 2^255

Code:

8000000000000000000000000000000000000000000000000000000000000000

Now we add an even key to our 2^256 :
Target  Pub

Code:

034a4a6dc97ac7c8b8ad795dbebcb9dcff7290b68a5ef74e56ab5edde01bced775

Target  Prv

Code:

0000000000000000000000000000000000000000000000000000000000008000

Result : pub

Code:

02c028224b2c45bd797143e8f32f025e24601ed85f27ef310d7d55020a192ddba5

Prv

Code:

000000000000000000000000000000014551231950b75fc4402da1732fca3ebf

Divide by 2 , result :

Code:

0216ca7e1edb137684b4aa8a41fd0f8a89dcb773b9db807a9f3f864de2161735ff

Now subtract pub 2^255 from above, result :

Code:

03111d6a45ac1fb90508907a7abcd6877649df662f3b3e2741302df6f78416824a

Prv, also real half of our original target :

Code:

03111d6a45ac1fb90508907a7abcd6877649df662f3b3e2741302df6f78416824a ,  0000000000000000000000000000000000000000000000000000000000004000

I just enjoy making a simple division difficult and twisted! 🤣, now chop chop start your brain's engine and do some calculation, large fractions could be solved by accounting for the above results, not telling you how.

Dive deep and let your brain solve it.😉

[citb0in]

Some elliptic curve magic ahead!
...
I just enjoy making a simple division difficult and twisted! 🤣, now chop chop start your brain's engine and do some calculation, large fractions could be solved by accounting for the above results, not telling you how.

Dive deep and let your brain solve it.😉

Anyone here knows how to divide a point by 3, 4, 5, 6, 7, 8, 9 and 10 and get a correct result?

Give me a few minutes, you will be amazed, I need to prepare the sample keys on laptop. Stay tuned.😉
Here you go
...

Ps, I will not study to figure out how to divide by 10m and still have a correct result, if I do, I will not share it, that'd be ECC bent and broken totally.

...
Never mind all the above, I have something to twist your minds, take the following key and double, divide, do many other things with it to get really confused about how EC works. 😂

Introducing to you 2^256 of secp256k1

you constantly act as if you are a genius who broke SECP256K1 but doesn't want to share his genius findings. On the other hand, you struggle in vain and miserably like many others to solve a puzzle. Find the mistake.

[_Counselor]

So basically, you talk about stride option in already existing tools.

Skipping the keys or searching n times is not the same as changing the curve.

Then explain the difference please.

I looked at the piece of code you wrote above, looks like it works like BSGS algorithm, with a very naive implementation.
The first thing that you should do, it is remove curve multiplication at all and replace it with subtraction.
I'm talking about this part: PublicKey = getPublicKey(Seq_Bytes)
Every call of "getPublicKey" is very expensive, no matter which point you're uses as "G".
Just take another point (G*100) as a stride and subtract it from current point on each step. Than you will get 6000, 5900, 5800, 5700 and so on with a great speed improvement. Trying to do the same by replacing the generator point is pretty bad practice, despite the fact that from some side it will certainly work.

[digaran]

you struggle in vain and miserably like many others to solve a puzzle. Find the mistake.

Don't you struggle like all other intelligent individuals hunting this puzzle? If not then that's understandable, no pressure.  Around these woods men break under pressure, previous pages are my witness. You might break your nails by passing by.

who broke SECP256K1

That's a promise, God willing I'd either deliver on that or die trying.😂

but doesn't want to share his genius findings.

Lol, what genius I use calculator to subtract 176 from 239, not lying.

Anyways, do you have something useful that can help solving a puzzle? Stupid question, of course you don't.😘

[Denis_Hitov]

Some elliptic curve magic ahead!

Public key for 2^256 in secp256k1 :

Code:

03dd3625faef5ba06074669716bbd3788d89bdde815959968092f76cc4eb9a9787

Private key :

Code:

000000000000000000000000000000014551231950b75fc4402da1732fc9bebf

Public key divided by 2 :

Code:

02b23790a42be63e1b251ad6c94fdef07271ec0aada31db6c3e8bd32043f8be384

Private key : 2^255

Code:

8000000000000000000000000000000000000000000000000000000000000000

Now we add an even key to our 2^256 :
Target  Pub

Code:

034a4a6dc97ac7c8b8ad795dbebcb9dcff7290b68a5ef74e56ab5edde01bced775

Target  Prv

Code:

0000000000000000000000000000000000000000000000000000000000008000

Result : pub

Code:

02c028224b2c45bd797143e8f32f025e24601ed85f27ef310d7d55020a192ddba5

Prv

Code:

000000000000000000000000000000014551231950b75fc4402da1732fca3ebf

Divide by 2 , result :

Code:

0216ca7e1edb137684b4aa8a41fd0f8a89dcb773b9db807a9f3f864de2161735ff

Now subtract pub 2^255 from above, result :

Code:

03111d6a45ac1fb90508907a7abcd6877649df662f3b3e2741302df6f78416824a

Prv, also real half of our original target :

Code:

03111d6a45ac1fb90508907a7abcd6877649df662f3b3e2741302df6f78416824a ,  0000000000000000000000000000000000000000000000000000000000004000

I just enjoy making a simple division difficult and twisted! 🤣, now chop chop start your brain's engine and do some calculation, large fractions could be solved by accounting for the above results, not telling you how.

Dive deep and let your brain solve it.😉

It is a pity that such an operation will not work with an odd key))

[digaran]

It is a pity that such an operation will not work with an odd key))

Sure it will, if you add an odd key to another odd key ( our 2^256 key is odd ) you'll get an even key and all you have to do is to subtract the following key from the result :

Code:

a2a8918ca85bafe22016d0b997e4df5f

But why bother if you could add or subtract 1G from your odd key and divide it without having to do what I said.

You can always divide an odd key, if by 2, you'd have to add n/2 to the result, if by 3, adding n/3 etc to get your actual and correct result.

[lordfrs]

It is a pity that such an operation will not work with an odd key))

Sure it will, if you add an odd key to another odd key ( our 2^256 key is odd ) you'll get an even key and all you have to do is to subtract the following key from the result :

Code:

a2a8918ca85bafe22016d0b997e4df5f

But why bother if you could add or subtract 1G from your odd key and divide it without having to do what I said.

You can always divide an odd key, if by 2, you'd have to add n/2 to the result, if by 3, adding n/3 etc to get your actual and correct result.

sorry my english is not good, i'm trying to understand by translating with translate, this gives me different sentences, so can you write the python code for the division you said.

[digaran]

It is a pity that such an operation will not work with an odd key))

Sure it will, if you add an odd key to another odd key ( our 2^256 key is odd ) you'll get an even key and all you have to do is to subtract the following key from the result :

Code:

a2a8918ca85bafe22016d0b997e4df5f

But why bother if you could add or subtract 1G from your odd key and divide it without having to do what I said.

You can always divide an odd key, if by 2, you'd have to add n/2 to the result, if by 3, adding n/3 etc to get your actual and correct result.

sorry my english is not good, i'm trying to understand by translating with translate, this gives me different sentences, so can you write the python code for the division you said.

I'm not a coder but here is the idea. Translate the following.

11/3 =

Code:

3.6666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666667

Secp256k1 representation of the fraction above :

Code:

55555555555555555555555555555554e8e4f44ce51835693ff0ca2ef01215c0

11 decimal 0xb/3 =

Code:

55555555555555555555555555555554e8e4f44ce51835693ff0ca2ef01215c4

Subtract both above, result is 0x4.

Now the twisted division I talked about, simple :

Target 7, is odd, we add 3 to get 10, divide 10 by 2 = 5, and if we subtract half of 3 = 1.5 from half of 7 = 3.5 we get 2, now we subtract 2 from 5 to get the real half of 7 in secp256k1.

[artistk]

is there any C++ open source script ( CPU or GPU ) to join you in this journey ? Thank you in advance

[albert0bsd]

is there any C++ open source script ( CPU or GPU ) to join you in this journey ? Thank you in advance

for CPU you can try my keyhunt program available on github of course it is open source.

https://github.com/albertobsd/keyhunt

If you have any questions or feedback, don't hesitate to reach out.

Regards

[mcdouglasx]

So basically, you talk about stride option in already existing tools.

Skipping the keys or searching n times is not the same as changing the curve.

Then explain the difference please.

I looked at the piece of code you wrote above, looks like it works like BSGS algorithm, with a very naive implementation.
The first thing that you should do, it is remove curve multiplication at all and replace it with subtraction.
I'm talking about this part: PublicKey = getPublicKey(Seq_Bytes)
Every call of "getPublicKey" is very expensive, no matter which point you're uses as "G".
Just take another point (G*100) as a stride and subtract it from current point on each step. Than you will get 6000, 5900, 5800, 5700 and so on with a great speed improvement. Trying to do the same by replacing the generator point is pretty bad practice, despite the fact that from some side it will certainly work.

I made the code basic to express the idea of why changing G+ database is a fast way to scan (it wasn't intended to be fast just forget about it and focus on G, the database, and the range division), if you jump keys you miss the speed of scalar multiplication.
for that reason the random in the current tools is R+incremental (to take advantage of scalar multiplication).

example :
pk=148557384957383058
and your database capacity is 1000000.
changing G to 1000000
you would only have to search
148557384957
while the common is
148557384957383058.
and as I said when posting the script, everything is in the fluidity with which we can scan the database quickly.

[DegenHero]

is there any C++ open source script ( CPU or GPU ) to join you in this journey ? Thank you in advance

for CPU you can try my keyhunt program available on github of course it is open source.

https://github.com/albertobsd/keyhunt

If you have any questions or feedback, don't hesitate to reach out.

Regards

I am not coder, so don't know how to build.
Could you please build this for non-coders?
Also how fast is this using CPU?

Thanks

[albert0bsd]

I am not coder, so don't know how to build.
Could you please build this for non-coders?
Also how fast is this using CPU?

Thanks

Hi you don't need to be a coder to use the program just follow the instrucctios to compile it under any WSL enviroment.

For CPU my program is one of the fastest available today, Address/rmd160 mode can reach some Millions keys per second on a laptop, up to 100 Millions keys per second on a High end CPU.

For Mode BSGS that use RAM to store precalcualted data you can reach some Petakeys/s scanning for a single publickey.

Regards!

[citb0in]

For Mode BSGS that use RAM to store precalcualted data you can reach some Petakeys/s scanning for a single publickey.

... though BSGS speed is not comparable to the standard scanning technique. Just for the sake of correctness, you cannot compare apple speed with pie speed displayed by those tools. I only want to mention this so that no false illusion is created in the reader and he might think that BSGS is the means of choice and thus the holy grail.