PubKeys, Signatures and PubKeyHash visibility on the Blockchain by output format

[No_2]

[Edit: this post has been edited to make the final contents as correct as possible]

I want to check what information I can see with only a view of the blockchain for each type of transaction input and output. Forgive me if this is a duplicate post but I can't find a definitive answer to this on-line as most items I've found are concerned with demonstrating the execution of scripting, rather than what types and formats of data are stored in each transaction input and output once the block containing them is mined to the chain e.g. if it's the public key or a hash of the public key which are very different things.


P2PKH

Valid inputs and outputs will contain the following.

Previous Transaction Output: Specifies a hash of the public key in the redeem scrip who's public key signature is needed to redeem the funds specified in this output.

This is formatted and stored on the block chain as follows:

Code:

OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

PubKeyHash is a hash of the public key. Therefore unless this transaction has been redeemed its full public key won't be known. The address of this output is the PubKeyHash with a checksum appended, base58 encoded with a '1' prepended.

Next Transaction Input: Contains the public key and corresponding signature of the relevant parts of this transaction. Both of these are provided in their full un-hashed forms.

This is formatted and stored on the block chain as follows:

Code:

<SigOfThisTransaction> <PubKey> 

The signature of the transaction and public key are stored in their full un-hashed forms. When these are used with the scrip of the previous output it evaluates to true. Therefore all information is present on the blockchain to verify this.


P2PKH Multisig

Valid inputs and outputs will contain the following.

Previous Transaction Output: Specifies 'n' hashes of public keys in the redeem scrip were 'm' public key signatures are needed to redeem the funds specified in this output.

This is formatted and stored on the block chain as follows:

Code:

OP_2 <PubKeyHash1> <PubKeyHash2> <PubKeyHash3> OP_3 OP_CHECKMULTISIG

These are stored as hashes of the public keys. This type of output has no address.

Next Transaction Input: Contains 'm' public keys and corresponding signatures of the relevant parts of this transaction. These public keys and signatures are provided in their full un-hashed forms.

This is formatted and stored on the block chain as follows:

Code:

OP_0 <Sig1OfThisTransaction> <PubKey1> <Sig2OfThisTransaction> <PubKey2> OP_4

The each signature of this transition and public key are stored in their full un-hashed forms. When these are used with the scrip of the previous output it evaluates to true. Therefore all information is present on the blockchain to verify this.


P2SH Multisig

Valid inputs and outputs will contain the following.

Previous Transaction Output: Specifies a hash of a second redeem script within this redeem scrip which is required in full in the next input with its satisfying conditions to claim the funds specified in this output.

This is formatted and stored on the block chain as follows:

Code:

OP_HASH160 <RedeemScriptHash> OP_EQUAL 

Here the hash of the redeem script specified in the P2SH script won't be known by looking at the blockchain unless it has been redeemed. The address of this output is the hash of the script plus checksum, base58 encoded with a '3' prepended.

Next Transaction Input: For P2SH  specifies the script for which the hash is stored in the output of the previous transaction. For Multisig this script will also specify the hashes of the public keys required to satisfy it. The redeeming script is also provides 'm' of the 'n' the public keys and corresponding signatures of the relevant parts of this transaction. Both the public keys and the signatures are provided in their full un-hashed forms.

This is formatted and stored on the block chain as follows:

Code:

OP_0 <Sig1OfThisTransaction> <Sig2OfThisTransaction> OP_2 <PubKey1> <PubKey2> <PubKey3> OP_3 OP_CHECKMULTISIG

Hashes of the public keys are not stored for P2SH multisig. The signatures of the transaction and public keys are stored in their full un-hashed forms. When these are used with the scrip it evaluates to true. Therefore all information is present on the blockchain to verify this.

I would be very grateful if anyone can point out any errors in the above.

[No_2]

PubKeyHash is a hash of the public key. Therefore unless this transaction has been redeemed its full public key won't be known.

If the user re-uses the address, then the public key may be known if any other outputs that were encumbered with the same signature requirement were already spent.

Good that's what I thought.

Specifies 'n' hashes of public keys in the redeem scrip were 'm' public key signatures are needed to redeem the funds specified in this output.

This is formatted and stored on the block chain as follows:

Code:

OP_2 <PubKeyHash1> <PubKeyHash2> <pubKeyHash3> OP_3 OP_CHECKMULTISIG

Are these stored as public keys or hashes of the public keys?

Um?  Didn't you already answer that question?  You said "Specifies 'n' hashes of public keys"  That means "hashes" doesn't it?

So they are stored as PubKeyHashes? Assuming that's correct I've edited the first post to keep it correct.

How is the address for this output generated?

This type of transaction doesn't have an address.  Various tools may choose to try to convert various portions of the script into a hash that it presents as an "address", but there is no single standard for how to represent this script as an address.

Ah, thanks. I had real trouble finding an answer to this one.

These are the immediate issues I see after quickly looking at what you've said here.  It's possible there may be other issues.  I'll give it a closer look in a few hours.

I've guessed a few of the OP codes, hope I've got those right.

Thanks a lot DannyHamilton this is very helpful.

[No_2]

So if I've understood this correctly between a P2SH multisig output and its redeeming input on the next transition the public key hashes will never be exposed to the network or when it is written to the blockchain.

It may seem an odd point but I thought that one security feature of Bitcoin was that public keys are not exposed before a transaction is redeemed. However in the case where a P2SH multisig address needs to be verified by other parties the public keys must be viewed by other parties.

It's probably a minor point but this then increases the risk if an ECDSA exploit using public keys was ever found.

[TierNolan]

There is no multisig version of pay to public key hash.  OP_CHECKMULTISIG doesn't take key hashes.  In the standard pay to public key hash for single signatures, the script does the check against the hash.  It isn't part of OP_CHECKSIG.

This is the full script when spending the output.

The | symbol is used to indicate the split between the scriptSig and scriptPubKey, but doesn't do anything.

Code:

<SigOfThisTransaction> <PubKey> | OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

This reads as

Push the signature onto the stack

Code:

<SigOfThisTransaction>

Push the PubKey onto the stack

Code:

<PubKey>
<SigOfThisTransaction>

Duplicate the top element on the stack

Code:

<PubKey>
<PubKey>
<SigOfThisTransaction>

Apply Hash160 to the top element on the stack

Code:

Hash(<PubKey>)
<PubKey>
<SigOfThisTransaction>

Push PubKeyHash onto the stack

Code:

<PubKeyHash>
Hash(<PubKey>)
<PubKey>
<SigOfThisTransaction>

Verify the top 2 elements are equal (PubKeyHash = Hash(PubKey)) and remove them

This step confirms that the public key properly hashes to the expected public key hash.  The script will immediately fail at this point if the hash doesn't match the expected value.

Code:

<PubKey>
<SigOfThisTransaction>

Check the signature against the public key.  Remove the 2 elements and if the signature is valid, push OP_TRUE onto the stack

Code:

OP_TRUE

The script is successful if the top element on the stack is non-zero when it ends.