Why bother checking both public key and signature in P2PKH transactions?

Question

In a P2PKH pubkey script, first, the public key provided by the intended spender is verified to be correct and then this key is used to verify the spender's signature.

I wonder why just verifying the public key is not enough. The pubkey script contains a cryptographic hash of it, so reversing should be impossible and anyone wanting to spend the UTXO associated with that script needs to have the correct public key. Doesn't that already authenticate the spender sufficiently? I understand that signing is necessary in P2PK transactions, but with P2PKH, hashing and signing seems redundant to me.

Isn't mere hashing of the redeem script also used for authentication in P2SH? The pubkey script in P2SH just checks if the redeem script hashes to the correct value and then it already executes it. If hashing is taken to be secure in P2SH, why not also in P2PKH?

Answer 1

1) The addresses would obsolete after one use.

2) If someone does a Sybil attack, s/he can prevent the transactions from relaying (which may also happen now), but also s/he can make a fake transaction from that address and relay it, as the attacker knows what the preimage is.

3) Even without a Sybil attack, someone could take advantage from eventual orphaned blocks and grab the money from all transactions in them, by making a fake transaction for each one.

Answer 2

There is spending condition and ownership condition. The spending condition is set by the previous sender of the funds in the pubkey script: “proof that you can create the hash which belongs to this address”. With the one way hash function this proofs, that only “you” can be the individual, to further spend the funds. You explained it correctly with the hashing dependency.

The signature is used to proof, that the you are the rightful owner of the funds. Checksig would verify the ECDSA logic, and only your private key can generate the correct result.

In your last comment you stated, that signatures (multisig) are not verified at all. This is slightly incorrect. The redeemscript has the OP_Code 0xAE at the end, which checks the signature(s) for a specified number of pubkeys.

See also the answer here

Answer 3

There exists research in the field and a similar solution has been proposed in the literature; it's called Fawkescoin and suggests replacing ECDSA with a hash function and a secure timeline service, such as a blockchain.

There are a few disadvantages (practicality issues) to consider as already mentioned by MCCCS and pebwindkraft, and the majority of them, if not all, is related to one-time signatures, as MCCCS mentions

the addresses would obsolete after one use

Some examples of what can go wrong include:

1. Transaction does not go through, e.g. due to low fees or a malicious party preventing the transactions from relaying and then create a fake transaction from that address and relay this one to her own key (thanks to MCCCS)
2. A fork, then the same key has to be used for every forked version.
3. Orphaned blocks (thanks to MCCCS)
4. The situation is more tricky in multi-sig transactions. There is no obvious solution using just hashes in cases where multi-sig addresses are owned by untrusted parties (services like CoinJoin cannot work).
5. Advertise the same address for receiving funds, i.e. a website accepting donations in a single address. Then you will require to spend everything in one transaction (to sign only once) and even if you can tolerate this (unlikely), you are still prone to the aforementioned attacks.
6. If a proof of solvency is required (or proof of key/assets ownership), then one way is to sign on a challenge and prove you own the key. As mentioned already, you want to avoid re-signing by any means, so the above will reveal your pre-image.
7. If a script fails for whatever reason during verification, it effectively destroys the value associated with any input addresses as they will have their pre-image revealed.

Answer 4

Because that's the only way to tell the spender is the intended recipient. Knowledge of the public key alone is susceptible to man in the middle attack. If signatures were not checked, then when you broadcast a transaction to the network, there would be nothing to stop the first recipient of your transaction from simply copying your public key, throwing your transaction in the trash, and relaying their own new transaction spending your coins to themselves. The signatures are needed to authenticate.