Verification w/ Public key recovery is never going to be faster than normal verification however it is only marginally slower. I benchmarked it a while back and it was only about 5% overhead to do pubkey recovery.

Changing the txn format would require a hard fork so it is unlikely that is going to happen but the advantage of pubkey recovery is that it trades storage for time. This could be useful for Bitcoin as processor power is less of a bottleneck than WAN bandwidth especially in residential 'last mile' scenarios.

A typical 2in, 2out P2PkH transaction is 373 bytes with compressed keys and 437 bytes using uncompressed keys). The same transaction without pubkeys would be 309 bytes resulting in a storage (bandwidth and memory) reduction of 17% to 29% in exchange for 5% increase in CPU time.

Hashing is extremely fast so performing 4 hashes vs 1 hash is negligible but a single byte can remove that overhead. The protocol would require using a flag with the signature to indicate which form to use when recovering the PubKey.

0x02 = compressed even
0x03 = compressed odd
0x04 = uncompressed even
0x05 = uncompressed odd

This really only saves significant space in P2PkH transactions. For P2SH (i.e. multisig) the script is very likely to contain full pubkeys instead of keyhashes.

If we were ever going to redesign txns I would go with Schnorr signatures as they support thresholding signatures. This would reduce the signature size from one or more per input to one per transaction.

Verification w/ Public key recovery is never going to be faster than normal verification however it is only marginally slower. I benchmarked it a while back and PubKey recovery added about 5% overhead.

Changing the txn format would require a hard fork so it is unlikely that is going to happen but the advantage of pubkey recovery is that it trades storage for time. This could be useful for Bitcoin as processor power is less of a bottleneck than WAN bandwidth especially in residential 'last mile' scenarios.

A typical 2in, 2out P2PkH transaction is 373 bytes with compressed keys and 437 bytes using uncompressed keys). The same transaction without pubkeys would be 309 bytes resulting in a storage (bandwidth and memory) reduction of 17% to 29% in exchange for 5% increase in CPU time.

Hashing is extremely fast so performing 4 hashes vs 1 hash is negligible but a single byte can remove that overhead. The protocol would require using a flag with the signature to indicate which form to use when recovering the PubKey.

0x02 = compressed even
0x03 = compressed odd
0x04 = uncompressed even
0x05 = uncompressed odd

This really only saves significant space in P2PkH transactions. For P2SH (i.e. multisig) the script is very likely to contain full pubkeys instead of keyhashes.

While using PubKey recovery initially would have made sense the cost in terms of needing a hardfork doesn't make that change very viable. If putting a hardfork on the table there are a lot of more interesting things that could be done instead. For example switching from ECDSA to Schnorr signatures would allow native thresholding signatures. This would reduce the number of signatures from one (or more in the case of multisig) per input to just one per transaction. As 64 bytes each that would really add up.

Verification w/ Public key recovery is never going to be faster than normal verification however it is only marginally slower. I benchmarked it a while back and it was only about 5% overhead to do pubkey recovery.

Changing the txn format would require a hard fork so it is unlikely that is going to happen but the advantage of pubkey recovery is trades storage for time. A typical 2in, 2out P2PkH transaction is 373 bytes with compressed keys (437 bytes w/ uncompressed keys). The same transaction without pubkeys would be 309 bytes so a savings of 17% to 29% in exchange for 5% slower verification.

Hashing is extremely fast so performing 4 hashes vs 1 hash is negligible but that overhead can be removed by adding a flag to the signature to indicate which form to use when recovering the PubKey.

0x02 = compressed even
0x03 = compressed odd
0x04 = uncompressed even
0x05 = uncompressed odd

This really only saves space in P2PkH transactions. For P2SH (i.e. multisig) the script contains full pubkeys already. While in theory new OP_CODES could be used to support multisig using key hashes there isn't much space saved.

If we were ever going to redesign txns I would go with Schnorr signatures as they support thresholding signing. That would mean only one signature per txn vs one or more signatures per input as used now.

Verification w/ Public key recovery is never going to be faster than normal verification however it is only marginally slower. I benchmarked it a while back and it was only about 5% overhead to do pubkey recovery.

Changing the txn format would require a hard fork so it is unlikely that is going to happen but the advantage of pubkey recovery is that it trades storage for time. This could be useful for Bitcoin as processor power is less of a bottleneck than WAN bandwidth especially in residential 'last mile' scenarios.

A typical 2in, 2out P2PkH transaction is 373 bytes with compressed keys and 437 bytes using uncompressed keys). The same transaction without pubkeys would be 309 bytes resulting in a storage (bandwidth and memory) reduction of 17% to 29% in exchange for 5% increase in CPU time.

Hashing is extremely fast so performing 4 hashes vs 1 hash is negligible but a single byte can remove that overhead. The protocol would require using a flag with the signature to indicate which form to use when recovering the PubKey.

0x02 = compressed even
0x03 = compressed odd
0x04 = uncompressed even
0x05 = uncompressed odd

This really only saves significant space in P2PkH transactions. For P2SH (i.e. multisig) the script is very likely to contain full pubkeys instead of keyhashes.

If we were ever going to redesign txns I would go with Schnorr signatures as they support thresholding signatures. This would reduce the signature size from one or more per input to one per transaction.