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.