Two questions about bitcoin public key

[javadsalehi]

1. Why doesn't any public key contain "zero" ?
2. As far as I know there is no difference between uppercase and lowercase letters when we make a transaction. So, why are there both uppercase and lowercase letters in the public key when they are shown on different block explorers?

[1714645506]

1714645506

[Rath_]

1. Why doesn't any public key contain "zero" ?

Bitcoin addresses are encoded in a way which makes it easier for a human to read them. Zero could be mistaken for 'o'. The public key itself can contain zero.

Bitcoin addresses are implemented using the Base58Check encoding of the hash of either:
Pay-to-pubkey-hash (p2pkh): payload is RIPEMD160(SHA256(ECDSA_publicKey)) where ECDSA_publicKey is a public key the wallet knows the private key for

Here's an example of an ECDSA publicKey - 0250863ad64a87ae8a2fe83c1af1a8403cb53f53e486d8511dad8a04887e5b2352

2. As far as I know there is no difference between uppercase and lowercase letters when we make a transaction.

There is a difference. Only native SegWit addresses (the ones starting with bc1) are not case sensitive. They are encoded in a different way.

[aundroid]

1. Why doesn't any public key contain "zero" ?

As far as I know, the Base58 encoding removes all the characters 0, O, I, l

2. As far as I know there is no difference between uppercase and lowercase letters when we make a transaction. So, why are there both uppercase and lowercase letters in the public key when they are shown on different block explorers?

only bech32 type addresses (starting with bc1) are case-INsensitive, the others are case sensitive.

[o_e_l_e_o]

As far as I know, the Base58 encoding removes all the characters 0, O, I, l

It also removes the characters "+" and "/" when compared to the more familiar Base64.

A key is just a long number. It can be expressed in any base you like. You could use Base10 if you wanted, or even Base2, in which case there would be loads of zeroes. We use Base58 to make the number shorter, more easily readable, and reduce the chance of mistaken characters as above.

Bech32 addresses use a custom character set of 32 characters - all case insensitive letters (26) and numbers (10), minus "1", "b", "i" and "o" (outside of the first 3 characters "bc1", known as the human readable part and the separator). This has the advantage of being impossible to make mistakes regarding upper or lower case, as well as generating smaller QR codes. You can read more about this in BIP 173.

[javadsalehi]

Bech32 addresses use a custom character set of 32 characters - all case insensitive letters (26) and numbers (10), minus "1", "b", "i" and "o" (outside of the first 3 characters "bc1", known as the human readable part and the separator). This has the advantage of being impossible to make mistakes regarding upper or lower case, as well as generating smaller QR codes. You can read more about this in BIP 173.

So, characters that are excluded in generating Bech32 and P2PKH addresses are different.
Bech32: 1 , b , i , o
P2PKH: O , I ( uppercase letter) , l (lowercase letter) , 0
Am I right?
I wonder why "b" and "i" are excluded in Bech32 addresses. I think uppercase letter "I" and lowercase letter "l" can cause visual ambiguity much more than "b" and "i". Every one will distinguish "b" and "i" from other characters easily.

[o_e_l_e_o]

Bech32: 1 , b , i , o
P2PKH: O , I ( uppercase letter) , l (lowercase letter) , 0
Am I right?

Yes, this is correct.

I wonder why "b" and "i" are excluded in Bech32 addresses. I think uppercase letter "I" and lowercase letter "l" can cause visual ambiguity much more than "b" and "i". Every one will distinguish "b" and "i" from other characters easily.

You can read about the reasoning behind excluding those characters here in the BIP 173 link I posted above:

The character set is chosen to minimize ambiguity according to this visual similarity data, and the ordering is chosen to minimize the number of pairs of similar characters (according to the same data) that differ in more than 1 bit

Also see this quote from Greg Maxwell:

We did, the character set does not include "1", "b", "i", or "o"; which is the unique selection which minimizes the number of visually confusing pairs, at least given the NIST visual confusion data we had available to us at the time.

By excluding "1" and "i" you remove the confusion with "l". By excluding "o", you remove the confusion with "0". By excluding "b", you remove any confusion with "h" or "6", or in case of using all uppercase, "B" and "8".