[ARCHIVE] Bitcoin challenge discusion

[MrFreeDragon]

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 

[1714163282]

1714163282

[1714163282]

1714163282

[1714163282]

1714163282

[1714163282]

1714163282

[iparktur]

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.

[MrFreeDragon]

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.

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.

[mrxtraf]

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

Code:

orig  :...101 11100000 01010111 11000110 00101011 10001001 11000000 01100101 10000011 01000000
74bits:    11 11100000 01010111 11000110 00101011 10001001 11000000 01100101 10000011 01000000
73bits:     1 11100000 01010111 11000110 00101011 10001001 11000000 01100101 10000011 01000000
72bits:       11100000 01010111 11000110 00101011 10001001 11000000 01100101 10000011 01000000
71bits:        1100000 01010111 11000110 00101011 10001001 11000000 01100101 10000011 01000000
70bits:         100000 01010111 11000110 00101011 10001001 11000000 01100101 10000011 01000000
69bits:          10000 01010111 11000110 00101011 10001001 11000000 01100101 10000011 01000000

Which app can make this? Kango, vanity, hashcat? And nead calcualte on GPU. On CPU i have realisation on php.

[iparktur]

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

[57fe]

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 

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

[Raj Lassi]

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

Code:

orig  :...101 11100000 01010111 11000110 00101011 10001001 11000000 01100101 10000011 01000000
74bits:    11 11100000 01010111 11000110 00101011 10001001 11000000 01100101 10000011 01000000
73bits:     1 11100000 01010111 11000110 00101011 10001001 11000000 01100101 10000011 01000000
72bits:       11100000 01010111 11000110 00101011 10001001 11000000 01100101 10000011 01000000
71bits:        1100000 01010111 11000110 00101011 10001001 11000000 01100101 10000011 01000000
70bits:         100000 01010111 11000110 00101011 10001001 11000000 01100101 10000011 01000000
69bits:          10000 01010111 11000110 00101011 10001001 11000000 01100101 10000011 01000000

Which app can make this? Kango, vanity, hashcat? And nead calcualte on GPU. On CPU i have realisation on php.

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!   

[MrFreeDragon]

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!   

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

[MrFreeDragon]

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 

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

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?

[crofrihosl]

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 

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

https://keys.lol/bitcoin/227212735507172232084285384316

Code:

0 btc (5 tx)   5HpHagT65TZzG1PH3CSu63k8DbpyfD3oPVBrwMG66gs4W77dCDN   1JATjHbShdvgkvGHyoRv1vTnEeiibqMVnj    1CMjscKB3QW7SDyQ4c3C3DEUHiHRhiZVib

maybe Google will index this address now  

[Razick]

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.

[57fe]

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 

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

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?

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.

[57fe]

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

[st0ffl]

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.

[mrxtraf]

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.

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?

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!   

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

[cryptonite101]

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)

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?

[mrxtraf]

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?

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.

Code:

2019-09-29 20:39:07     222312390859770514489418809920  F:0     C1:3899535 C2:296364660          In sec 12964 var. In min 777860 var
2019-09-29 20:40:07     218598570004008863471606530624  F:0     C1:3909466 C2:297119416          In sec 12963 var. In min 777799 var
2019-09-29 20:41:07     221069917349776220271478669888  F:0     C1:3919395 C2:297874020          In sec 12962 var. In min 777738 var
2019-09-29 20:42:07     221688887221883522150213976640  F:0     C1:3929287 C2:298625812          In sec 12961 var. In min 777671 var
2019-09-29 20:43:07     221693344693121491067113669184  F:0     C1:3939217 C2:299380492          In sec 12960 var. In min 777611 var
2019-09-29 20:44:07     220450266607233054658515010112  F:0     C1:3949461 C2:300159036          In sec 12960 var. In min 777614 var
2019-09-29 20:45:07     219213006736295439409437049408  F:0     C1:3959598 C2:300929448          In sec 12959 var. In min 777595 var

222312390859770514489418809920  hese are the keys in decimal format that were at the time of the output of the string.

[Devicore]

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.

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 :

Code:

Please give the modulus (p).
1
Please give the generator (g).
1
Please give the order of the generator (q).
1
Please give the element (y).
1
What value k for the special point condition would you like to use?
1

[MrFreeDragon]

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.

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?

There are two answers to your question.
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.

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?

[paniker]

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

why do check this ranges?