Bitcoin scriptsig format
Multisig outputs allow to share control of bitcoins between several keys. When creating the script, one specifies the public keys that control the funds, and how many of those keys are required to sign off spending transactions to be valid. An output with N public keys of which M are required is called an m-of-n output For example, 2-of-3, 3-of-5, 4-of-4, etc.
Note that regular multisig outputs are rarely used nowadays. Pay to script hash outputs are scripts that contain the hash of another script, called redeemScript. To spend bitcoins sent in a p2sh output, the spending transaction must provide a script matching the script hash and data which makes the script evaluate to true.
This allows to defer revealing the spending conditions to the moment of spending. It also makes it possible for the receiver to set the conditions to spend those bitcoins. Most multisig transactions today use p2sh outputs where the redeemScript is a multisig output. Data outputs are used to push data into the blockchain. Up to 40 bytes can be pushed in a standard way, but more data can be used, if a miner decides to accept the transaction.
To create a custom Script instance, you must rely on the lower-level methods add and prepend. Both methods accept the same parameter types, and insert an opcode or data at the beginning prepend or end add of the Script.
Script has an easy interface to parse raw scripts from the network or bitcoind, and to extract useful information. An illustrative example for more options check the API reference. To validate a transaction, the bitcoin network validates all of its inputs and outputs. To validate an input, the input's script is concatenated with the referenced output script, and the result is executed. If at the end of execution the stack contains a 'true' value, then the transaction is valid.
You can do this in bitcore by using the Interpreter class. The entry point and probably the only interface you'll need for most applications is the method Interpreter verify. Note that verify expects two scripts: This is because different conditions are checked for each. Bitcoin transactions contain scripts. Each input has a script called the scriptSig, and each output has a script called the scriptPubkey. If at the end of execution the stack contains a "true" value, then the transaction is valid.
Verifies a Script by executing it and returns true if it is valid. This function needs to be provided with the scriptSig and the scriptPubkey separately. Based on bitcoind's EvalScript function, with the inner loop moved to Interpreter. Checks a locktime parameter with the transaction's locktime. There are two times of nLockTime: See the corresponding code on bitcoin core: Based on the inner loop of bitcoind's EvalScript function bitcoind commit: We'll also step through creating and spending a multisig transaction to make it all clearer.
In many ways, this is a follow up to Ken's amazing explanation of the Bitcoin protocol and constructing a Pay-to-PubKeyHash P2PKH transaction, so I won't cover things covered there in any great detail.
Please check out his post out first if you're completely new to the Bitcoin protocol. I'll be using go-bitcoin-multisig to generate keys and transactions along the way, explaining each step.
If you'd like to follow along and create a multisig transaction yourself, you'll need to follow the simple build instructions for go-bitcoin-multisig. To spend Bitcoin funds sent to this type of address, the recipient must use the private key associated with the public key hash specified in that address to create a digital signature, which is put into the scriptSig of a spending transaction, unlocking the funds.
This is because P2SH addresses have a version byte prefix of 0x05 , instead of the 0x00 prefix in P2PKH addresses, and these come out as a '3' and '1' after base58check encoding.
So what information is encoded in a P2SH address? A specific unspent Bitcoin can actually have a whole range of different spending conditions attached to it, the most common being a typical P2PKH which just requires the recipient to provide a signature matching the public key hash.
The Bitcoin core developers realized that people were looking at the capabilities of Bitcoin's Script language and seeing a whole array of possibilities about what spending conditions you could attach to a Bitcoin output, to create much more elaborate transactions than just P2PKH transactions.
The core developers decided that instead of letting senders put in long scripts into their scriptPubKey where spending conditions usually go , they would let each sender put in a hash of their spending conditions instead. These spending conditions are known as the redeem script , and a P2SH funding transaction simply contains a hash of this redeem script in the scriptPubKey of the funding transaction. The redeem script itself is only revealed, checked against the redeem script hash, and evaluated during the spending transaction.
This puts the responsibility of providing the full redeem script on to the recipient of the P2SH funds. This has a number of advantages:. All of this will hopefully make more sense as we go ahead and craft a multisignature P2SH transaction. If you'd like to learn more, the Bitcoin developer guide has a full explanation of P2SH transactions. We will create a 2-of-3 multisignature address, where 2 digital signatures of 3 possible public keys are required to spend funds sent to this address.
First we need the hex representations of 3 public keys. Now, we specify that we want a 2-of-3 address and provide our 3 public keys to generate our P2SH address:. Let's breakdown that redeem script since that is where all the magic happens. A valid multisignature redeem script, according to the Bitcoin protocol , looks like:. It contains a hashed redeem script with our chosen public keys and multisig script, but this will not be revealed publicly until the spending transaction, since it has been hashed.
We would at this point pass this address to the sender who is funding our multisig address. To fund our multisig address now, we need a funding source of Bitcoins. Note that the generated transaction changes slightly each time because of the nonce in the digital signatures and this may change the total size of the transaction slightly each time.