P2PUBKEY in witness program (P2WPUBKEY)

Question

Old standard transactions format included 3 types: P2PUBKEY, P2PKH, P2SH. After Segwit soft fork, we have got 2 additional types: P2WPKH and P2WSH.

If we compare the cost of spending inputs (in bytes we write on HDD) for P2PUBKEY, P2PKH, and P2WPKH and we got next values:

• P2PUBKEY 33 bytes public key(we do not consider uncompressed keys) + signature 72 bytes = 105 bytes
• P2PKH 20 bytes public key hash + 33 bytes public key + 72 bytes signature = 125 bytes
• P2WPKH 20 bytes public key hash + 33 bytes public key + 72 bytes signature = 125 bytes

From this comparison, we can conclude that P2PUBKEY the best for reducing blockchain size. We can save about 19% of spending input size. I understand that P2PKH give more security in case we do not reuse the address. If we reuse address, there are no advantages to use P2PKH. We can observe the quite frequent use of addresses repeatedly. For a specific range of tasks, we do not need extra security like P2PKH. Why in Segwit transaction types we don't have the ability to use P2WPUBKEY as standard transaction? This type of transaction help to reduce blockchain size in case a user does not need/want use "no address reuse" security model? 20 bytes for each input this is a good opportunity to save the size of the blockchain.

Also, I read this thread https://bitcointalk.org/index.php?topic=6430.0, what is the reason why bitcoin core developers do not want to use public key recovery and save 33 bytes for each input? If the concerns are related to performance, we can observe how the ethereum works and reaches about 1M tx per day (this is like 1M inputs per day in Bitcoin).

Answer 1

If the concerns are related to performance, we can observe how the ethereum works and reaches about 1M tx per day (this is like 1M inputs per day in Bitcoin).

Ethereum is really not a good comparison considering that it is impossible to sync a fully validating archival Ethereum node.

Regardless, the concern isn't just "performance" but rather Denial of Service attack risk. Performing pubkey recovery is much more computationally expensive than computing a hash of something. Thus there is potentially a DoS attack where an attacker creates many transactions with invalid signatures which a node then has to perform pubkey recovery on only to discard the transaction because it is invalid. By requiring a node to do a lot of computations on invalid transactions, it can be prevented from doing any verification of actual transactions thus preventing the node from actually doing its job.

With key hashes, this is less of a risk because the attacker needs to know the pubkey in order to get a node to break on the invalid signature step. Thus an attacker could not just use any output that has the same format (as you could with any output using key recovery) but has to use specific outputs which he knows the pubkeys for which limits how many of these transactions can be created.