<p>1) The addresses would obsolete after one use.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2018-03-18T09:42:50.570Z
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
CC BY-SA 3.0
2018-03-18T09:55:54.487Z
@Downvoter I'll simplify both 1 and 2: After the hash's input (preimage) gets revealed, anyone can steal the address's bitcoins.
MCCCS
CC BY-SA 3.0
2018-03-18T10:00:26.757Z
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
CC BY-SA 3.0
2018-03-18T11:06:40.497Z
@Downvoter That’s why signatures exist. P2SH verifies the signature too.
MCCCS
CC BY-SA 3.0
2018-03-18T11:34:25.820Z
[Here](https://bitcoin.org/en/developer-guide#standard-transactions), 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
CC BY-SA 3.0
2018-03-18T12:50:22.543Z
@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
CC BY-SA 3.0
2018-03-18T21:49:10.987Z
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.
Ava Chow
CC BY-SA 4.0
2023-10-18T22:32:09.587Z
@cadaniluk Sure, anyone can pretend to be the owner. But so what? If I can pretend to be the owner but can only submit the very same script as the actual owner, what harm can I do?
David Schwartz
CC BY-SA 3.0
2018-03-18T09:16:24.890Z
2018-03-18T12:55:08.207Z
2018-03-18T12:55:08.207Z
MCCCS
<p>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.</p>

<p>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.</p>

<p>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. </p>

<p>See also the <a href="https://bitcoin.stackexchange.com/questions/69062/why-does-bitcoin-uses-a-script-language/69077#69077">answer here</a></p>

CC BY-SA 3.0
2018-03-18T15:03:48.087Z
2018-03-18T15:03:48.087Z
pebwindkraft
<p>There exists research in the field and a similar solution has been proposed in the literature; it's called <a href="http://www.jbonneau.com/doc/BM14-SPW-fawkescoin.pdf" rel="nofollow noreferrer">Fawkescoin</a> and suggests replacing ECDSA with a hash function and a secure timeline service, such as a blockchain.</p>

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

<blockquote>
  <p>the addresses would obsolete after one use</p>
</blockquote>

<p>Some examples of what can go wrong include:</p>

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

CC BY-SA 3.0
2018-03-18T20:40:10.437Z
2018-03-18T20:46:02.870Z
2018-03-18T20:46:02.870Z
Kostas Kryptos
<p>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.</p>

CC BY-SA 3.0
2018-03-18T16:20:57.857Z
2018-03-19T12:01:13.360Z
2018-03-19T12:01:13.360Z
RBF06
<p>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.</p>

<p>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.</p>

<p>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?</p>

<transactions><signature><p2sh><authentication><p2pkh>
Why bother checking both public key and signature in P2PKH transactions?
cadaniluk
# Why bother checking both public key and signature in P2PKH transactions?

(Asked by: username_0 on 2018-03-18)

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?

**Tags:** transactions, signature, p2sh, authentication, p2pkh


---

## 4 answers

### Answer by username_1 on 2018-03-18. Score: 2 | Accepted answer

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.

> **Comments:**
> **username_0**: 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. ^^  
> **username_1**: @Downvoter I'll simplify both 1 and 2: After the hash's input (preimage) gets revealed, anyone can steal the address's bitcoins.  
> **username_0**: 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?  
> **username_1**: @Downvoter That’s why signatures exist. P2SH verifies the signature too.  
> **username_0**: [Here](https://bitcoin.org/en/developer-guide#standard-transactions), 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?  
> **username_1**: @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.  
> **username_2**: 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.  
> **username_3**: @username_0 Sure, anyone can pretend to be the owner. But so what? If I can pretend to be the owner but can only submit the very same script as the actual owner, what harm can I do?  

---

### Answer by username_4 on 2018-03-18. Score: 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](https://bitcoin.stackexchange.com/questions/69062/why-does-bitcoin-uses-a-script-language/69077#69077)


---

### Answer by username_5 on 2018-03-18. Score: 0

There exists research in the field and a similar solution has been proposed in the literature; it's called [Fawkescoin](http://www.jbonneau.com/doc/BM14-SPW-fawkescoin.pdf) 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 *username_1* and *username_4*, and the majority of them, if not all, is related to one-time signatures, as username_1 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 username_1)
2. A fork, then the same key has to be used for every forked version.
3. Orphaned blocks (thanks to username_1)
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 by username_6 on 2018-03-18. Score: 0

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.


---

