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

The publickeys for #64 and #66 are not revealed. There has to be an outgoing transaction to be able to get the publickey.
We only have the public keys of numbers ending with 5 and 0.

I need public key for non find number .. 64, 66 etc  nobody help my?

I posted a solution to test in BurtW's thread.
If there are no concerns regarding the Pollard Kangaroo method and they confirm it, i will post the new table with publickeys to search for in this thread.

No logic applied. Just guesses.

28 million? Oh no, much much more! In average there are 2^96 private key for every bitcoin address. 2^96 is 79.22 * 10^27, so 79 and 27 zeros after it   It is much much more than you said 28 million!

Problem here for me is not to find the private key, but to find such collission (2 different private keys to the same address). Such finding will help better understand the group of private keys. Examing such collision in details will help to understand the things which are no known now, i beleive. May be we can see something new for this bitcoin transaction chalenge as well.

The collision finding is offtopic here, so some weeks ago I created a separate discussion for it: https://bitcointalksearch.org/topic/example-of-btc-collision-2-different-priv-key-to-the-same-btc-address-5185726

Yes you are right, there are about 28 million private keys for every single Bitcoin address. Whichever of these 28 million keys you find, you can take the coins from that address. Problem is you can not find the single one of those private keys by chance, let alone the other ones that lead to the same address, so this is totally unimportant. We humans are very bad with large numbers, so 2^160 looks to us very different to 2^256, while in fact they are both so big that for all practical purposes there is no difference between them, that's why the Bitcoin address scheme is designed this way.

why do check this ranges?

I also learned that one key for one private key is guaranteed by the ECDSA. But do you know how to prove it?
I mean that there is a number of points in the amount of order. But why some 2 points generated by two different private keys could not be the same point?


Actually this was my question. I'm with you that there are only 2^160 addresses, but almost 2^256 private keys. So there should a collision, because every private key could be converted to the address only in one posible way (if we are talking about the same format, like Legacy, Segwit, bech32)
When we have a private key and the address which was generated from the private key, so the x,y coordinates of the address are in the same group as the basis point. There also should be other private keys which lead to teh same address.

And I also very curious about the ability to sign with different private keys. Imagine that somebody found 2 (or may be more) different private keys to the same address. Is it possible to make outgoing transactions with the both keys or only with that one which was primarirly used? I guess that for Legace addresses it is possible. But for beech32 addresses only one unique private key should be used. Am i right?

Yes I am very interested about what BurtW and Telariust are doing too, that would be really interesting to see your method since without GPU, the best key/s on Pollard Rho Kangaroo are not more than 450k/s on CPU.. It's pretty good in fact but ridiculous if we compare it to GPU

As a C# developer have you tried to wrote your own GPU script ?  

By the way anybody know what theses values means exactly if we want to find the #110 on this Pollard Rho GPU script https://github.com/twjvdhorst/Parallel-Pollard-Rho/? What do we have to put instead of the "1" to make it work ?

Here's the cmd :

Probability theory.
Someone starts the search from the end, someone goes through the ranges. And I want to try this way. Rather, I realized this, but on the php, and the speed is small, only 13K keys per second.
222312390859770514489418809920  hese are the keys in decimal format that were at the time of the output of the string.

It's not clear where you're going with this. You can create any mapping for the keys, but you still have to iterate through all of them, so what's the point?

I try explaine. It would be better in Russian, but let's try it this way. 
Any string or number consists of bits. The bit position is counted from right to left. That is, the zero bit is on our right.
This is how simple incremental enumeration looks like in bit representation.


Hex   7 6 5 4 3 2 1 0 (Position)
00    0 0 0 0 0 0 0 0
01    0 0 0 0 0 0 0 1
02    0 0 0 0 0 0 1 0
03    0 0 0 0 0 0 1 1
04    0 0 0 0 0 1 0 0
05    0 0 0 0 0 1 0 1
06    0 0 0 0 0 1 1 0
07    0 0 0 0 0 1 1 1
      1 0 6 3 7 3 2 5 (new position from map see down)

and etc.
This is standart incrementla.

But I want, with standard enumeration, a changed bit position.
For example.
We have map. 0->5, 1->2, 2->3, 3->7, 4->4, 5->6, 6->0, 7->1
This means that the bit at the zero position puts on the fifth, the bit on the first position puts at the second position, the third bit at the seventh, etc.
Given these permutations, we get the following numbers.

Old Hex   7 6 5 4 3 2 1 0   NewHex          (Position)
00        0 0 0 0 0 0 0 0   (00)
01        0 0 1 0 0 0 0 0   (20)
02        0 0 0 0 0 1 0 0   (04)
03        0 0 1 0 0 1 0 0   (24)
04        0 0 0 0 1 0 0 0   (08)
05        0 0 1 0 1 0 0 0   (28)
06        0 0 0 0 1 1 0 0   (0C)
07        0 0 1 0 1 1 0 0   (2C)
          3 5 0 4 2 1 7 6   (old position)

Next, the new received number is used as a private key.
We got a big key, we can try to get the wallet address using it as a private key.
But in our task, the keys must be of a certain length in bits. So we cut this key to the desired lengths, and check each received option. At the same time, it is unforgettable that you need to set the left bit to one.
For example, we indicated that we are looking for keys with a length of 6,5,4 and 3 bits.
Getted this number
05        0 0 1 0 1 0 0 0   (28)
And calculate

Len  7 6 5 4 3 2 1 0  Hex
Orig 0 0 1 0 1 0 0 0 
7    0 1 1 0 1 0 0 0  68
6    0 0 1 0 1 0 0 0  28
5    0 0 0 1 1 0 0 0  18
4    0 0 0 0 1 0 0 0  08
3    0 0 0 0 0 1 0 0  04

From each number 68, 28 , 18 ... Try generated and cheked new address.
Now it is clear?

I do not speak C very well. Especially in terms of converting from bit to prime numbers and compiling numbers bit by bit.

Hi there,
i always thought the puzzle transaction was made by LBC, actually came here cause i saw some publickeys where revealed.
Congrats to #105! Seems like 57fe is winning the race.
Can we expect from 57fe and j2002ba2 that they share their scripts involving GPU ECPoint math when #110 or #115 is found?

I'm impressed how fast the kangaroo method is, tested the python script from 57fe, the modified multicore from Telariust and read BurtW c#.
As a c# developer i was playing a lot with eliptic curve points, when i wanted to learn about bitcoin and about it's security.
Back then i never thought about the the security when you would know that a public key is in a specific space...

I developed a method the last day which is easy to implement within your scripts and halfs the searchtime per space.
Looking forward to post it in BurtW's thread later if somebody is interested.
if the table from j2002ba2 is correct using 4x V100:
#110 > 90 days > 45 days
#115 > 1 year  147 days > 256 days

What i don't understand is why the creator of the puzzle revealed the publickeys to +5 from 2^160...
Correctly there should be 161 to 255 also rewarded when dealing with such.

Of course, secp256k1+SHA256+RIPEMD160, not rounding of SHA256 output. But definitely it is acting like rounding.

There are two answers to your question.
1. No other private keys, if you mean the same public key (256 bits of X-coordinate plus one byte for parity of Y-coordinate and pubkey format). This is guaranteed by elliptic curve group structure. Each public point and corresponding coordinates are unique. It's true also for compressed pubkey.
2. Yes, huge amount of private keys, if you mean the same public address (160 bits, wallet address). Approximately there is must be 2^96 different private keys for each public address. This is provided by good statistical properties of SHA256 hash function, which was accurately tested by many cryptographers before this hash function was standardized, i'm sure. We must have unavoidable collisions for 256 bits space of input at rounding of SHA256 output to 160 bits. It is the reason for the creator of the puzzle to cancel problems from #161 to #255 some years ago, because if you can solve #160 by brute force means you can reveal privkey for any address in same time. It is not true for ECDLP, but ECDLP-race started only 4 month ago.

Nice question, thanks.
PS: nobody found collisions with known public address for secp256k1+SHA256 and similar schemes, it's equivalent to solving #160 by brute force. You can also found random, but useless collision by Pollard's rho or kangaroo methods, that equivalent to solve #255 with kangaroos. Yes, here is Pollard again. When the first case will be happened, BTC and all similar cryptocurrencies will be broken. Hopefully, we have only #63 solved right now, and no practical chances for #159 (#160 is occupied by kangaroos) without superquantum computer, which complexity growths even faster with each new qubit than the complexity of brute force, or we need something like Almanach from "Back to the Future" movie with published privkeys. Who knows what is more realistic.

Well I have absolutely no idea of how to do this. I would just brute force but in my limited experience it would probably take until the end of the foreseeable universe and still wouldn't be cracked, so leave it to others.

https://keys.lol/bitcoin/227212735507172232084285384316

maybe Google will index this address now  

Thank you! I was wrong with the date. On the 8th of Sep there was release of #62 key.

57fe, how do you think, are there other possible private keys for the same #105? Have you any ideas how to find these "other" private keys?

Not the same results! You at least saved your electricity consumption 

I am pretty dumb, so after 20 minutes, i still could not figure out what you are trying to do.

I especially do not understand this part:
"And have map position bits
0->10, 1->25, 2->8, 3->51 and etc"

decimal confuses me, so i converted to hex and got these numbers (and spaces to visually separate the part that changes):
2D2542DE057C62B89 C06582 40
2D2542DE057C62B89 C06586 40
2D2542DE057C62B89 C26582 40
2D2542DE057C62B89 C26586 40
2D2542DE057C62B89 C06583 40

i still don't get it.

Bitcrack is easily modified to create whatever starting points you want.  Look at CudaKeySearchDevice.cpp.
You can write functions to play all sorts of bit games, shifting, rotating, random XOR, using digits of pi, etc.

I have made my Bitcrack spin the top 2 bytes from 0000-FFFF for each random 3 bytes (15 of them per run).  Then it spins the last 2 bytes 0000-FFFF and restarts.  It can also read 3-byte numbers from a text file every time it restarts.  The few million leftover starting points are random.

The interesting thing is, i have not run any of my bitcoin hacking programs for a few weeks and still achieve the exact same results!