An overview of private key and compressed / uncompressed public keys

gistfile1.txt

An overview of private key and derivation of compressed and uncompressed public key and its belonging corresponding addresses on utxo coins such as Bitcoin or Hush. Example was demonstrated on Hush mainnet network as of short same transaction type construction, short blocktime and cheap fees.

private key a8db568957aab4d708fa1cde6b3c19c14674d5ffe283REDACTEDREDACTEDREDA

t1W9D96R9hk8vtyuHdajwtDzSDRRtnXacT3 - address from uncompressed public key, private key in WIF from uncompresseed 5K6eoShWWsgptas3XYGL34xcj66Bn1tREDACTEDREDACTEDREDA
04317b3fd39dd25719563f46534e6d9779695ef3b5b8886c2293fc79e0c5c3283635c386d467ce6035c9862330f33dead77527b77474012410b3a26f1e7ed33447 - uncompressed pubkey

t1UPSwfMYLe18ezbCqnR5QgdJGznzCUYHkj - address from compressed public key, private key in WIF from compressed L2swqzRoGrinNgTt9nzf28UUgmTtZgtpfREDACTEDREDACTEDREDA
03317b3fd39dd25719563f46534e6d9779695ef3b5b8886c2293fc79e0c5c32836 - compressed pubkey


So from one private key we can obtain 2 public keys (compressed and uncompressed format). Those result in different address.
When a payment is made to an address the public key is not known only the address. Public key is revealed only when an address is used for spending. 
So prior that we do not know if an address is belonging to uncompressed or compressed public key. The assumption that is being used is that it is compressed as of todays standards.

An example of transaction: https://explorer.hush.zelcore.io/tx/4950305a39c74e8a55b1180d849751596692e01f14bdab7c33b614027aef7872
In this transaction an address which comes from uncompressed public key is sending to an address derived from compressed public key. Note that BOTH of these addresse belong to the SAME private key.
But the WIF format of the private key is different. The WIF format is different so wallets/core can distinguish if the public part is compressed or uncompressed and choose a correct signing method.
-> Only 1 private key is needed to unlock and spend utxos from both addresses but a specification of compression has to be used to correctly sign transaction.

Here is another example transaction: https://explorer.hush.zelcore.io/tx/84b89f4cdc586a6179a94b8a494a76c60dabb17a227897ad92024c3572bf358d
Here our address coming from compressed public key pays to address belonging to uncompressed public key. Note that the same private key is used for signing.
-> 1 private key rules 2 different addresses

-> the type is always pay to public key hash. 

Transaction where our address t1UPSwfMYLe18ezbCqnR5QgdJGznzCUYHkj coming from compressed public key pays to uncompressed public key 04317b3fd39dd25719563f46534e6d9779695ef3b5b8886c2293fc79e0c5c3283635c386d467ce6035c9862330f33dead77527b77474012410b3a26f1e7ed33447. 
-> the type is pay to public key. Change type coming back to t1UPSwfMYLe18ezbCqnR5QgdJGznzCUYHkj is p2pkh
https://explorer.hush.zelcore.io/tx/a8ec1ec003f446cd754921814c3d650876ff0eaeccf9061590135055b2f8aceb
However in the list of transaction of an address t1W9D96R9hk8vtyuHdajwtDzSDRRtnXacT3 this transaction is not shown! https://explorer.hush.zelcore.io/address/t1W9D96R9hk8vtyuHdajwtDzSDRRtnXacT3
API of explorer is not showing the transaction correctly - the type there is pubkeyhash. However if we decode it using daemon we are obtaining it correctly
https://pastebin.com/WwKvxeye

And to complete it, There is a transaction spending this utxo
https://explorer.hush.zelcore.io/tx/8903db74b78e5ed8ef493ddd9d1794164fcd672cfb60d38f7b5fc8d826477e38
As you can see that input is shown as coming from unparsed address (from the uncompressed public key) even though its the same as the uncompressed address t1W9D96R9hk8vtyuHdajwtDzSDRRtnXacT3. Explorer just does not know that