Topic: [ARCHIVE] Bitcoin challenge discusion - page 15. (Read 29427 times)

For this case you have a VanitySearch.

It is impossible to add to the algorithm a kangaroo so that it does not search by public key, but by address? Suppose this takes longer, but you can search for keys for addresses without an outgoing transaction. Or is the kangaroo algorithm not suitable for this?

From the OP:


#64 has never been spent (an outbound transaction), so there's no public key known yet.

If brute force is the only way to creak a P2PKH address with no outbound transactions, then at some point it may become more viable to crack the lower ranges of #160 to #256 (public keys known) than to brute force the "easier" challenges of #156 to #159 (public keys unknown).

Public key for #64 = ?

Okay, I've re-read the OP, and it seems I missed that the keys were generated randomly from a specific range for that key, rather than a 256 bit number with the upper bits masked out.

I'm sure I saw the person who created the transaction (whose nick I cannot remember now) say something about masking, but it wouldn't be the first time my memory had failed.


-----

Edit: I found the text from the creator. (I cannot vouch for authenticity)


So I remembered correctly: the creator specifically mentions masking (of deterministic keys), rather than generating random numbers from specific ranges.

Based on the binary representation here https://rya.nc/forensic-bitcoin-cracking.html , it seems that all keys up to at least #37 have their top bit set, so if it's truly masked as the creator stated, it would be a massive coincidence (like flipping heads 37 times) that all have that bit set.

(Perhaps each key was masked PLUS the top bit set?)

The next key should start with 1, because the rage is given already
it is 2^n-1->2ⁿ-1, not 1->2ⁿ-1

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...

MeBender  -  I THANK  YOU!

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

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

Congratulations to 57fe for getting the #105. 

https://bitcointalksearch.org/topic/m.52531552

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://bitcointalksearch.org/topic/m.51900286

---

Pubkey is 03bcf7ce887ffca5e62c9cabbdb7ffa71dc183c52c04ff4ee5ee82e0c55c39d77b

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

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

#105 is d(g)one

who is this lucky man?

why not? 64 and 105

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

people still trying to bruteforce #64?

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).

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

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