Bitcoin puzzle transaction ~32 BTC prize to who solves it

[al3xcjc]

I wrote a simple script for solving puzzle 66: https://github.com/allinbit/btc_puzzle

If it could be ported to gpu then it would be faster but I don't know anything about it.

Your code uses scalar multiplication for all the keys, making it even slower.
The code is interesting, although for the processor it can take a long time, it needs to be on the video card itself.

No, the code doesn't directly involve scalar multiplication for generating private keys. Instead, it generates private keys by randomly shuffling bits to create a binary string, which is then converted to a hexadecimal representation. The generated private key is then used to create a public key and subsequently generate a Bitcoin address.

In the context of Bitcoin, scalar multiplication is a fundamental operation used in elliptic curve cryptography (ECC). Scalar multiplication is used to derive a public key from a private key, and it's a core operation in generating Bitcoin addresses. However, the code doesn't explicitly perform scalar multiplication. It generates private keys in a way that doesn't directly reflect the typical method used in Bitcoin.

Here's how scalar multiplication is generally used in Bitcoin address generation:

A private key is randomly generated using a secure random number generator.
Scalar multiplication is performed on the elliptic curve with the private key and a predefined generator point to compute the corresponding public key point.
The x-coordinate of the resulting public key point is used to create a Bitcoin address.
In the code, the process of generating private keys is unrelated to scalar multiplication. Instead, it generates private keys through a random bit shuffling approach, converts them to hexadecimal format, and then processes them to create public keys and Bitcoin addresses.

[1714872542]

1714872542

[1714872542]

1714872542

[1714872542]

1714872542

[1714872542]

1714872542

[1714872542]

1714872542

[albert0bsd]

My only sugestion for you get more speed is to work with some precalculated table of publickeys for some specific number of bits...

Lets to said that we want to process subranges of of 3 o 4 bytes [24 or 32 bits] (Less significative bits)
if the target puzzle is 66 bits you will have some main range of [42 or 34 bits] (Most significative bits)

Code:

[Main range 42 or 34 bits][Subrange 24 or 32 bits]

if you want to have Ratio from 40% to 60% that means you only need 33 +/6 bits in "1"

So that +/- 6 variations of bits maybe only need to checked in each subrange... or only +/- 4 bits in the subrange and +/- 2 bits in the main rarange

Example for a Subrange of 3 Bytes [24 bits], half is 12 bits +/- 4 will be checked all those with from 8 bits to 16 bits in "1"

For this example we need to calcualte all the publickeys under 24 bits that its privatekeys have only bewteen 8 to 16 bits in "1",
2^24 are 16777216 keys, you will only need to stetore (Surprise) 94 % of them in memory

Once that you already have that table in memory you only need is to Select a KEY from the Main range and performe a Point Addition againts all the previous table

That should gain some speed...

[albert0bsd]

The generated private key is then used to create a public key and subsequently generate a Bitcoin address.

That is exactly what scalar multiplication means...

[james5000]

I wrote a simple script for solving puzzle 66: https://github.com/allinbit/btc_puzzle

If it could be ported to gpu then it would be faster but I don't know anything about it.

one more problem in this method is the keys repeat   

[citb0in]

you should get rid of the bad idea that a ratio of 40/60 or vice-versa of zeros and ones exists. That is simply absurd. Pure waste of time. With the method mentioned here you would never have discovered the puzzles 11,12,13,14,17,18,19,24,25,31,48,49,51,56,57.

[james5000]

you should get rid of the bad idea that a ratio of 40/60 or vice-versa of zeros and ones exists. That is simply absurd. Pure waste of time. With the method mentioned here you would never have discovered the puzzles 11,12,13,14,17,18,19,24,25,31,48,49,51,56,57.

please what method do you suggest then? I observed many calculating, looking for errors etc... one or two try to improve, after all I'm not quite right, but it is something new and clearly an advantage in the search.

[citb0in]

you should get rid of the bad idea that a ratio of 40/60 or vice-versa of zeros and ones exists. That is simply absurd. Pure waste of time. With the method mentioned here you would never have discovered the puzzles 11,12,13,14,17,18,19,24,25,31,48,49,51,56,57.

please what method do you suggest then? I observed many calculating, looking for errors etc... one or two try to improve, after all I'm not quite right, but it is something new and clearly an advantage in the search.

this method is just as useless as the previous proposed ones. It's all right for ideas to come in, but you should get caught up in it and chase after something that makes no sense in this context. It is exactly the same as the clumsy attempt to guess the position of the searched key within the searched bit range. It is simply impossible, because there are always outliers (as the past and thus our existing knowledge proves). People try to create a pattern, in the process they get lost in the chaos

[james5000]

muticore mode added to python code

https://github.com/Jamerson1000/million-python

[elvis13]

james5000
How to run it in Ubuntu?
Write a command.

[delta[trix]]

I have a small curiosity about these occasional small incoming transactions in wallet 66. Could they be some clue about the key's location, or is it just something random?

[Minase]

Not at all, just dust or some people sending small amounts.
Have looked at the past addresses and no such hint was given

[delta[trix]]

Not at all, just dust or some people sending small amounts.
Have looked at the past addresses and no such hint was given

But it seems to be something automated by the puzzle's creator itself, I looked at some transactions.

[citb0in]

But it seems to be something automated by the puzzle's creator itself, I looked at some transactions.

Be more specific, please

[james5000]

To mathematicians, there is a way to divide one point by another point on the elliptic curve.

[delta[trix]]

But it seems to be something automated by the puzzle's creator itself, I looked at some transactions.

Be more specific, please

If you look at the transactions in wallet 66, and a few others, you will see that it appears to be something automated, sending small transactions with numbers that I believe might provide some clues in decimal/hexadecimal or binary code as to where the private key could be located. However, this is just an assumption.

[citb0in]

...you will see that it appears to be something automated, sending small transactions with numbers that I believe...

what makes you think that it's automated and not manually entered as a transaction?
what do you mean by 'small transactions with numbers' in detail?

[digaran]

But it seems to be something automated by the puzzle's creator itself, I looked at some transactions.

Be more specific, please

If you look at the transactions in wallet 66, and a few others, you will see that it appears to be something automated, sending small transactions with numbers that I believe might provide some clues in decimal/hexadecimal or binary code as to where the private key could be located. However, this is just an assumption.

If you mean numbers 66 and 99, they are mirrors of each other, also converting 66 and 99 to hex twice you will get 2a for 66 and 3f for 99. Converting 66 to decimal is 102, and 99 is 153.

Note that 6 and 9 are represented by each other in hex format, since there are only 6 alphabet letters, the remaining 9 digits have no alphabet representatives. So here is how it works :
0= f
1= e
2= d
3= c
4= b
5= a
6= 9
7= 8
8= 7
9= 6
It's a world of wonders this hexadecimal world!

To mathematicians, there is a way to divide one point by another point on the elliptic curve.

Are you asking or telling? Of course there is a way, look at my personal text, e.g. dividing n by 6 will give you this :

Code:

2aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa74727a26728c1ab49ff8651778090ae0

You can multiply any point by above key, and it will divide your key by 6 if it's divisible by 6 you will get a correct answer.

Now if you divide a point by the key above, you will actually be multiplying your point by 6.

Now if you divide a point by 4 and multiply the result by 2 you should naturally get half of your original point, if your point is divisible by 4 then your results are correct, otherwise you will have a much much bigger point than your original point.

Essentially dividing a point by a number other than 2 will get you no where close if your key is not divisible by that number, you can try by dividing a number by 3, 4, 5, etc and if the fraction is something other than .5, then the result of point division will not be any where close, however as long as the fraction is .5, then you can always add n/your divisor to the result to get the correct result.


For example, divide 23 by 2, you will get -n/2-12 as a result, and if you add n/2 to your result, you'll have -12.

101 on how to break cryptography by ~dig.😉

[james5000]

But it seems to be something automated by the puzzle's creator itself, I looked at some transactions.

Be more specific, please

If you look at the transactions in wallet 66, and a few others, you will see that it appears to be something automated, sending small transactions with numbers that I believe might provide some clues in decimal/hexadecimal or binary code as to where the private key could be located. However, this is just an assumption.

If you mean numbers 66 and 99, they are mirrors of each other, also converting 66 and 99 to hex twice you will get 2a for 66 and 3f for 99. Converting 66 to decimal is 102, and 99 is 153.

Note that 6 and 9 are represented by each other in hex format, since there are only 6 alphabet letters, the remaining 9 digits have no alphabet representatives. So here is how it works :
0= f
1= e
2= d
3= c
4= b
5= a
6= 9
7= 8
8= 7
9= 6
It's a world of wonders this hexadecimal world!

To mathematicians, there is a way to divide one point by another point on the elliptic curve.

Are you asking or telling? Of course there is a way, look at my personal text, e.g. dividing n by 6 will give you this :

Code:

2aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa74727a26728c1ab49ff8651778090ae0

You can multiply any point by above key, and it will divide your key by 6 if it's divisible by 6 you will get a correct answer.

Now if you divide a point by the key above, you will actually be multiplying your point by 6.

Now if you divide a point by 4 and multiply the result by 2 you should naturally get half of your original point, if your point is divisible by 4 then your results are correct, otherwise you will have a much much bigger point than your original point.

Essentially dividing a point by a number other than 2 will get you no where close if your key is not divisible by that number, you can try by dividing a number by 3, 4, 5, etc and if the fraction is something other than .5, then the result of point division will not be any where close, however as long as the fraction is .5, then you can always add n/your divisor to the result to get the correct result.


For example, divide 23 by 2, you will get -n/2-12 as a result, and if you add n/2 to your result, you'll have -12.

101 on how to break cryptography by ~dig.

for n = fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141

Code:

print(toHex(round(n / 6)))

my result is 2aaaaaaaaaaaaa00000000000000000000000000000000000000000000000000

 

but what I meant is whether there is a way to divide a point on the curve x, y by another point on the curve x, y?

[digaran]

for n = fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141

Code:

print(toHex(round(n / 6)))

my result is 2aaaaaaaaaaaaa00000000000000000000000000000000000000000000000000

 

but what I meant is whether there is a way to divide a point on the curve x, y by another point on the curve x, y?

Your result is not correct because you should do the math mod n to have the correct result.

Anyways, point by point multiplication and division without knowing at least one point's private key is impossible, why else they call it crypto-graphy for?
If it was possible directly, we all could break ECC easily.

Ps, I'm not a mathematician, but I'll find a way to divide point by point or die trying! 🤣

[james5000]

for n = fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141

Code:

print(toHex(round(n / 6)))

my result is 2aaaaaaaaaaaaa00000000000000000000000000000000000000000000000000

 

but what I meant is whether there is a way to divide a point on the curve x, y by another point on the curve x, y?

Your result is not correct because n is not divisible by 5, you should do the math mod n to have the correct result.

Anyways, point by point multiplication and division without knowing at least one point's private key is impossible, why else they call it crypto-graphy for?
If it was possible directly, we all could break ECC easily.

Ps, I'm not a mathematician, but I'll find a way to divide point by point or die trying! 🤣

work with me 🤣🤣