2

What if I had a scriptPubKey of 

<pubKey>OP_CHECKSIG

And an scriptSig of

<sig>

Question

  1. Would that work in the standard client?

  2. Why do we need to check the hash?

The only possible reason I could come up with is that it makes a DDOS much more difficult since people aren't flooding the network with invalid signatures that eats up the CPU, and a hash is relatively inexpensive.

If the explanation I have is correct, is it documented anywhere?

The wiki says that that the pay to pub key hash is to prevent a break in the ECDSA algorithm, but I wonder what the real answer might be.

| improve this question | |
  • Interestingly, the use of the hash also uses extra space in the blockchain, since the public key has to appear in the spending transaction anyway. On the other hand, without the hash, you'd use the public key as your address; it's about 60% longer, which might be a little inconvenient. – Nate Eldredge Mar 11 '14 at 3:22
  • Protection against an attack on ECDSA seems a perfectly reasonable explanation; why do you doubt it? – Nate Eldredge Mar 11 '14 at 3:25
1

Exposing your public key does weaken the security a bit. That is why it is recommended that you do not reuse addresses since your public key is exposed when you sign the first transaction spending money from that address. Using Pay-To-PubKey instead of Pay-To-Pubkey-Hash exposes your public key immediately.

| improve this answer | |
  • That is a reason, but not the primary one, or the reason it was done originally. – Pieter Wuille Apr 3 '14 at 18:40
4

This is the standard pay-to-pubkey script, which was the original "standard script" for a while, and is still used if you'd solo mine from within bitcoind.

Originally, Bitcoin transactions were intended to use pay-to-IP, where the "address" was an IP address, and the public key to pay to was computed on the fly when requested by the sender. These transactions used pay-to-pubkey scripts.

Pay-to-IP became deprecated and eventually removed quickly, mostly because of security reasons (man-in-the-middle), and the "workaround" (intended for when the recipient was offline) pay-to-pubkeyhash took over, with several unfortunate side effects (address reuse, no comments on transactions, ...). Hopefully the Payment Protocol (BIP 70-72) can bring these back.

There are other reasons for preferring pay-to-pubkeyhash instead of pay-to-pubkey, such as a very minor security advantage (before the pubkey is revealed, the attacker first needs a preimage attack on the hash, before starting to attack the EC key), and smaller effect on the UTXO set (the database every full node maintains in addition to the block chain).

| improve this answer | |
1

This is not useful because anyone can redeem it with a valid ECDSA signature signed under ANY key.

| improve this answer | |
  • You're right, I typed in the script wrong. I revised it. – goodguys_activate Mar 11 '14 at 4:36
  • Thanks but this script is only useful if people publish the public key instead of the address. Even after compression a pubkey is still 60% longer than an address. – uminatsu Mar 11 '14 at 15:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.