Topic: [ARCHIVE] Bitcoin challenge discusion - page 14. (Read 28991 times)

Not 3 weeks ago, 23th Sep 19 only.
#105 key is:
DEC: 29083230144918045706788529192435
HEX: 16f14fc2054cd87ee6396b33df3
WIFc: KwDiBf89QgGbjEhKnhXJuH7Lrcim5eBMkFQwQtRbW6wxT1ajoNqE

To MrFreeDragon you confirm that I have written.

Main to appear in the necessary time in the necessary place, i.e. to begin search maximum close to a required point.
Then speed of search and computing capacity of the computer will leave on the second place.
As against a lottery here you know that search - #62 1Me6EfpwZK5kQziBwBfvLiHjaPGxCKLoJi  and provisional place 200000000000000 - 3FFFFFFFFFFFFFFF
In this range the people can vary an index point of search, bat in a lottery the man takes that ticket, which him is given by(with) the seller.
Even if the man himself fills in numbers of the lottery ticket nobody knows what numbers will be happy.
And here there is more detailed information - #62 1Me6EfpwZK5kQziBwBfvLiHjaPGxCKLoJi and provisional place 200000000000000 - 3FFFFFFFFFFFFFFF
There are more chances than in the lottery. Moreover, the rules of the game are constantly changing in the lottery

Which program can iterate bitwise but not in direct order?
Example.
We have start number in dec
223549943504745960712268251712
And have map position bits
0->10, 1->25, 2->8, 3->51 and etc
In this variants next number not
223549943504745960712268251713
convert to bin
00000010 11010010 01010100 00101101 11100000 01010111 11000110 00101011 10001001 11000000 01100101 10000010 01000000
00000010 11010010 01010100 00101101 11100000 01010111 11000110 00101011 10001001 11000000 01100101 10000110 01000000
in dec 223549943504745960712268252736
next
00000010 11010010 01010100 00101101 11100000 01010111 11000110 00101011 10001001 11000000 01100101 10000110 01000000
00000010 11010010 01010100 00101101 11100000 01010111 11000110 00101011 10001001 11000010 01100101 10000010 01000000
in dec 223549943504745960712301806144
next
00000010 11010010 01010100 00101101 11100000 01010111 11000110 00101011 10001001 11000010 01100101 10000010 01000000
00000010 11010010 01010100 00101101 11100000 01010111 11000110 00101011 10001001 11000010 01100101 10000110 01000000
dec 223549943504745960712301807168
next
00000010 11010010 01010100 00101101 11100000 01010111 11000110 00101011 10001001 11000010 01100101 10000110 01000000
00000010 11010010 01010100 00101101 11100000 01010111 11000110 00101011 10001001 11000000 01100101 10000011 01000000
dec 223549943504745960712268251968
and etc for all position.
Well, it’s understandable to apply the obtained values as a private key to check for matches.
It is also desirable that the key is cut to the desired value in bits and the first bit is set to the left. According to the specified lengths.
Example.
In programm seeted values 70,71,72,73,74
App calculate next priv sample in bin
00000010 11010010 01010100 00101101 11100000 01010111 11000110 00101011 10001001 11000000 01100101 10000011 01000000
and try get key from next data
Which app can make this? Kango, vanity, hashcat? And nead calcualte on GPU. On CPU i have realisation on php.

You do not increase your chances by this way. The chances remain the same, you just slpit them to 2 differet events: (1) selection of patterm, (2) brutforce the remaining part.

Let's calcualate your suggestion. For #62 wallet there are 2^61 all posible combinations. The key in HEX format has 16 digits, where the 1st digit is 2 or 3 (2 possibilities), and the remaining digits could be from 0 to F (16 possibilities).

You are randomly selecting the pattern for the first 6 digits of the key (which is 363D54 in your example), and the remaining 10 digits you are going to brutforce. Let's say you have small speed to brutforce (100MKey/sec), so with this speed you need 16^10 / (100,000,000) * 60 * 60 hours which is smth like 3 hours. Good, only 3 hours!

BUT, what are you cnances to select the correct patter? Let's calculate:
All possible combinations for the 1st 6 digits are 2 * 16^5 = 2,097,152. More than 2 million! It is 0.000048%, very very small, like nothing.

Go to wiki https://en.wikipedia.org/wiki/Paris and learn that 2,140,526 residents live there. It is close to our possible combinations.

So, your methond could be imagined like this:
The creator made a quest and says to you: "I put 6k dollars to one of the citizens of Paris. You can ask everybody in Paris and he will answer the truth after 3 hours. If you find the correct person - you can take the bounty".

You go to Paris, find any citizen and aks him: "Yes or No" (this is your pattern for first bits). That citizen waits for 3 hours, and only after these 3 hours (your brutforce the remaining bits) answer: "No". Unlucky, no problem, go to another citizen, and so on   Do you want to participate in such quest to win just 5-6k dollars?

PS. I do not know where do you live. But in every country theare lotteries. I beleive that you can find the lottery which is run every 3 hours with the chances 1:500,000 - 1:2,000,000, HOWEVER the prize to win will be not 5-6 thousand dollars (like for #62), but even even more ≈ 100 thousand dollars.

PS. Smbd with more speed (let's say 300MKey/s, 1080ti) will receive the answer within 1 hour. Smb with 1,300MKey/sec (2080ti) will receive the answer within 15 minutes ) But the quest still remain very hard!
PPS. For #64 key the quest is the same but you should go to London with 8 million residents instead of Paris. For #64 key you should go not to city but to the whole country like Canada with 32-35 million residents. And so on.

To MrFreeDragon

I wanted to say another.
For example we shall take #62  1Me6EfpwZK5kQziBwBfvLiHjaPGxCKLoJi
Presumably he should be 200000000000000 - 3FFFFFFFFFFFFFFF
If I shall begin search with 200000000000000 - me there will be no life to find the necessary address.
But, if I for any reason shall begin search not with 200000000000000 and from another 363D540000000000 that even at small speed of my computer
The true address 363D541EB611ABEE will be found rather quickly.
It will be equivalent of your theory about hit of a lightning in the separate man.

By the way, where is the key for #105? It was released by 57fe 3 weeks ago (8Sep 19), but the key has not been published yet 

For all practical purposes:  no chance at all.

if someone took the key space 2^256
and start ruining his bots with speed 200 address/sec (generating and testing for tx and balance 200/s)

what is his chance to find an address with tx or balance from all addresses that ever used?
 

to be honest i start working on similar project but need to increase speed and few option to working on

Here is the list of some of them (not all 55 for every year, but some famous people):

https://www.ranker.com/list/famous-people-who-died-of-lightning/reference

Perhaps these 55 people thought so too?

One more participant in the digital lottery  

The chances to find the key (randomly) during the priod of 10,000 years with the speed 1130MKey/sec are (1 130 000 * 60 * 60 * 24 * 365 * 10 000) / (2^63) = 0.038636 ≈ 3.8%

For 80 years (like for the whole your life) it just 0.031% [but actually some less because your random could generate the same keys during these 80 years]

For comparison, there are 16,000,000 thunder storms annually, 25,000,000 cloud lightings come to earth. Such lightings kill approximately 55 humans during a year. Considering the average life of 80 years, te chances to be killed by a storm lighting are 1:3000, so it is like 0.033%, which is more than the chances to find a key for #64 with the speed 1130MKey/s for 80 years  

So, do you really expect to be killed by a lighting storm during your life? Oh no, you beleive this will never happen because the chances are very very low.

But why do you beleive to find the key to #64 where the chances for the same period (80 years) are less? - the answer is in our mind which rejects the statistics: positive events are expected to happen (even with very very low chances), but negative events we just not beleive could happened.

I am using bitcrack on RTX 2080 Ti and  has speed of 1130 Mkeys/s. I am scanning from last 4 days. Now I am thinking to scan random.

what do you use ? and what is your speed?

i try this and no luck yet

#64

9000000000000000   -     900008c8cdbfc000
fe38B13505B26867   -     fe38b4e9a9e18000
fe08b4e9a9e18000   -      fe38b28c4dcdf000
f908b4e9a9e18000   -      f908b83fef996800
e908b4e9a9e18000  -      e908b8e3fd70a800
f200000000000000   -      f20007dc504d4000
a0dea1390507f800   -      a0decf332bc7f800
f4430518eaddc000   -      f44309cb5f5dc000
d39b97986985a000  -      d39bf99dea45a000
c89526398b87e000  -      c895840b4507e000
de1df04147b1b000  -       de1df13e0f31b000
e3ef4e58aa31b000   -      e3efc87af531b000
cde0b6b3a7640000  -      cde0c690b6a40000

This ranges are already scanned.
 

Unless you are using -r and hoping to get lucky 

This is a good point. If you are searching for +1 and starting from the beginning of the keyspace you are racing against the fastest guy in the world, whoever he is. It is more than likely you are not the fastest guy because you haven't found the highest private key, have you? Doing this is enormous waist of the resources, only one guy needs to have faster calculator than you, and it is more than likely bunch of guys already checked private keys you are currently checking thinking they were the fastest. But they were not, they were only thinking they were fastest because only single one can be fastest, all others are heating their homes with wasted electricity.

I wonder how many people are deliberately working on brute forcing a harder output, say #66 or #67, to increase their chances of being able to find the solution before someone else claims it? If you work on +1, then you could already be a quarter to halfway through the search space for the "new" key, by the time the solution for is discovered.

The main idea of The Kangaroo algorithm could be explain by the example of birth dates paradox.

Imagine that you take the group of 23 persons, so there is more than 50% probability that 2 persons were born on the same date. If you take the group of 50 persons, the probability that 2 of them were born on the same date is at least 97%. For group of 100 persons, such probability is 99.99996%.

So, to find 2 persons with the same date of birth you do not need to ask 366 persons. You can easility take the group of 50 persons (which is 7 times less) and highly likely (with 97%) find within this goup 2 persons with the same date of birth.

In bitcon with (or withount) public key is the same idea. If you do not know the public key the directway is to bruteforce the whole range. But if the public key is known, you can highly likely find the private key just making the squre root of the total range operations.


Example: for 40bit key (41 bin digits) the range is 2^40 = 1 099 511 627 776. This could be bruteforced with the speed 350Mkey/sec for approx. 52 minutes. But with the Kangaroo method the calcualtions range is only  1 048 576, and highly likely you will find the key. Highly likely means that not 100%, but very close to 100%.

For #105 key the approximate range with Kangaroo is 4 503 599 627 370 496 which could resolved with 300MKey/sec speed for 175 days (almost 6 months). But with the 5 times more speed (1,500MKey/sec) it could resolved just for 1-1.5 months. But again, "resolved" here means that "more likely resolved" with not 100% but very close to it.

To add further detail...

When the pubkey is known, all you have to do is find an efficient way (more efficient than brute force) to "reverse" secp256k1 and obtain the private key.

When the pubkey is unknown, you must also find a way to reverse two cryptographic hash functions (RIPEMD160 and SHA256). This is going to be near impossible, since when you feed data to a cryptographic hash function, the output does not resemble the input in any way. It's deliberately modified, mixed, and mashed together into a sea of random looking bits.

You would need to:

1. Break (ie discover and exploit an inherent weakness in the algorithm itself) RIPEMD160 to find an input of precisely 256 bits that matches the address you're trying to crack.
2. Break SHA256 to find an input of precisely 264 bits (for a compressed public key) or 520 bits (uncompressed) that results in the 256 bit value which was created from step #1.
3. That input value from step #2 is the public key. (It probably won't be the same public key used by the rightful owner, however, I think a collision at this point would be sufficient to claim funds?). But then you still have to crack the pubkey to find the 256 bit private key...

Step #3 is already computationally impossible.

The Kangaroo algorithm requires that you know the public key in order for it to work.  Knowing the Bitcoin address, which is the hash of the public key, cannot be used.  You need to know the actual public key or you cannot use the Kangaroo algorithm.  If you are interested in exactly how the Kangaroo algorithm works you can check out our thread here:

https://bitcointalksearch.org/topic/science-fair-project-to-trap-bitcoin-private-keys-using-kangaroos-5173445

Or, just read about it here:

Pollard Kangaroo algorithm