Bitcoin Forum
November 12, 2024, 05:04:48 PM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3]  All
  Print  
Author Topic: 2^96 same bitcoin address  (Read 911 times)
MikeJ_NpC
Member
**
Offline Offline

Activity: 107
Merit: 10

if you want to lie *cough*use your data; not mine.


View Profile
December 18, 2022, 02:20:59 PM
 #41

some private key will get the same address?
Yes, many private keys will create the same address. It's called a collision, but you can't find them.

does that apply for pubkeys  as well ?

Id like to know how many possible addresses are there with 2 consecutive characters. and 3 and 4 etc.. does it decrease by 1/2 on every step?

side question:
Also does it have any meaning if you have a 02 publickey and 03 publickey .. but  are a identical with the the exception of 02 03 - they result in the same btc address
i was under the impression they cannot match in this manner? 

If Karma is a bitch, then god is a woman. I ask to know, not to be screwed or hear trite excuses (after the fact) which a 3rd grader could do better on. If you give your word, keep it atleast..
LoyceV
Legendary
*
Offline Offline

Activity: 3486
Merit: 17667


Thick-Skinned Gang Leader and Golden Feather 2021


View Profile WWW
December 18, 2022, 04:37:48 PM
 #42

does that apply for pubkeys  as well ?
See Bitaddress.org > Wallet Details: Pubkeys are 130 characters HEX (or 66 compressed), private keys are only 64 characters HEX. That means there are 256 times more pubkeys than privkeys. I don't know if different private keys can still give the same pubkey though.

▄▄███████████████████▄▄
▄█████████▀█████████████▄
███████████▄▐▀▄██████████
███████▀▀███████▀▀███████
██████▀███▄▄████████████
█████████▐█████████▐█████
█████████▐█████████▐█████
██████████▀███▀███▄██████
████████████████▄▄███████
███████████▄▄▄███████████
█████████████████████████
▀█████▄▄████████████████▀
▀▀███████████████████▀▀
Peach
BTC bitcoin
Buy and Sell
Bitcoin P2P
.
.
▄▄███████▄▄
▄████████
██████▄
▄██
█████████████████▄
▄███████
██████████████▄
███████████████████████
█████████████████████████
████████████████████████
█████████████████████████
▀███████████████████████▀
▀█████████████████████▀
▀██████████████████▀
▀███████████████▀
▀▀███████▀▀

▀▀▀▀███▀▀▀▀
EUROPE | AFRICA
LATIN AMERICA
▄▀▀▀











▀▄▄▄


███████▄█
███████▀
██▄▄▄▄▄░▄▄▄▄▄
████████████▀
▐███████████▌
▐███████████▌
████████████▄
██████████████
███▀███▀▀███▀
.
Download on the
App Store
▀▀▀▄











▄▄▄▀
▄▀▀▀











▀▄▄▄


▄██▄
██████▄
█████████▄
████████████▄
███████████████
████████████▀
█████████▀
██████▀
▀██▀
.
GET IT ON
Google Play
▀▀▀▄











▄▄▄▀
DannyHamilton
Legendary
*
Online Online

Activity: 3486
Merit: 4832



View Profile
December 18, 2022, 06:20:36 PM
Merited by LoyceV (6), vapourminer (2)
 #43

I don't know if different private keys can still give the same pubkey though.

I'm not an expert in Elliptic Curve Cryptography, but it seems like it would be a pretty big problem if 2 different private keys each resulted in the same public key?

I say that because my understanding is that the private key is an integer that indicates how many times to add the base point, and that the public key is just the coordinates of the point you end up at after completing that addition.

Doesn't that imply that if private key X and private key Y have the same public key (arrive at the same point), then private key X+1 and private key Y+1 would ALSO be matching public keys?  More importantly, for ANY integer N, X+N and Y+N would be matching public keys?

Even worse, assuming that Y is the SMALLEST private key that generates a repeat public key, that would imply that there is a cycle of exactly Y-X private keys that simply repeats over and over throughout ALL the remaining private keys.  That would mean that the effective private key range would not be the order of the chosen elliptic curve, but rather the potentially MUCH smaller value Y-X.

In reality, after a bit more thought, saying that 2 different private keys result in the same public key implies that there are 2 different points on the curve X and Y for which a straight line drawn through X and the base point hits the curve at the exact same place as a line drawn through Y and the base point.  Given the way that straight lines work, and how they only intersect elliptic curves at a maximum of 3 points, it seems the only way that can happen is if either X or Y IS the base point, meaning you've reached the order of the curve.

Sorry. Now that I've written all that (and worked through my thoughts as I went), I think I'm saying that I'm pretty confident that 2 different private keys within the range of the order of the curve can NOT both result in the same public key?
MikeJ_NpC
Member
**
Offline Offline

Activity: 107
Merit: 10

if you want to lie *cough*use your data; not mine.


View Profile
December 18, 2022, 06:40:37 PM
 #44

does that apply for pubkeys  as well ?
See Bitaddress.org > Wallet Details: Pubkeys are 130 characters HEX (or 66 compressed), private keys are only 64 characters HEX. That means there are 256 times more pubkeys than privkeys. I don't know if different private keys can still give the same pubkey though.

okay i understand that ... but what about 02 and 03 pubkey (compressed) being identical?  resulting in the same address...   dont know the private key.
02abcd1234567
03abcd1234567
would this not be a example of inverse relation on the curve? They are 2 different points correct?
one is a lower bit than the other which is the only difference.
 
Ive just never seen 02 and 03 being the same ... until recent

If Karma is a bitch, then god is a woman. I ask to know, not to be screwed or hear trite excuses (after the fact) which a 3rd grader could do better on. If you give your word, keep it atleast..
o_e_l_e_o
In memoriam
Legendary
*
Offline Offline

Activity: 2268
Merit: 18746


View Profile
December 18, 2022, 07:16:53 PM
Merited by vapourminer (2), pooya87 (2)
 #45

does it decrease by 1/2 on every step?
Given that Base58 has 58 characters, then there is a roughly 1 in 58 chance for the next character to match the preceding one. I say roughly because you are encoding a hex number in Base58 so it is not an exact process, and there are limits on the range of addresses.

Also does it have any meaning if you have a 02 publickey and 03 publickey .. but  are a identical with the the exception of 02 03 - they result in the same btc address
This should not happen. It could happen, but would mean you had found the world's first SHA256 or RIPEMD160 collision. Exponentially more likely than that is that either you or the software you are using have made a mistake.

I don't know if different private keys can still give the same pubkey though.
They can not. Ignoring the distinction between compressed and uncompressed public keys for a moment, then there is a one to one relationship between private keys and public keys.

okay i understand that ... but what about 02 and 03 pubkey (compressed) being identical?  resulting in the same address...   dont know the private key.
They should not result in the same address. Can you share these two pubkeys so we can check?

02abcd1234567
03abcd1234567
would this not be a example of inverse relation on the curve? They are 2 different points correct?
one is a lower bit than the other which is the only difference.
It is not simply a lower bit. The 0x02 bit tells us that the omitted y coordinate is even, while 0x03 tells us it is odd. This means these are two separate points on the curve, with the same x coordinate, but the y coordinate reflected over the x axis.

By negating the private key (modulo n), you negate the public key. This means your two keys 02abcd1234567 and 03abcd1234567 come from two different private keys, which are the negation of each other.

Note none of this applies to newer taproot public keys, which only use even y coordinates and omit the parity byte altogether.
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!