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

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?

cadaniluk

Posted 2018-03-18T08:58:36.980

Reputation: 143

Answers

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.

MCCCS

Posted 2018-03-18T08:58:36.980

Reputation: 5 827

Could you elaborate a little on 1) and dumb down 2) for me, please or explain it otherwise? I don't see how 2) answers my question because I barely understand it. ^^ – cadaniluk – 2018-03-18T09:42:50.570

1@Downvoter I'll simplify both 1 and 2: After the hash's input (preimage) gets revealed, anyone can steal the address's bitcoins. – MCCCS – 2018-03-18T09:55:54.487

Thanks. So that rules out just using a public key for P2PKH, but doesn't P2SH also just verify the hash of a redeem script? So once that redeem script is known, can't anyone pretend to be the owner? – cadaniluk – 2018-03-18T10:00:26.757

1@Downvoter That’s why signatures exist. P2SH verifies the signature too. – MCCCS – 2018-03-18T11:06:40.497

Here, the pubkey script of P2SH is shown to be OP_HASH160 <Hash160(redeemScript)> OP_EQUAL. The signature script is <sig> [sig] [sig...] <redeemScript>, so signatures are passed, but they must not be verified at all, it seems. Only if the redeem script chooses to, they are verified. Isn't that super unsecure if someone misses to verify signatures in the redeem script? – cadaniluk – 2018-03-18T11:34:25.820

@Downvoter 99% of the P2SH checks the signature. The 1% is special, rare, and called "Anyone Can Spend" scripts. No one "misses" to verify the signature. – MCCCS – 2018-03-18T12:50:22.543

In a P2SH input, the redeemScript is passed back through the script interpreter after it's hash has been checked. So when you create the input, you put the binary blob that is the redeemScript in the input. Then that blob is taken off of the stack and interpreted as a script itself. – Andrew Chow – 2018-03-18T21:49:10.987

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

pebwindkraft

Posted 2018-03-18T08:58:36.980

Reputation: 4 568

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.

RBF06

Posted 2018-03-18T08:58:36.980

Reputation: 148

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:

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)
A fork, then the same key has to be used for every forked version.
Orphaned blocks (thanks to MCCCS)
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).
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.
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.
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.

Kostas Chalkias

Posted 2018-03-18T08:58:36.980

Reputation: 146