== Bitcoin challenge transaction: ~1000 BTC total bounty to solvers! ==UPDATED==

[fecell]

found a way to reduce 1/6 total range.
python proto give a nice result for all known PK.

hope CUDA version will be a nice with 66..70 profit.

good luck!

[digaran]

found a way to reduce 1/6 total range.
python proto give a nice result for all known PK.

hope CUDA version will be a nice with 66..70 profit.

good luck!

Hi, who are you talking to, do you need someone help you cross the street? 😂
Since you cared enough to share your achievement verbally, could you be kind and tell us how did you managed  to reduce the range for an unknown key? You know sharing is caring right? But if you found a way to do range reduction for public keys, let us know about it, we might find some useful hints.😉

[albert0bsd]

found a way to reduce 1/6 total range.
python proto give a nice result for all known PK.

That is only passible when you know the private key, but WITHOUT the private key all those reductions aren't possible.

[fecell]

found a way to reduce 1/6 total range.
python proto give a nice result for all known PK.

That is only passible when you know the private key, but WITHOUT the private key all those reductions aren't possible.

it's wrong.
for example 7-bit key can be found at 4 step (direct search from 2^6 to (2^7)-1 will find only at step 12, reduce 3 times).
1001001 1
1001010 2
1001011 3
1001100 4
result: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7hDgvu64y

17-bit at 17318 (direct at 30287 step, reduce ~2 times)
10111011001001111 17318
result: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFiHkRsp99uC

22-bit (direct 910351)
1011011110010000001111 607024
result: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rP9Ja2dhtxoh

and so on... tested with known PK.
but still at researching.
8-bit key skiped by this method, therefore, unfortunately, there is a possibility of missing the desired value.

i was wrong about 1/6 (error with calculation was), anyway reduce are possible, but with chance to skip needed value =(
and we must take into account that by skipping some values ​​when generating numbers, we save time on generating the address and checking it with the required one (speedup).

[albert0bsd]

unfortunately, there is a possibility of missing the desired value.

That said all no? The possibility of missing the target value with bigger keys is great.

[fecell]

unfortunately, there is a possibility of missing the desired value.

That said all no? The possibility of missing the target value with bigger keys is great.

many test was. real steps to find was different.
22-bit at this test is:
1011011110010000001111 777854
but anyway its better vs range(2**21, 2**22-1)

[digaran]

unfortunately, there is a possibility of missing the desired value.

That said all no? The possibility of missing the target value with bigger keys is great.

many test was. real steps to find was different.
22-bit at this test is:
1011011110010000001111 777854
but anyway its better vs range(2**21, 2**22-1)

Lets say this is a private key, 3857991093436143 and you only know it starts with 3, that's all. Now that you have no other knowledge about the key other than what it starts with, can you give us a %100 working method to reduce the size of that key and still finding it successfully?

If you can do that, congratulations because you just partially broke elliptic curve.

[ElDalmatino]

Hmm why is the keyspace shown different here on the first site, this site https://privatekeys.pw/puzzles/bitcoin-puzzle-tx and this site https://privatekeyfinder.io/bitcoin-puzzle/.

  end will be, the puzzles are in the wrong keyspace, thats why nobody can find anything. Look at 66 for example, different keyranges.

[digaran]

Start range :
0000000000000000000000000000000000000000000000020000000000000000
End range:
0000000000000000000000000000000000000000000000040000000000000000  -1

Both of them show the range correctly, where do you see anything wrong? Anyways the correct range for all keys are in the second post.

[kalaam]

Does anyone have concerns about the advancement of machine learning algorithms becoming increasingly capable of breaking complex encryption methods, such as secp256k1 and others?

[digaran]

Does anyone have concerns about the advancement of machine learning algorithms becoming increasingly capable of breaking complex encryption methods, such as secp256k1 and others?

What is secp256k1 encryption methods? elliptic curve doesn't encrypt anything, it's just a numbering system with 2 sides, negative and positive.

Here is an example of how it is possible to "break" the key :
Imagine this is your private key :
368812095337 and this is your public key:
023eb3a5c5c9e1303055215b2f2f455288bda053e1791a2b06d2c385cbc94eb51a

Now imagine you have zero knowledge about private key, can you or AI tell us how we can reduce the size of private key down to 368812  without even knowing the actual key above? If you guys can do that, I'd be concerned.

[mabdlmonem]

how much time and resource to find a public key in range 40000000000000000000000000000...7ffffffffffffffffffffffffffff  115 puzzle with kangaroo

[CY4NiDE]

While running some performance tests with Rotor-Cuda I've noticed that when I assign a monstruous grid-size for my GPU, I can get more speed.

If I set it like this --gpux 18000,512 I get a steady 4.62 GK/s peaking at 6.90 GK/s for a few seconds.

Can this cause any problems, like skipping keys during the search? If so, can anyone recommend a good grid-size for a 3080ti?

Thanks in advance!

[WanderingPhilospher]

While running some performance tests with Rotor-Cuda I've noticed that when I assign a monstruous grid-size for my GPU, I can get more speed.

If I set it like this --gpux 18000,512 I get a steady 4.62 GK/s peaking at 6.90 GK/s for a few seconds.

Can this cause any problems, like skipping keys during the search? If so, can anyone recommend a good grid-size for a 3080ti?

Thanks in advance!

The best thing to do is to test your grid size and run through a small range, something like a 2^40 range. See if the grid size finds the key or not.

I use a similiar version of KeyHunt Cuda / Rotor and haven't missed a key with a large grid size. But seriously, run a simple test to know for sure with your card and setup.

[CY4NiDE]

Hey there, thanks for your reply. Much appreciated.

So if it can pass the 2^40 test without skipping any keys can I deem it safe?

So far no problems with 2^35, 2^38, 2^39, 2^40.

--gpux 32000,512

[WanderingPhilospher]

Hey there, thanks for your reply. Much appreciated.

So if it can pass the 2^40 test without skipping any keys can I deem it safe?

So far no problems with 2^35, 2^38, 2^39, 2^40.

--gpux 32000,512

I would run a few tests. Put some keys at the beginning of range, the middle and the end. I've used some large grid sizes with no issues.

If you are using the rekey option, you will get fluctuation in your speed no matter the grid size; as it spins up to rekey and then picks back up.

[CY4NiDE]

I definitely got ahead of myself. 

I ran X-Point mode using --gpux 32000,512 against 20 keys spread over the 2^40 range and only 2 of those keys were being found.

Same with --gpux 18000,512 and anything in between.

In the end only with --gpux 1024,512 the program was able to find all 20 keys without skipping.

I'll run 2^50 next against more keys to see if this effect gets mitigated as the space increases.

Haven't checked Address mode or Hash160 mode yet.

[digaran]

You might be interested to read and learn more about grid sizes, there are more stats which you could find by visiting this nvidia page  there are technical stats on what is the acceptable grid size for different applications. You can't simply use any arbitrary grid size.

[WanderingPhilospher]

You might be interested to read and learn more about grid sizes, there are more stats which you could find by visiting this nvidia page  there are technical stats on what is the acceptable grid size for different applications. You can't simply use any arbitrary grid size.

Digger doesn't even own a GPU or PC, lol. He's doing all of his tests from an old Blackberry flip phone

I've had some large grid sizes CY4NiDE, but I keep them multiples. If card stock grid is 38,128; then I will keep a front grid that is a multiple of 38. I normally run multiple of 38x256. I've used 760x512 with no issues, 1520x512 with no issues, and I think 1 multiple higher.

Those are tests with KeyHunterGPU; Rotor has some flaws in it, especially if using the continue option. I stopped using/testing all versions of Rotor after I discovered a bug with the continue option, because it was causing keys to be skipped.

[CY4NiDE]

Yeah, I was testing different grids for my card the other day, within the reasonable bounds, keeping it a small multiple of the original grid.

After a while I decided to play with it a bit and increased the grid by larger factors, thus arriving at numbers like 18000 and 32000. They are not arbitrary.

I thought the program wouldn't even initiate. For my surprise not only it ran but it had increased speeds. Then it came to mind that it was probably jumping over a bunch of keys.  

It was too good to be true. I was getting a constant 5GK/s with sudden peaks to 9GK/s every few seconds running sequential X-Point mode with a grid-size like --gpux 36000x512 against #130.

Raise it much further than that and the speed will keep dropping to 0.00 MK/s for a few seconds during the entire search.

Anyways, if going for random mode I guess this issue could be overlooked? One can have more threads thus searching faster, the trade-off being skipping some keys...

About this other flaw [in a scenario where the grid-size is not causing it to skip keys] could I avoid it by updating the lower range in my .bat file to be the last key shown in the counter before terminating the session, instead of using continue.bat?

Thanks!