Bitcoin Wiki - User contributions [en]

Payment channels

2019-07-18T04:54:20Z

Rusty: Broken reference URL, fixed

A '''Micropayment Channel''' or '''Payment Channel''' is class of techniques designed to allow users to make multiple Bitcoin transactions without commiting all of the transactions to the Bitcoin block chain.<ref name="bitcoinorg_dev_guide"/> In a typical payment channel, only two transactions are added to the block chain but an unlimited or nearly unlimted number of payments can be made between the participants.

Several channel designs have been proposed or implemented over the years. This article describes some of them. Many designs are vulnerable to [[Transaction Malleability|transaction malleability]]. Specifically, many designs require a way to be able to spend an unsigned transaction, in order to ensure that the channel can be opened atomically. Thus, these designs require a malleability fix that separates the signatures from the part of the transaction that is hashed to form the txid.

=== Nakamoto high-frequency transactions ===

Implemented in Bitcoin 0.1 were features such as [[Transaction Replacement|transaction replacement]]<ref name="replacement_in_original_code" />, input sequence numbers (nSequence), and [[nLockTime]] that would allow two or more parties to repeatedly update the state of an unconfirmed transaction prior to it becoming confirmed.

Satoshi Nakamoto described the technique to a Bitcoin developer in a personal email:<ref name="hearn_hft_quote" />

<blockquote>
An unrecorded open transaction can keep being replaced until nLockTime. It may contain payments by multiple parties. Each input owner signs their input. For a new version to be written, each must sign a higher sequence number (see IsNewerThan). By signing, an input owner says "I agree to put my money in, if everyone puts their money in and the outputs are this." There are other options in SignatureHash such as SIGHASH_SINGLE which means "I agree, as long as this one output (i.e. mine) is what I want, I don't care what you do with the other outputs.". If that's written with a high nSequenceNumber, the party can bow out of the negotiation except for that one stipulation, or sign SIGHASH_NONE and bow out completely.

The parties could create a pre-agreed default option by creating a higher nSequenceNumber tx using OP_CHECKMULTISIG that requires a subset of parties to sign to complete the signature. The parties hold this tx in reserve and if need be, pass it around until it has enough signatures.

One use of nLockTime is high frequency trades between a set of parties. They can keep updating a tx by unanimous agreement. The party giving money would be the first to sign the next version. If one party stops agreeing to changes, then the last state will be recorded at nLockTime. If desired, a default transaction can be prepared after each version so n-1 parties can push an unresponsive party out. Intermediate transactions do not need to be broadcast. Only the final outcome gets recorded by the network. Just before nLockTime, the parties and a few witness nodes broadcast the highest sequence tx they saw.
</blockquote>

This design was not secure:{{citation needed}} one party could collude with a miner to commit a non-final version of the transaction, possibly stealing funds from the other party or parties.

=== Spillman-style payment channels===

Discussed on the bitcoin-development mailing list<ref name="spillman_channel_description"/> and implemented in BitcoinJ,<ref name="channels_bitcoinj"/> this one transaction to create a secured deposit and a second transaction to release the deposit funds in the manner agreed to by both parties, preventing miners from being able to commit a non-final version of the transaction. However, opening a channel in the Spillman model exposed the depositor to malleability risk where the counter party would be able to hold the depositor's funds hostage.<ref name="bip65"/>

A full description of the protocol is in [[Contract#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party|example 7 of the Contract page]].

Spillman payment channels are unidirectional (there is a payer and a payee, and it is not possible to transfer money back in the reverse direction).

Spillman payment channels expire after a specific time, and the receiver needs to close the channel before the expiration.

=== CLTV-style payment channels ===

Were made possible in Decemember 2015 by the activation of the CLTV soft fork{{citation needed}} after discussion that began in the #bitcoin-wizards IRC channel{{citation needed}}, moved to the bitcoin-development and bitcoin-dev mailing lists<ref name="bitcoin_dev_bip65"/>, and included a design specification in [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65]. Channels constructed using the new OP_CLTV opcode were resistant to the malleability problem inherent in the Spillman-style construction.<ref name="bip65" />

Like Spillman payment channels, CLTV-style payment channels are unidirectional and expire after a specific time.

=== Poon-Dryja payment channels ===

Poon-Dryja payment channels were presented in the paper<ref name="ln_pdf">[https://lightning.network/lightning-network-paper.pdf Lightning Network paper, v0.5.9.1] Joseph Poon & Thaddeus Dryja ''Retrieved 2016-04-10''</ref> that also introduced the [[Lightning Network]]. Channel backing funds are locked into a 2-of-2 multisig, but before the funding transaction is even signed, commitment transactions for each party are first written and signed. As it requires referring to transactions that have not been signed yet, it requires using a transaction format that separates signatures from the part of the transaction that is hashed to generate the txid, such as [[Segregated Witness]].

Poon-Dryja channels may be closed unilaterally (requires the participation of only one party) or bilaterally (requires the participation of both parties). When closed bilaterally Poon-Dryja channels are indistinguishable on-chain from 2-of-2 multisig address spends. When closed unilaterally, the funds of the party that closed the channel is temporarily timelocked; this allows the other party to dispute the state transmitted by the closing party (who might have given old state on closing).

Poon-Dryja payment channels have indefinite lifetime. They are also bidirectional, unlike Spilman and CLTV payment channels.

The [https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md Lightning BOLT] specifications include recommended implementation of Poon-Dryja payment channels.

=== Decker-Wattenhofer duplex payment channels ===

Duplex payment channels were presented in a paper<ref name='duplex_pdf'>[https://tik-old.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels] Decker, C.; Wattenhofer, R.</ref> by Christian Decker and Roger Wattenhofer. This type of payment channel requires the new BIP68<ref name='bip68'>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68]</ref> meaning of nSequence. As the name implies, a duplex payment channel is composed of two unidirectional payment channels, one in both directions. The unidirectional payment channels are essentially Spillman channels, but using relative lock time (nSequence) instead of nLockTime.

However, instead of funding unidirectional payment channels directly from an on-chain funding transaction, there is an "invalidation tree" of off-chain transactions between the funding transaction and the payment channel finalization transactions. The invalidation tree transactions also use relative lock time; the first version of the transaction has a large relative lock time, and the next version of the transaction (which ''invalidates'' the first) uses a slightly smaller relative lock time, and so on. There is also a "kick-off" transaction that starts the timeout for the relative locktime. The sequence of transactions is thus: funding -> kickoff -> invalidation tree -> payment channel.

Initially, the invalidation transaction may have a relative lock time of 100 days, and then its outputs go to two unidirectional payment channels, one in either direction. Both parties may then use the payment channels until one channel is exhausted. The parties may then reset the payment channels, creating a new invalidation transaction with a relative lock time of 99 days that redistributes the money correctly, but with the unidirectional payment channels reset.

The payment channel may be closed at any time by either party (without the help of the other) by broadcasting the kickoff transaction on the blockchain. In case of such a unilateral close, both parties must wait out the relative lock times until they can broadcast the payment channel finalization transactions.

Parties should prefer the bilateral (cooperative) close, which collapses the kickoff, invalidation tree, and payment channel transactions into a single simple transaction that pays out the funds to both parties.

Duplex payment channels have indefinite lifetime, but there is a limit on number of updates possible due to the invalidation tree. This limit can be multiplied by adding additional layers to the invalidation tree, with resetting of the lower layers. Finally, in case of a unilateral close duplex payment channels require significant wait times and significant number of transactions to be published on the blockchain.

The invalidation tree structure may actually have more than two participants; it would be possible for groups of 3 or more parties to build multiple payment channels between them that are backed by this invalidation tree structure, and to rebalance their payment channels without hitting the blockchain.<ref name='scaling_funding_pdf'>[https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf Scalable Funding of Bitcoin Micropayment Channel Networks]</ref> It would also be possible for the invalidation tree structure to fund Poon-Dryja rather than pairs of unidirectional payment channels.

=== Decker-Russell-Osuntokun eltoo Channels ===

Eltoo channels were presented in a paper<ref name='eltoo_pdf'>[https://blockstream.com/eltoo.pdf eltoo: A Simple Layer2 Protocol for Bitcoin] Decker, C.; Russell, R., Osuntokun, O. '''Retrieved 2018-05-02'''</ref> by Christian Decker, Rusty Russell, and Olauluwa Osuntokun in April 30, 2018. This type of channel requires a new <code>SIGHASH_NOINPUT</code><ref name='bip_sighash_noinput'>[https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki <code>SIGHASH_NOINPUT</code>]</ref> signing flag.

Roughly, each update of the channel requires creating two transactions: an update transaction and a CSV-encumbered settlement transaction that spends the update transaction. Via <code>SIGHASH_NOINPUT</code> and an unusual use of <code>OP_CHECKLOCKTIMEVERIFY</code>, any later update transaction can spend any earlier update transaction during the time that the settlement transaction is encumbered; only the latest update transaction cannot be spent by another update transaction (since it has no later update) and can only be spent by its corresponding settlement transaction after the CSV delay has passed. Thus even if an attacker or disrupter publishes an old update transaction, it cannot get the old state published since the latest transaction can still be published while the CSV-delay on the old settlement transaction hasn't completed yet.

The <code>OP_CHECKLOCKTIMEVERIFY</code> is not used to enforce a particular future time, but rather to enforce an ordering on the update transactions, such that a later update transaction can spend an earlier update transaction, but not vice versa. This is because <code>OP_CHECKLOCKTIMEVERIFY</code> ensures that the spending transaction has a <code>nLockTime</code> equal to, '''or greater than''', the value specified in the spent output SCRIPT. Each update transaction's output SCRIPT has an "update" branch that allows any update transaction to spend it, as long as that update transaction has a higher <code>nLockTime</code> than it currently has. We use past <code>nLockTime</code> Unix timestamps, which start at 500,000,000 and reach up to about ~1,500,000,000 (somewhat less than the Unix timestamp as of time of writing), giving a limit of about 1,000,000,000 (1 billion) updates. If an old update transaction is spent, it will allow any later update transaction to spend it, thus preventing publication of old settlement transactions.

This has the advantage of not requiring a punishment branch (unlike Poon-Dryja), simplifying watchtower design and reducing the punishment of accidentally using old state (which would lead to total loss of funds under Poon-Dryja, but will only lead to wasting of fees in Decker-Russell-Osuntokun). However, it requires a new feature in the base blockchain (<code>SIGHASH_NOINPUT</code>).

=== Hashed Time-Locked Contracts (HTLCs) ===

''Full article: [[Hashed Timelock Contracts]]''

A technique that can allow payments to be securely routed across multiple payment channels.{{citation needed}} For example, if Alice has a channel open to Bob and Bob has a channel open to Charlie, Alice can use a HTLC to pay Charlie through Bob without any risk of Bob stealing the payment in transit. HTLCs are integral to the design of more advanced payment channels such as those used by the [[Lightning Network]].

=== References ===
<references>

<ref name="bitcoinorg_dev_guide">[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channel], Bitcoin.org Developer Guide</ref>

<ref name="replacement_in_original_code">[https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp#L434 Replacement in original Bitcoin code] Satoshi Nakamoto, GitHub</ref>

<ref name="hearn_hft_quote">[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002417.html Anti DoS for tx replacement], Mike Hearn, bitcoin-development mailing list, 17 April 2013</ref>

<ref name="spillman_channel_description">[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Re: Anti DoS for tx replacement], Jeremy Spillman, bitcoin-development mailing list, 20 April 2013</ref>

<ref name="channels_bitcoinj">[https://bitcointalk.org/index.php?topic=244656.0 Micro-payment channels implementation now in bitcoinj], Mike Hearn & Matt Corallo, BitcoinTalk.org, 27 June 2013</ref>

<ref name="bip65">[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65], Peter Todd, BIPs repository, retrieved 28 October 2016</ref>

<ref name="bitcoin_dev_bip65">[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011197.html [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!], Peter Todd, bitcoin-dev mailing list, 27 September 2015</ref>
</references>

[[Category:Technical]]

Script

2017-12-06T06:26:08Z

Rusty: OP_VERIFY removes top stack element.

Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, '''Script''' is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.

A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide
# a public key that, when hashed, yields destination address D embedded in the script, and
# a signature to show evidence of the private key corresponding to the public key just provided.

Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several, or even no keys at all.

A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). The party who originally ''sent'' the Bitcoins now being spent, dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero).

This document is for information purposes only. Officially Bitcoin script is defined by [https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp its reference implementation].

The stacks hold byte vectors.
When used as numbers, byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer.
Thus 0x81 represents -1.
0x80 is another representation of zero (so called negative 0).
Positive 0 is represented by a null-length vector.
Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.

== Opcodes ==
This is a list of all Script words, also known as opcodes, commands, or functions.

There are some words which existed in very early versions of Bitcoin but were removed out of a concern that the client might have a bug in their implementation. This fear was motivated by a bug found in OP_LSHIFT which could crash any Bitcoin node if exploited, and by other bugs in how Script worked which allowed anyone to spend anyone's bitcoins. The removed opcodes are sometimes said to be "disabled" opcodes, but this is something of a misnomer because there is ''absolutely no way'' for anyone using Bitcoin to use these opcodes (they simply ''do not exist anymore'' in the protocol), and there are also no solid plans to ever re-enable all of these opcodes. They are listed here only for historical interest.

New opcodes can be added by means of a carefully designed and executed [[softfork]] using OP_NOP1-OP_NOP10.

False is zero or negative zero (using any number of bytes) or an empty array, and True is anything else.

=== Constants ===
When talking about scripts, these value-pushing words are usually omitted.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_0, OP_FALSE
|0
|0x00
|Nothing.
|(empty value)
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)
|-
|N/A
|1-75
|0x01-0x4b
|(special)
|data
|The next ''opcode'' bytes is data to be pushed onto the stack
|-
|OP_PUSHDATA1
|76
|0x4c
|(special)
|data
|The next byte contains the number of bytes to be pushed onto the stack.
|-
|OP_PUSHDATA2
|77
|0x4d
|(special)
|data
|The next two bytes contain the number of bytes to be pushed onto the stack.
|-
|OP_PUSHDATA4
|78
|0x4e
|(special)
|data
|The next four bytes contain the number of bytes to be pushed onto the stack.
|-
|OP_1NEGATE
|79
|0x4f
|Nothing.
| -1
|The number -1 is pushed onto the stack.
|-
|OP_1, OP_TRUE
|81
|0x51
|Nothing.
|1
|The number 1 is pushed onto the stack.
|-
|OP_2-OP_16
|82-96
|0x52-0x60
|Nothing.
|2-16
|The number in the word name (2-16) is pushed onto the stack.
|}

=== Flow control ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_NOP
|97
|0x61
|Nothing
|Nothing
|Does nothing.
|-
|OP_IF
|99
|0x63
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the top stack value is not False, the statements are executed. The top stack value is removed.
|-
|OP_NOTIF
|100
|0x64
| colspan="2"|<expression> notif [statements] [else [statements]]* endif
|If the top stack value is False, the statements are executed. The top stack value is removed.
|-
|OP_ELSE
|103
|0x67
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not.
|-
|OP_ENDIF
|104
|0x68
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|Ends an if/else block. All blocks must end, or the transaction is '''invalid'''. An OP_ENDIF without OP_IF earlier is also '''invalid'''.
|-
|OP_VERIFY
|105
|0x69
|True / false
|Nothing / ''fail''
|'''Marks transaction as invalid''' if top stack value is not true. The top stack value is removed.
|-
|[[OP_RETURN]]
|106
|0x6a
|Nothing
|''fail''
|'''Marks transaction as invalid'''. A standard way of attaching extra data to transactions is to add a zero-value output with a scriptPubKey consisting of OP_RETURN followed by exactly one pushdata op. Such outputs are provably unspendable, reducing their cost to the network. Currently it is usually considered non-standard (though valid) for a transaction to have more than one OP_RETURN output or an OP_RETURN output with more than one pushdata op.
|}

=== Stack ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_TOALTSTACK
|107
|0x6b
|x1
|(alt)x1
|Puts the input onto the top of the alt stack. Removes it from the main stack.
|-
|OP_FROMALTSTACK
|108
|0x6c
|(alt)x1
|x1
|Puts the input onto the top of the main stack. Removes it from the alt stack.
|-
|OP_IFDUP
|115
|0x73
|x
|x / x x
|If the top stack value is not 0, duplicate it.
|-
|OP_DEPTH
|116
|0x74
|Nothing
|<Stack size>
|Puts the number of stack items onto the stack.
|-
|OP_DROP
|117
|0x75
|x
|Nothing
|Removes the top stack item.
|-
|OP_DUP
|118
|0x76
|x
|x x
|Duplicates the top stack item.
|-
|OP_NIP
|119
|0x77
|x1 x2
|x2
|Removes the second-to-top stack item.
|-
|OP_OVER
|120
|0x78
|x1 x2
|x1 x2 x1
|Copies the second-to-top stack item to the top.
|-
|OP_PICK
|121
|0x79
|xn ... x2 x1 x0 <n>
|xn ... x2 x1 x0 xn
|The item ''n'' back in the stack is copied to the top.
|-
|OP_ROLL
|122
|0x7a
|xn ... x2 x1 x0 <n>
|... x2 x1 x0 xn
|The item ''n'' back in the stack is moved to the top.
|-
|OP_ROT
|123
|0x7b
|x1 x2 x3
|x2 x3 x1
|The top three items on the stack are rotated to the left.
|-
|OP_SWAP
|124
|0x7c
|x1 x2
|x2 x1
|The top two items on the stack are swapped.
|-
|OP_TUCK
|125
|0x7d
|x1 x2
|x2 x1 x2
|The item at the top of the stack is copied and inserted before the second-to-top item.
|-
|OP_2DROP
|109
|0x6d
|x1 x2
|Nothing
|Removes the top two stack items.
|-
|OP_2DUP
|110
|0x6e
|x1 x2
|x1 x2 x1 x2
|Duplicates the top two stack items.
|-
|OP_3DUP
|111
|0x6f
|x1 x2 x3
|x1 x2 x3 x1 x2 x3
|Duplicates the top three stack items.
|-
|OP_2OVER
|112
|0x70
|x1 x2 x3 x4
|x1 x2 x3 x4 x1 x2
|Copies the pair of items two spaces back in the stack to the front.
|-
|OP_2ROT
|113
|0x71
|x1 x2 x3 x4 x5 x6
|x3 x4 x5 x6 x1 x2
|The fifth and sixth items back are moved to the top of the stack.
|-
|OP_2SWAP
|114
|0x72
|x1 x2 x3 x4
|x3 x4 x1 x2
|Swaps the top two pairs of items.
|}

=== Splice ===

If any opcode marked as disabled is present in a script, it must abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_CAT
|126
|0x7e
|x1 x2
|out
|style="background:#D97171;"|Concatenates two strings. ''disabled.''
|-
|OP_SUBSTR
|127
|0x7f
|in begin size
|out
|style="background:#D97171;"|Returns a section of a string. ''disabled.''
|-
|OP_LEFT
|128
|0x80
|in size
|out
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''disabled.''
|-
|OP_RIGHT
|129
|0x81
|in size
|out
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''disabled.''
|-
|OP_SIZE
|130
|0x82
|in
|in size
|Pushes the string length of the top element of the stack (without popping it).
|}

=== Bitwise logic ===

If any opcode marked as disabled is present in a script, it must abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_INVERT
|131
|0x83
|in
|out
|style="background:#D97171;"|Flips all of the bits in the input. ''disabled.''
|-
|OP_AND
|132
|0x84
|x1 x2
|out
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''disabled.''
|-
|OP_OR
|133
|0x85
|x1 x2
|out
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''disabled.''
|-
|OP_XOR
|134
|0x86
|x1 x2
|out
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''disabled.''
|-
|OP_EQUAL
|135
|0x87
|x1 x2
|True / false
|Returns 1 if the inputs are exactly equal, 0 otherwise.
|-
|OP_EQUALVERIFY
|136
|0x88
|x1 x2
|Nothing / ''fail''
|Same as OP_EQUAL, but runs OP_VERIFY afterward.
|}

=== Arithmetic ===

Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.

If any input value for any of these commands is longer than 4 bytes, the script must abort and fail.
If any opcode marked as ''disabled'' is present in a script - it must also abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_1ADD
|139
|0x8b
|in
|out
|1 is added to the input.
|-
|OP_1SUB
|140
|0x8c
|in
|out
|1 is subtracted from the input.
|-
|OP_2MUL
|141
|0x8d
|in
|out
|style="background:#D97171;"|The input is multiplied by 2. ''disabled.''
|-
|OP_2DIV
|142
|0x8e
|in
|out
|style="background:#D97171;"|The input is divided by 2. ''disabled.''
|-
|OP_NEGATE
|143
|0x8f
|in
|out
|The sign of the input is flipped.
|-
|OP_ABS
|144
|0x90
|in
|out
|The input is made positive.
|-
|OP_NOT
|145
|0x91
|in
|out
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.
|-
|OP_0NOTEQUAL
|146
|0x92
|in
|out
|Returns 0 if the input is 0. 1 otherwise.
|-
|OP_ADD
|147
|0x93
|a b
|out
|a is added to b.
|-
|OP_SUB
|148
|0x94
|a b
|out
|b is subtracted from a.
|-
|OP_MUL
|149
|0x95
|a b
|out
|style="background:#D97171;"|a is multiplied by b. ''disabled.''
|-
|OP_DIV
|150
|0x96
|a b
|out
|style="background:#D97171;"|a is divided by b. ''disabled.''
|-
|OP_MOD
|151
|0x97
|a b
|out
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''disabled.''
|-
|OP_LSHIFT
|152
|0x98
|a b
|out
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''disabled.''
|-
|OP_RSHIFT
|153
|0x99
|a b
|out
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''disabled.''
|-
|OP_BOOLAND
|154
|0x9a
|a b
|out
|If both a and b are not 0, the output is 1. Otherwise 0.
|-
|OP_BOOLOR
|155
|0x9b
|a b
|out
|If a or b is not 0, the output is 1. Otherwise 0.
|-
|OP_NUMEQUAL
|156
|0x9c
|a b
|out
|Returns 1 if the numbers are equal, 0 otherwise.
|-
|OP_NUMEQUALVERIFY
|157
|0x9d
|a b
|Nothing / ''fail''
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.
|-
|OP_NUMNOTEQUAL
|158
|0x9e
|a b
|out
|Returns 1 if the numbers are not equal, 0 otherwise.
|-
|OP_LESSTHAN
|159
|0x9f
|a b
|out
|Returns 1 if a is less than b, 0 otherwise.
|-
|OP_GREATERTHAN
|160
|0xa0
|a b
|out
|Returns 1 if a is greater than b, 0 otherwise.
|-
|OP_LESSTHANOREQUAL
|161
|0xa1
|a b
|out
|Returns 1 if a is less than or equal to b, 0 otherwise.
|-
|OP_GREATERTHANOREQUAL
|162
|0xa2
|a b
|out
|Returns 1 if a is greater than or equal to b, 0 otherwise.
|-
|OP_MIN
|163
|0xa3
|a b
|out
|Returns the smaller of a and b.
|-
|OP_MAX
|164
|0xa4
|a b
|out
|Returns the larger of a and b.
|-
|OP_WITHIN
|165
|0xa5
|x min max
|out
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.
|}

=== Crypto ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_RIPEMD160
|166
|0xa6
|in
|hash
|The input is hashed using RIPEMD-160.
|-
|OP_SHA1
|167
|0xa7
|in
|hash
|The input is hashed using SHA-1.
|-
|OP_SHA256
|168
|0xa8
|in
|hash
|The input is hashed using SHA-256.
|-
|OP_HASH160
|169
|0xa9
|in
|hash
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.
|-
|OP_HASH256
|170
|0xaa
|in
|hash
|The input is hashed two times with SHA-256.
|-
|OP_CODESEPARATOR
|171
|0xab
|Nothing
|Nothing
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.
|-
|[[OP_CHECKSIG]]
|172
|0xac
|sig pubkey
|True / false
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.
|-
|OP_CHECKSIGVERIFY
|173
|0xad
|sig pubkey
|Nothing / ''fail''
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.
|-
|OP_CHECKMULTISIG
|174
|0xae
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys>
|True / False
|Compares the first signature against each public key until it finds an ECDSA match. Starting with the subsequent public key, it compares the second signature against each remaining public key until it finds an ECDSA match. The process is repeated until all signatures have been checked or not enough public keys remain to produce a successful result. All signatures need to match a public key. Because public keys are not checked again if they fail any signature comparison, signatures must be placed in the scriptSig using the same order as their corresponding public keys were placed in the scriptPubKey or redeemScript. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.
|-
|OP_CHECKMULTISIGVERIFY
|175
|0xaf
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys>
|Nothing / ''fail''
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.
|}

=== Locktime ===
{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_CHECKLOCKTIMEVERIFY (previously OP_NOP2)
|177
|0xb1
|x
|x / ''fail''
|'''Marks transaction as invalid''' if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed. Transaction is also invalid if 1. the stack is empty; or 2. the top stack item is negative; or 3. the top stack item is greater than or equal to 500000000 while the transaction's nLockTime field is less than 500000000, or vice versa; or 4. the input's nSequence field is equal to 0xffffffff. The precise semantics are described in [[BIP 0065]]
|-
|OP_CHECKSEQUENCEVERIFY (previously OP_NOP3)
|178
|0xb2
|x
|x / ''fail''
|'''Marks transaction as invalid''' if the relative lock time of the input (enforced by [[BIP 0068]] with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in [[BIP 0112]].
|}

===Pseudo-words===
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.
{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Description
|-
|OP_PUBKEYHASH
|253
|0xfd
|Represents a public key hashed with OP_HASH160.
|-
|OP_PUBKEY
|254
|0xfe
|Represents a public key compatible with OP_CHECKSIG.
|-
|OP_INVALIDOPCODE
|255
|0xff
|Matches any opcode that is not yet assigned.
|}

=== Reserved words ===
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction '''invalid'''.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!When used...
|-
|OP_RESERVED
|80
|0x50
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_VER
|98
|0x62
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_VERIF
|101
|0x65
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''
|-
|OP_VERNOTIF
|102
|0x66
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''
|-
|OP_RESERVED1
|137
|0x89
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_RESERVED2
|138
|0x8a
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_NOP1, OP_NOP4-OP_NOP10
|176, 179-185
|0xb0, 0xb3-0xb9
|The word is ignored. Does not mark transaction as invalid.
|}

== Script examples ==
This is a list of interesting scripts. Keep in mind that all constants actually use the data-pushing commands above. Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.

=== Standard Transaction to Bitcoin address (pay-to-pubkey-hash) ===

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

To demonstrate how scripts look on the wire, here is a raw scriptPubKey:
<pre> 76 A9 14
OP_DUP OP_HASH160 Bytes to push

89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre>

Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.

Here is how each word is processed:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Obsolete pay-to-pubkey transaction ===

OP_CHECKSIG is used directly without first hashing the public key.
This was used by early versions of Bitcoin where people paid directly to IP addresses, before Bitcoin addresses were introduced.
scriptPubKeys of this transaction form are still recognized as payments to user by Bitcoin Core.
The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.

scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
|<sig> <pubKey> OP_CHECKSIG
|scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_CHECKSIG
|Constants are added to the stack.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Provably Unspendable/Prunable Outputs ===

The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:

scriptPubKey: OP_RETURN {zero or more ops}

OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the UTXO set even if it has not been spent. [http://blockexplorer.com/tx/eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29] is an example: it has a single output of zero value, thus giving the full 0.125BTC fee to the miner who mined the transaction without adding an entry to the UTXO set. You can also use OP_RETURN to add data to a transaction without the data ever appearing in the UTXO set, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc; [[P2Pool]] does this with the share chain hash txout in the coinbase of blocks it creates.

=== Anyone-Can-Spend Outputs ===

Conversely a transaction can be made spendable by anyone at all:

scriptPubKey: (empty)
scriptSig: OP_TRUE

With some software changes such transactions can be used as a way to donate funds to miners in addition to transaction fees: any miner who mines such a transaction can also include an additional one after it sending the funds to an address they control. This mechanism may be used in the future for [[fidelity bonds]] to sacrifice funds in a provable way.

Anyone-Can-Spend outputs are currently considered non-standard, and are not relayed on the P2P network.

=== Freezing funds until a time in the future ===

Using OP_CHECKLOCKTIMEVERIFY it is possible to make funds provably unspendable until a certain point in the future.

scriptPubKey: <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey> <expiry time>
| OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <expiry time>
| OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is checked against the current time or block height.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is removed.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Transaction puzzle ===

Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.

scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL
scriptSig: <data>

To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.

{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
|<data> OP_HASH256 <given_hash> OP_EQUAL
|
|-
|<data>
|OP_HASH256 <given_hash> OP_EQUAL
|scriptSig added to the stack.
|-
|<data_hash>
|<given_hash> OP_EQUAL
|The data is hashed.
|-
|<data_hash> <given_hash>
|OP_EQUAL
|The given hash is pushed to the stack.
|-
|true
|Empty.
|The hashes are compared, leaving true on the stack.
|}

This transaction was successfully spent by 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. The required data happened to be the [[Genesis block]], and the given hash was the genesis block hash. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.

==See Also==

* [[Transactions]]
* [[Contracts]]

== External Links ==
*[https://github.com/siminchen/bitcoinIDE Bitcoin IDE]: Bitcoin Script for dummies
*[https://webbtc.com/script Bitcoin Debug Script Execution]
*[http://www.crmarsh.com/script-playground/ Script Playground] — convert Script to JavaScript
(cf. "[http://bitcoin.stackexchange.com/q/42576/4334 Online Bitcoin Script simulator or debugger?]")

[[Category:Technical]]
[[Category:Vocabulary]]

{{Bitcoin Core documentation}}

Pay to script hash

2015-05-27T06:35:17Z

Rusty: Save others from trying to understand that non-BIP16 spending script!

'''Pay to script hash''' (P2SH) transactions were standardised in [[BIP 0016|BIP 16]]. They allow transactions to be sent to a script hash (addresses starting with 3) instead of a public key hash (addresses starting with 1). To spend bitcoins sent via P2SH, the recipient must provide a [[script]] matching the script hash and data which makes the script evaluate to true.

Using P2SH, you can send bitcoins to an address that is secured in various unusual ways without knowing anything about the details of how the security is set up. You just send bitcoins to the ~34-character P2SH address. The recipient might need the signatures of several people to spend these bitcoins, or a password might be required, or the requirements could be completely unique.

== Addresses ==

[[BIP 0013|BIP 13]] specifies the address format. Bitcoin P2SH addresses always start with 3.

== Example ==

Transaction 40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8 paid to P2SH address 3P14159f73E4gFr7JterCCQh9QjiTjiZrG. You can see the redeem script in transaction 7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45 which spends that output, using <code>OP_FALSE <sig> { OP_1 <pubkey> OP_1 OP_CHECKMULTISIG }</code>.

== History ==

342ftSRCvFHfCeFFBuz4xwbeqnDw6BGUey is a Bitcoin [[address]] notable for being the first [[P2SH]]-compatible address receiving bitcoins on the production network.
Its payment was mined in [[block]] 160720; note that it was spent prior to the enforcement of [[BIP 0016|BIP 16]], so it's not a good example to understand P2SH.