[ARCHIVE] Bitcoin challenge discusion

[iparktur]

This "another" key works as well. Try to check it in bitcoin address generator, or try to import this file into your wallet. You will receive the access to the same address of wallet #62 lol )

Maximum value for secp256k1 is:

FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141

Your key is above this value:

FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B F60FB2AB 8647ED2F

Some software will correctly reject this out of range value, but others will just overflow and wrap max+1 to 0.

The result of F60FB2AB 8647ED2F minus BFD25E8C D0364141 is 363D541E B611ABEE, which is the "proper" key. That's why your key works: when wrapped around it ends up being the same calculated value.

(If this was a clever joke, sorry that I spoiled it. )

It turns out the transition to the second round (to a new ring)?

[1715180666]

1715180666

[1715180666]

1715180666

[1715180666]

1715180666

[supika]

This "another" key works as well. Try to check it in bitcoin address generator, or try to import this file into your wallet. You will receive the access to the same address of wallet #62 lol )

Maximum value for secp256k1 is:

FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141

Your key is above this value:

FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B F60FB2AB 8647ED2F

Some software will correctly reject this out of range value, but others will just overflow and wrap max+1 to 0.

The result of F60FB2AB 8647ED2F minus BFD25E8C D0364141 is 363D541E B611ABEE, which is the "proper" key. That's why your key works: when wrapped around it ends up being the same calculated value.

(If this was a clever joke, sorry that I spoiled it. )

It is possible that some private keys to be "outside" of the standard agreed key space? Somewhere where nobody will search?

[PrivatePerson]

Let's!
:
:
to be continued..

Your post is very informative, but goes down in history, maybe you should create a separate topic?

[almightyruler]

It is possible that some private keys to be "outside" of the standard agreed key space? Somewhere where nobody will search?

That won't work. A key value outside the curve literally means that it's invalid (presumably, the public key cannot be computed from such a private key). Once you go above the maximum value, the key will either be rejected (if the software checks), or the value will overflow back to the start of valid key space.

[bulleteyedk]

Can you please tell your configuration for 1080ti? (b, t, p and any other relevant info). What CUDA do you use? (9.2 or the newest 10.1).
I tried on the week to test 1080ti (Gigabyte Gaming OC 11Gb) and received thr result 150 Mkey/sec (as another guy posted earlier) with -b 56 -t 512 -p 2048.

I've not tried running BitCrack with newer GPU's, i have 3 older ones running, but they are tweaked to the max of their capacity.

I have not seen any significant performance issues running CUDA 9.xx vs. 10.xx, i know that there is more features in some particular BitCrack builds running CUDA 10.xx

I've looked up your 1080i specs, and according to those i would try and run with any these settings:

-b 88 -t 448 -p 2048  
-b 176 -t 672 -p 2048

if you encounter a crash or a message displaying your GPU is out of memory, you need to tweak the -p parameter to a lower value, let us know how this turns out  

And if this is running just fine, you might as well add more value to -p as this GPU has a lot of memory

[PrivatePerson]

62. Wallet

Private Key : KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYpCemuaUp7NigjvtJug

Public Key : 03231a67e424caf7d01a00d5cd49b0464942255b8e48766f96602bdfa4ea14fea8

Private Key (Hex): 363D541EB611ABEE
Private Key (Decimal): 3908372542507822062

Another private key to wallet #62:

HEX: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BF60FB2AB8647ED2F
DEC: 115792089237316195423570985008687907852837564279074904382609071514060669316399
WIF: L5oLkpV3aqBjhki6LmvChTCV6odsp4SXM6LBVeqHTSj1w9XhwfuR

Share the story how did you find another key?

[MeBender]

Can you please tell your configuration for 1080ti? (b, t, p and any other relevant info). What CUDA do you use? (9.2 or the newest 10.1).
I tried on the week to test 1080ti (Gigabyte Gaming OC 11Gb) and received thr result 150 Mkey/sec (as another guy posted earlier) with -b 56 -t 512 -p 2048.

I've not tried running BitCrack with newer GPU's, i have 3 older ones running, but they are tweaked to the max of their capacity.

I have not seen any significant performance issues running CUDA 9.xx vs. 10.xx, i know that there is more features in some particular BitCrack builds running CUDA 10.xx

I've looked up your 1080i specs, and according to those i would try and run with any these settings:

-b 88 -t 448 -p 2048  
-b 176 -t 672 -p 2048

if you encounter a crash or a message displaying your GPU is out of memory, you need to tweak the -p parameter to a lower value, let us know how this turns out  

And if this is running just fine, you might as well add more value to -p as this GPU has a lot of memory

Those values don't get higher than what I've been able to achieve with -b 56 -t 512 -p 2048

With that I get 350Mkey/s

[bulleteyedk]

ok, then all there is left is to get the -p value as high as possible without getting an memory error, you need to dial that in

[MrFreeDragon]

Can you please tell your configuration for 1080ti? (b, t, p and any other relevant info). What CUDA do you use? (9.2 or the newest 10.1).
I tried on the week to test 1080ti (Gigabyte Gaming OC 11Gb) and received thr result 150 Mkey/sec (as another guy posted earlier) with -b 56 -t 512 -p 2048.

For 1080ti i used -b28 -t512 and -p 1250, and received 340-350MKey/sec. I tried different values for b/t/p, and found that the b should be exact that the number of cores (i.e 28). Some members advices to use 2-3 times ore, but i didn't find real effect. The t should be multiple of 256, i used 512. And the p should be found by your own hardware. For me 1250 was the best.

I used the newest Cuda, but the released cubitcrack didn't work as wanted cudaart64_92.dll. I just copied this one dll file to the same folder with bitcrack, and it works properly.

I also tried to make the release for Cuda 10.1 and newest Visual Studio, but the speed was very slow (less than 50MKey/sec).

[usama12]

people still trying to bruteforce #64?

[MeBender]

Public key for #105 = 03bcf7ce887ffca5e62c9cabbdb7ffa71dc183c52c04ff4ee5ee82e0c55c39d77b
Public key for #110 = 0309976ba5570966bf889196b7fdf5a0f9a1e9ab340556ec29f8bb60599616167d
Public key for #115 = 0248d313b0398d4923cdca73b8cfa6532b91b96703902fc8b32fd438a3b7cd7f55
Public key for #120 = 02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630
Public key for #125 = 0233709eb11e0d4439a729f21c2c443dedb727528229713f0065721ba8fa46f00e
Public key for #130 = 03633cbe3ec02b9401c5effa144c5b4d22f87940259634858fc7e59b1c09937852
Public key for #135 = 02145d2611c823a396ef6712ce0f712f09b9b4f3135e3e0aa3230fb9b6d08d1e16
Public key for #140 = 031f6a332d3c5c4f2de2378c012f429cd109ba07d69690c6c701b6bb87860d6640
Public key for #145 = 03afdda497369e219a2c1c369954a930e4d3740968e5e4352475bcffce3140dae5
Public key for #150 = 03137807790ea7dc6e97901c2bc87411f45ed74a5629315c4e4b03a0a102250c49
Public key for #155 = 035cd1854cae45391ca4ec428cc7e6c7d9984424b954209a8eea197b9e364c05f6
Public key for #160 = 02e0a8b039282faf6fe0fd769cfbc4b6b4cf8758ba68220eac420e32b91ddfa673

[PrivatePerson]

people still trying to bruteforce #64?

why not? 64 and 105

[yauhenify]

#105 is d(g)one

who is this lucky man?

[almightyruler]

#105 is d(g)one

who is this lucky man?

Cracking a weak(ish) private key less than 4 months after the pubkey was revealed... mmmm. Congrats to the winner(s).

This message earlier in the thread shows estimates for bits vs cracking time. It may also give a hint as to who found it.

https://bitcointalk.org/index.php?topic=5166284.msg51900286#msg51900286

---

Pubkey is 03bcf7ce887ffca5e62c9cabbdb7ffa71dc183c52c04ff4ee5ee82e0c55c39d77b

https://www.blockchain.com/btc/address/1CMjscKB3QW7SDyQ4c3C3DEUHiHRhiZVib

BTW, the winner also needs to claim BCHABC/BCHSV and any other forks.

[PrivatePerson]

#105 is d(g)one

who is this lucky man?

https://bitcointalk.org/index.php?topic=1306983.msg52531552#msg52531552

[JDScreesh]

Congratulations to 57fe for getting the #105. 

[Firebox]

57fe, congrats!
Share pls the lucky script that you use to crack #105.

[MeBender]

Here are the keyspaces for the remaining unsolved addresses up to #110

#64 = 8000000000000000:FFFFFFFFFFFFFFFFF
#66 = 20000000000000000:3FFFFFFFFFFFFFFFF
#67 = 40000000000000000:7FFFFFFFFFFFFFFFF
#68 = 80000000000000000:FFFFFFFFFFFFFFFFF
#69 = 100000000000000000:1FFFFFFFFFFFFFFFFF
#71 = 400000000000000000:7FFFFFFFFFFFFFFFFF
#72 = 800000000000000000:FFFFFFFFFFFFFFFFFF
#73 = 1000000000000000000:1FFFFFFFFFFFFFFFFFF
#74 = 2000000000000000000:3FFFFFFFFFFFFFFFFFF
#76 = 8000000000000000000:FFFFFFFFFFFFFFFFFFF
#77 = 10000000000000000000:1FFFFFFFFFFFFFFFFFFF
#78 = 20000000000000000000:3FFFFFFFFFFFFFFFFFFF
#79 = 40000000000000000000:7FFFFFFFFFFFFFFFFFFF
#80 = 80000000000000000000:FFFFFFFFFFFFFFFFFFFF
#81 = 0100000000000000000000:01FFFFFFFFFFFFFFFFFFFF
#82 = 0200000000000000000000:03FFFFFFFFFFFFFFFFFFFF
#83 = 0400000000000000000000:07FFFFFFFFFFFFFFFFFFFF
#84 = 0800000000000000000000:0FFFFFFFFFFFFFFFFFFFFF
#86 = 2000000000000000000000:3FFFFFFFFFFFFFFFFFFFFF
#87 = 4000000000000000000000:7FFFFFFFFFFFFFFFFFFFFF
#88 = 8000000000000000000000:FFFFFFFFFFFFFFFFFFFFFF
#89 = 010000000000000000000000:01FFFFFFFFFFFFFFFFFFFFFF
#91 = 040000000000000000000000:07FFFFFFFFFFFFFFFFFFFFFF
#92 = 080000000000000000000000:0FFFFFFFFFFFFFFFFFFFFFFF
#93 = 100000000000000000000000:1FFFFFFFFFFFFFFFFFFFFFFF
#94 = 200000000000000000000000:3FFFFFFFFFFFFFFFFFFFFFFF
#96 = 800000000000000000000000:FFFFFFFFFFFFFFFFFFFFFFFF
#97 = 01000000000000000000000000:01FFFFFFFFFFFFFFFFFFFFFFFF
#98 = 02000000000000000000000000:03FFFFFFFFFFFFFFFFFFFFFFFF
#99 = 04000000000000000000000000:07FFFFFFFFFFFFFFFFFFFFFFFF
#101 = 10000000000000000000000000:1FFFFFFFFFFFFFFFFFFFFFFFFF
#102 = 20000000000000000000000000:3FFFFFFFFFFFFFFFFFFFFFFFFF
#103 = 40000000000000000000000000:7FFFFFFFFFFFFFFFFFFFFFFFFF
#104 = 80000000000000000000000000:FFFFFFFFFFFFFFFFFFFFFFFFFF
#106 = 0200000000000000000000000000:03FFFFFFFFFFFFFFFFFFFFFFFFFF
#107 = 0400000000000000000000000000:07FFFFFFFFFFFFFFFFFFFFFFFFFF
#108 = 0800000000000000000000000000:0FFFFFFFFFFFFFFFFFFFFFFFFFFF
#109 = 1000000000000000000000000000:1FFFFFFFFFFFFFFFFFFFFFFFFFFF
#110 = 2000000000000000000000000000:3FFFFFFFFFFFFFFFFFFFFFFFFFFF

[iparktur]

MeBender  -  I THANK  YOU!

[almightyruler]

Here are the keyspaces for the remaining unsolved addresses up to #110

#64 = 8000000000000000:FFFFFFFFFFFFFFFFF
#66 = 20000000000000000:3FFFFFFFFFFFFFFFF
[...]

Do these ranges take into account the possibility that the masked key could have at least one leading 0 bit? In other words, what is technically an x bit key (once masked) could actually fall within the x-1 bit (or even lower) scan range.

For example, the range you've provided for key #66 is in binary:
10000000000000000000000000000000000000000000000000000000000000 - start
11111111111111111111111111111111111111111111111111111111111111 - end

what happens if the key (after masking) has a leading zero bit? Its value then falls into the range of the previous key, #65. Random example:
01010111101111011011101010110000110010110111010111110000100111

In hex again:
20000000000000000 - start of #66 scan range
3FFFFFFFFFFFFFFFF - end of #66 scan range
15EF6EAC32DD7C27 - (fictional) key value is below this range

Correct me if I'm wrong, but it seems to me that if, once a solution is found, people abandon work and move to the next range, the new key could be hiding within an older scan range. In theory, key #66, when the leading bits are masked off, could be 00000000000000000000000000000000000000000000000000000000000001...