Topic: PubKeys, Signatures and PubKeyHash visibility on the Blockchain by output format (Read 920 times)

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.


This reads as

Push the signature onto the stack


Push the PubKey onto the stack


Duplicate the top element on the stack


Apply Hash160 to the top element on the stack


Push PubKeyHash onto the stack


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.


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


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

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.

Good that's what I thought.


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


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


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

Thanks a lot DannyHamilton this is very helpful.

[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:
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:
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:
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:
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:
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:
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.