diff --git a/_autocrossref.yaml b/_autocrossref.yaml index 15a56cf8..08887159 100644 --- a/_autocrossref.yaml +++ b/_autocrossref.yaml @@ -144,8 +144,12 @@ proof of work: proof-of-work: proof of work protocol buffer: protobuf protocol buffers: protobuf +pubkey: public key pubkey hash: pubkey hashes: pubkey hash +pubkey script: +pubkey scripts: pubkey script +pubkeys: public key public key: public keys: public key public key infrastructure: pki @@ -154,7 +158,7 @@ raw format: rawtransaction format: raw format receipt: recurrent rebilling: -redeemScript: +redeem script: refund: refunds: refund regression test mode: @@ -165,12 +169,8 @@ RPCs: rpc RPC: satoshi: satoshis: satoshi -scriptPubKey: '`script`': pp script script hash: -scriptPubKeys: scriptPubKey -scriptSig: -scriptSigs: scriptSig secp256k1: sequence number: sequence numbers: sequence number @@ -183,6 +183,8 @@ SIGHASH: signature hash '`SIGHASH_SINGLE|SIGHASH_ANYONECANPAY`': shs_shacp signature: signature hash: +signature script: +signature scripts: signature script signatures: signature SPV: stack: diff --git a/_includes/example_payment_processing.md b/_includes/example_payment_processing.md index e19df3e5..72c75f1b 100644 --- a/_includes/example_payment_processing.md +++ b/_includes/example_payment_processing.md @@ -250,13 +250,13 @@ amount = 10000000 ## In satoshis ## P2PKH pubkey hash pubkey_hash = "2b14950b8d31620c6cc923c5408a701b1ec0a020" -## P2PKH output script entered as hex and converted to binary +## P2PKH pubkey script entered as hex and converted to binary # OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG # 76 a9 14 88 ac hex_script = "76" + "a9" + "14" + pubkey_hash + "88" + "ac" serialized_script = hex_script.decode("hex") -## Load amount and script into PaymentDetails +## Load amount and pubkey script into PaymentDetails details.outputs.add(amount = amount, script = serialized_script) ## Memo to display to the spender @@ -286,24 +286,24 @@ hex_script = "76" + "a9" + "14" + pubkey_hash + "88" + "ac" serialized_script = hex_script.decode("hex") {% endhighlight %} -`script`: (required) You must specify the output script you want the spender to -pay---any valid script is acceptable. In this example, we'll request -payment to a P2PKH output script. +`script`: (required) You must specify the pubkey script you want the spender to +pay---any valid pubkey script is acceptable. In this example, we'll request +payment to a P2PKH pubkey script. First we get a pubkey hash. The hash above is the hash form of the address used in the URI examples throughout this section, mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN. -Next, we plug that hash into the standard P2PKH output script using hex, +Next, we plug that hash into the standard P2PKH pubkey script using hex, as illustrated by the code comments. -Finally, we convert the output script from hex into its serialized form. +Finally, we convert the pubkey script from hex into its serialized form. {% highlight python %} details.outputs.add(amount = amount, script = serialized_script) {% endhighlight %} -`outputs`: (required) add the output script and (optional) amount to the +`outputs`: (required) add the pubkey script and (optional) amount to the PaymentDetails outputs array. It's possible to specify multiple [`scripts`][pp diff --git a/_includes/example_transactions.md b/_includes/example_transactions.md index 67d4086b..f0bd96ff 100644 --- a/_includes/example_transactions.md +++ b/_includes/example_transactions.md @@ -703,7 +703,7 @@ variable. Decode the signed raw transaction so we can get its txid. Also, choose a specific one of its UTXOs to spend and save that UTXO's output index number -(vout) and hex output script (scriptPubKey) into shell variables. +(vout) and hex pubkey script (scriptPubKey) into shell variables. {% highlight bash %} > bitcoin-cli -regtest getnewaddress @@ -763,16 +763,16 @@ transaction hex unchanged. As illustrated above, the data that gets signed includes the txid and vout from the previous transaction. That information is included in the `createrawtransaction` raw transaction. But the data that gets signed -also includes the output script from the previous transaction, even +also includes the pubkey script from the previous transaction, even though it doesn't appear in either the unsigned or signed transaction. In the other raw transaction subsections above, the previous output was part of the UTXO set known to the wallet, so the wallet was able to use -the txid and output index number to find the previous output script and +the txid and output index number to find the previous pubkey script and insert it automatically. In this case, you're spending an output which is unknown to the wallet, -so it can't automatically insert the previous output script. +so it can't automatically insert the previous pubkey script.
{% highlight bash %} @@ -804,12 +804,12 @@ so it can't automatically insert the previous output script. {% endhighlight %}
-Successfully sign the transaction by providing the previous output +Successfully sign the transaction by providing the previous pubkey script and other required input data. This specific operation is typically what offline signing wallets do. The online wallet creates the raw transaction and gets the previous -output scripts for all the inputs. The user brings this information to +pubkey scripts for all the inputs. The user brings this information to the offline wallet. After displaying the transaction details to the user, the offline wallet signs the transaction as we did above. The user takes the signed transaction back to the online wallet, which @@ -895,9 +895,9 @@ called m-of-n, and in this case we'll be using 2-of-3. {% endhighlight %} Generate three new P2PKH addresses. P2PKH addresses cannot be used with -the multisig redeemScript created below. (Hashing each public key is +the multisig redeem script created below. (Hashing each public key is unnecessary anyway---all the public keys are protected by a hash when -the redeemScript is hashed.) However, Bitcoin Core uses addresses as a +the redeem script is hashed.) However, Bitcoin Core uses addresses as a way to reference the underlying full (unhashed) public keys it knows about, so we get the three new addresses above in order to use their public keys. @@ -905,7 +905,7 @@ public keys. [Recall from the Guide][address] that the hashed public keys used in addresses obfuscate the full public key, so you cannot give an address to another person or device as part of creating a typical multisig output or P2SH multisig -redeemScript. You must give them a full public key. +redeem script. You must give them a full public key.
{% highlight bash %} @@ -931,9 +931,9 @@ redeemScript. You must give them a full public key. Use the `validateaddress` RPC to display the full (unhashed) public key for one of the addresses. This is the information which will -actually be included in the multisig redeemScript. This is also the +actually be included in the multisig redeem script. This is also the information you would give another person or device as part of creating -a multisig output or P2SH multisig redeemScript. +a multisig output or P2SH multisig redeem script. We save the address returned to a shell variable. @@ -964,26 +964,26 @@ We save the address returned to a shell variable. Use the `createmultisig` RPC with two arguments, the number (*n*) of signatures required and a list of addresses or public keys. Because -P2PKH addresses can't be used in the multisig redeemScript created by this +P2PKH addresses can't be used in the multisig redeem script created by this RPC, the only addresses which can be provided are those belonging to a public key in the wallet. In this case, we provide two addresses and one public key---all of which will be converted to public keys in the -redeemScript. +redeem script. -The P2SH address is returned along with the redeemScript which must be +The P2SH address is returned along with the redeem script which must be provided when we spend satoshis sent to the P2SH address. ![Warning icon](/img/icon_warning.svg) - **Warning:** You must not lose the redeemScript, especially if you + **Warning:** You must not lose the redeem script, especially if you don't have a record of which public keys you used to create the P2SH -multisig address. You need the redeemScript to spend any bitcoins sent -to the P2SH address. If you lose the redeemScript, you can recreate it +multisig address. You need the redeem script to spend any bitcoins sent +to the P2SH address. If you lose the redeem script, you can recreate it by running the same command above, with the public keys listed in the -same order. However, if you lose both the redeemScript and even one of +same order. However, if you lose both the redeem script and even one of the public keys, you will never be able to spend satoshis sent to that P2SH address. -Neither the address nor the redeemScript are stored in the wallet when +Neither the address nor the redeem script are stored in the wallet when you use `createmultisig`. To store them in the wallet, use the `addmultisigaddress` RPC instead. If you add an address to the wallet, you should also make a new backup. @@ -1073,7 +1073,7 @@ We save that txid to a shell variable as the txid of the UTXO we plan to spend n We use the `getrawtransaction` RPC with the optional second argument (*true*) to get the decoded transaction we just created with `spendtoaddress`. We choose one of the outputs to be our UTXO and get -its output index number (vout) and output script (scriptPubKey). +its output index number (vout) and pubkey script (scriptPubKey). {% highlight bash %} > bitcoin-cli -regtest getnewaddress @@ -1121,7 +1121,7 @@ cNmbnwwGzEghMMe1vBwH34DFHShEj5bcXD1QpFRPHgG9Mj1xc5hq We get the private keys for two of the public keys we used to create the transaction, the same way we got private keys in the Complex Raw -Transaction subsection. Recall that we created a 2-of-3 multisig script, +Transaction subsection. Recall that we created a 2-of-3 multisig pubkey script, so signatures from two private keys are needed. ![Warning icon](/img/icon_warning.svg) @@ -1168,8 +1168,8 @@ complex raw transaction].
We make the first signature. The input argument (JSON object) takes the -additional redeemScript parameter so that it can append the redeemScript -to the scriptSig after the two signatures. +additional redeem script parameter so that it can append the redeem script +to the signature script after the two signatures.
{% highlight bash %} diff --git a/_includes/guide_contracts.md b/_includes/guide_contracts.md index 75d0da06..19424fe0 100644 --- a/_includes/guide_contracts.md +++ b/_includes/guide_contracts.md @@ -42,7 +42,7 @@ who should get the satoshis if there's a dispute. To create a multiple-signature ([multisig][]{:#term-multisig}{:.term}) output, they each give the others a public key. Then Bob creates the -following [P2SH multisig][]{:#term-p2sh-multisig}{:.term} redeemScript: +following [P2SH multisig][]{:#term-p2sh-multisig}{:.term} redeem script: {% endautocrossref %} @@ -58,19 +58,19 @@ OP_2 [A's pubkey] [B's pubkey] [C's pubkey] OP_3 OP_CHECKMULTISIG stack. `OP_2` specifies that 2 signatures are required to sign; `OP_3` specifies that 3 public keys (unhashed) are being provided. This is a 2-of-3 multisig -scriptPubKey, more generically called a m-of-n scriptPubKey (where *m* is the +pubkey script, more generically called a m-of-n pubkey script (where *m* is the *minimum* matching signatures required and *n* in the *number* of public keys provided). -Bob gives the redeemScript to Charlie, who checks to make sure his +Bob gives the redeem script to Charlie, who checks to make sure his public key and Alice's public key are included. Then he hashes the -redeemScript to create a P2SH scriptPubKey and pays the satoshis to it. Bob +redeem script to create a P2SH redeem script and pays the satoshis to it. Bob sees the payment get added to the block chain and ships the merchandise. Unfortunately, the merchandise gets slightly damaged in transit. Charlie wants a full refund, but Bob thinks a 10% refund is sufficient. They turn to Alice to resolve the issue. Alice asks for photo evidence from -Charlie along with a copy of the redeemScript Bob created and +Charlie along with a copy of the redeem script Bob created and Charlie checked. After looking at the evidence, Alice thinks a 40% refund is sufficient, @@ -78,36 +78,36 @@ so she creates and signs a transaction with two outputs, one that spends 60% of the satoshis to Bob's public key and one that spends the remaining 40% to Charlie's public key. -In the scriptSig Alice puts her signature -and a copy of the unhashed serialized redeemScript +In the signature script Alice puts her signature +and a copy of the unhashed serialized redeem script that Bob created. She gives a copy of the incomplete transaction to both Bob and Charlie. Either one of them can complete it by adding -his signature to create the following scriptSig: +his signature to create the following signature script: {% endautocrossref %} ~~~ -OP_0 [A's signature] [B's or C's signature] [serialized redeemScript] +OP_0 [A's signature] [B's or C's signature] [serialized redeem script] ~~~ {% autocrossref %} -(Op codes to push the signatures and redeemScript onto the stack are +(Op codes to push the signatures and redeem script onto the stack are not shown. `OP_0` is a workaround for an off-by-one error in the original implementation which must be preserved for compatibility.) When the transaction is broadcast to the network, each peer checks the -scriptSig against the P2SH output Charlie previously paid, -ensuring that the redeemScript matches the redeemScript hash previously -provided. Then the redeemScript is evaluated, with the two signatures -being used as input data. Assuming the redeemScript +signature script against the P2SH output Charlie previously paid, +ensuring that the redeem script matches the redeem script hash previously +provided. Then the redeem script is evaluated, with the two signatures +being used as input data. Assuming the redeem script validates, the two transaction outputs show up in Bob's and Charlie's wallets as spendable balances. However, if Alice created and signed a transaction neither of them would agree to, such as spending all the satoshis to herself, Bob and Charlie can find a new arbitrator and sign a transaction spending the satoshis -to another 2-of-3 multisig redeemScript hash, this one including a public +to another 2-of-3 multisig redeem script hash, this one including a public key from that second arbitrator. This means that Bob and Charlie never need to worry about their arbitrator stealing their money. @@ -133,7 +133,7 @@ him thousands of satoshis in transaction fees, so Alice suggests they use a Bob asks Alice for her public key and then creates two transactions. The first transaction pays 100 millibits to a P2SH output whose -2-of-2 multisig redeemScript requires signatures from both Alice and Bob. +2-of-2 multisig redeem script requires signatures from both Alice and Bob. This is the bond transaction. Broadcasting this transaction would let Alice hold the millibits hostage, so Bob keeps this transaction private for now and creates a diff --git a/_includes/guide_operating_modes.md b/_includes/guide_operating_modes.md index 63099951..d205b8fa 100644 --- a/_includes/guide_operating_modes.md +++ b/_includes/guide_operating_modes.md @@ -68,7 +68,8 @@ Removal of elements can only be done by scrapping the bloom filter and re-creati Rather than viewing the false positive rates as a liability, it is used to create a tunable parameter that represents the desired privacy level and bandwidth trade-off. A SPV client creates their Bloom filter and sends it to a full node using the message `filterload`, which sets the filter for which transactions are desired. The command `filteradd` allows addition of desired data to the filter without needing to send a totally new Bloom filter, and `filterclear` allows the connection to revert to standard block discovery mechanisms. If the filter has been loaded, then full nodes will send a modified form of blocks, called a merkleblock. The merkleblock is simply the block header with the merkle branch associated with the set Bloom filter. -An SPV client can not only add transactions as elements to the filter, but also public keys, data from scriptSig and scriptPubKeys, and more. This enables P2SH transaction finding. +An SPV client can not only add transactions as elements to the filter, but also public keys, data from signature +scripts and pubkey scripts, and more. This enables P2SH transaction finding. If a user is more privacy-conscious, he can set the Bloom filter to include more false positives, at the expense of extra bandwidth used for transaction discovery. If a user is on a tight bandwidth budget, he can set the false-positive rate to low, knowing that this will allow full nodes a clear view of what transactions are associated with his client. diff --git a/_includes/guide_payment_processing.md b/_includes/guide_payment_processing.md index a4c82b97..9ebce56b 100644 --- a/_includes/guide_payment_processing.md +++ b/_includes/guide_payment_processing.md @@ -307,9 +307,9 @@ invoice database: * An expiration time when that total will no longer be acceptable. -* An output script to which Charlie should send payment. Typically this - will be a P2PKH or P2SH output script containing a unique (never - before used) public key. +* A pubkey script to which Charlie should send payment. Typically this + will be a P2PKH or P2SH pubkey script containing a unique (never + before used) secp256k1 public key. After adding all that information to the database, Bob's server displays a `bitcoin:` URI for Charlie to click to pay. @@ -334,7 +334,7 @@ unique identifier from the URL and looks up the corresponding details in the database. It then creates a PaymentDetails message with the following information: -* The amount of the order in satoshis and the output script to be paid. +* The amount of the order in satoshis and the pubkey script to be paid. * A memo containing the list of items ordered, so Charlie knows what he's paying for. It may also include Charlie's mailing address so he can @@ -355,7 +355,7 @@ payment request to Charlie's wallet in the reply to the HTTP GET. Charlie's wallet receives the PaymentRequest message, checks its signature, and then displays the details from the PaymentDetails message to Charlie. Charlie -agrees to pay, so the wallet constructs a payment to the output script +agrees to pay, so the wallet constructs a payment to the pubkey script Bob's server provided. Unlike a traditional Bitcoin payment, Charlie's wallet doesn't necessarily automatically broadcast this payment to the network. Instead, the wallet constructs a Payment message and sends it to @@ -367,7 +367,7 @@ other things, the Payment message contains: * An optional memo Charlie can send to Bob. (There's no guarantee that Bob will read it.) -* A refund address (output script) which Bob can pay if he needs to +* A refund address (pubkey script) which Bob can pay if he needs to return some or all of Charlie's satoshis. Bob's server receives the Payment message, verifies the transaction pays @@ -390,14 +390,14 @@ In the case of a dispute, Charlie can generate a cryptographically-proven otherwise-proven information. * The PaymentDetails message signed by Bob's webserver proves Charlie - received an invoice to pay a specified output script for a specified + received an invoice to pay a specified pubkey script for a specified number of satoshis for goods specified in the memo field. -* The Bitcoin block chain can prove that the output script specified by +* The Bitcoin block chain can prove that the pubkey script specified by Bob was paid the specified number of satoshis. If a refund needs to be issued, Bob's server can safely pay the -refund-to output script provided by Charlie. (Note: a proposal has been +refund-to pubkey script provided by Charlie. (Note: a proposal has been discussed to give refund-to addresses an implicit expiration date so users and software don't need to worry about payments being sent to addresses which are no longer monitored.) See the Refunds section below @@ -504,7 +504,7 @@ basis. Occasionally receivers using your applications will need to issue refunds. The obvious way to do that, which is very unsafe, is simply -to return the satoshis to the output script from which they came. +to return the satoshis to the pubkey script from which they came. For example: * Alice wants to buy a widget from Bob, so Bob gives Alice a price and diff --git a/_includes/guide_transactions.md b/_includes/guide_transactions.md index 0c1c24c3..62e4e778 100644 --- a/_includes/guide_transactions.md +++ b/_includes/guide_transactions.md @@ -23,7 +23,7 @@ and they're an exception to many of the rules listed below. Instead of pointing out the coinbase exception to each rule, we invite you to read about coinbase transactions in the block chain section of this guide. -![The Parts Of A Transaction](/img/dev/en-tx-overview.svg) + The figure above shows the core parts of a Bitcoin transaction. Each transaction has at least one input and one output. Each [input][]{:#term-input}{:.term} spends the @@ -48,13 +48,14 @@ cryptographic key pair. ![Creating A P2PKH Public Key Hash To Receive Payment](/img/dev/en-creating-p2pkh-output.svg) Bob must first generate a private/public [key pair][]{:#term-key-pair}{:.term} before Alice can create the -first transaction. Standard Bitcoin [private keys][private +first transaction. Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA) with +the secp256k1 curve; secp256k1 [private keys][private key]{:#term-private-key}{:.term} are 256 bits of random -data. A copy of that data is deterministically transformed into a [public +data. A copy of that data is deterministically transformed into an secp256k1 [public key][]{:#term-public-key}{:.term}. Because the transformation can be reliably repeated later, the public key does not need to be stored. -The public key is then cryptographically hashed. This pubkey hash can +The public key (pubkey) is then cryptographically hashed. This pubkey hash can also be reliably repeated later, so it also does not need to be stored. The hash shortens and obfuscates the public key, making manual transcription easier and providing security against @@ -79,7 +80,8 @@ Once Alice has the address and decodes it back into a standard hash, she can create the first transaction. She creates a standard P2PKH transaction output containing instructions which allow anyone to spend that output if they can prove they control the private key corresponding to -Bob's hashed public key. These instructions are called the [scriptPubKey][]{:#term-scriptpubkey}{:.term}. +Bob's hashed public key. These instructions are called the [pubkey script][]{:#term-pubkey-script}{:.term} +or scriptPubKey. Alice broadcasts the transaction and it is added to the block chain. The network categorizes it as an Unspent Transaction Output (UTXO), and Bob's @@ -88,40 +90,44 @@ wallet software displays it as a spendable balance. When, some time later, Bob decides to spend the UTXO, he must create an input which references the transaction Alice created by its hash, called a Transaction Identifier (txid), and the specific output she used by its -index number ([output index][]{:#term-output-index}{:.term}). He must then create a [scriptSig][]{:#term-scriptsig}{:.term}---a +index number ([output index][]{:#term-output-index}{:.term}). He must then create a [signature +script][]{:#term-signature-script}{:.term}---a collection of data parameters which satisfy the conditions Alice placed -in the previous output's scriptPubKey. +in the previous output's pubkey script. Signature scripts are also +called scriptSigs. + +Pubkey scripts and signature scripts combine secp256k1 pubkeys +and signatures with conditional logic, creating a programable +authorization mechanism. ![Unlocking A P2PKH Output For Spending](/img/dev/en-unlocking-p2pkh-output.svg) -Bob does not need to communicate with Alice to do this; he must simply -prove to the Bitcoin peer-to-peer network that he can satisfy the -scriptPubKey's conditions. For a P2PKH-style output, Bob's scriptSig will -contain the following two pieces of data: +For a P2PKH-style output, Bob's signature script will contain the following two +pieces of data: -1. His full (unhashed) public key, so the scriptPubKey can check that it +1. His full (unhashed) public key, so the pubkey script can check that it hashes to the same value as the pubkey hash provided by Alice. -2. A [signature][]{:#term-signature}{:.term} made by using the ECDSA cryptographic formula to combine +2. An secp256k1 [signature][]{:#term-signature}{:.term} made by using the ECDSA cryptographic formula to combine certain transaction data (described below) with Bob's private key. - This lets the scriptPubKey verify that Bob owns the private key which + This lets the pubkey script verify that Bob owns the private key which created the public key. -Bob's signature doesn't just prove Bob controls his private key; it also -makes the rest of his transaction tamper-proof so Bob can safely -broadcast it over the peer-to-peer network. +Bob's secp256k1 signature doesn't just prove Bob controls his private key; it also +makes the non-signature-script parts of his transaction tamper-proof so Bob can safely +broadcast them over the peer-to-peer network. ![Some Things Signed When Spending An Output](/img/dev/en-signing-output-to-spend.svg) As illustrated in the figure above, the data Bob signs includes the txid and output index of the previous transaction, the previous -output's scriptPubKey, the scriptPubKey Bob creates which will let the next +output's pubkey script, the pubkey script Bob creates which will let the next recipient spend this transaction's output, and the amount of satoshis to spend to the next recipient. In essence, the entire transaction is -signed except for any scriptSigs, which hold the full public keys and -signatures. +signed except for any signature scripts, which hold the full public keys and +secp256k1 signatures. -After putting his signature and public key in the scriptSig, Bob +After putting his signature and public key in the signature script, Bob broadcasts the transaction to Bitcoin miners through the peer-to-peer network. Each peer and miner independently validates the transaction before broadcasting it further or attempting to include it in a new block of @@ -133,8 +139,8 @@ transactions. {% autocrossref %} -The validation procedure requires evaluation of the scriptSig and scriptPubKey. -In a P2PKH output, the scriptPubKey is: +The validation procedure requires evaluation of the signature script and pubkey script. +In a P2PKH output, the pubkey script is: {% endautocrossref %} @@ -144,8 +150,8 @@ OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG {% autocrossref %} -The spender's scriptSig is evaluated and prefixed to the beginning of the -script. In a P2PKH transaction, the scriptSig contains a signature (sig) +The spender's signature script is evaluated and prefixed to the beginning of the +script. In a P2PKH transaction, the signature script contains an secp256k1 signature (sig) and full public key (pubkey), creating the following concatenation: {% endautocrossref %} @@ -170,19 +176,19 @@ sections about stacks. These are programming terms. Also "above", "below", "top", and "bottom" are commonly used relative directions or locations in stack descriptions. -harding --> -To test whether the transaction is valid, scriptSig and scriptPubKey arguments -are pushed to the stack one item at a time, starting with Bob's scriptSig -and continuing to the end of Alice's scriptPubKey. The figure below shows the -evaluation of a standard P2PKH scriptPubKey; below the figure is a description +To test whether the transaction is valid, signature script and pubkey script arguments +are pushed to the stack one item at a time, starting with Bob's signature script +and continuing to the end of Alice's pubkey script. The figure below shows the +evaluation of a standard P2PKH pubkey script; below the figure is a description of the process. ![P2PKH Stack Evaluation](/img/dev/en-p2pkh-stack.svg) -* The signature (from Bob's scriptSig) is added (pushed) to an empty stack. +* The signature (from Bob's signature script) is added (pushed) to an empty stack. Because it's just data, nothing is done except adding it to the stack. - The public key (also from the scriptSig) is pushed on top of the signature. + The public key (also from the signature script) is pushed on top of the signature. -* From Alice's scriptPubKey, the `OP_DUP` operation is pushed. `OP_DUP` replaces +* From Alice's pubkey script, the `OP_DUP` operation is pushed. `OP_DUP` replaces itself with a copy of the data from one level below it---in this case creating a copy of the public key Bob provided. @@ -190,11 +196,11 @@ of the process. of the data from one level below it---in this case, Bob's public key. This creates a hash of Bob's public key. -* Alice's scriptPubKey then pushes the pubkey hash that Bob gave her for the +* Alice's pubkey script then pushes the pubkey hash that Bob gave her for the first transaction. At this point, there should be two copies of Bob's pubkey hash at the top of the stack. -* Now it gets interesting: Alice's scriptPubKey adds `OP_EQUALVERIFY` to the +* Now it gets interesting: Alice's pubkey script adds `OP_EQUALVERIFY` to the stack. `OP_EQUALVERIFY` expands to `OP_EQUAL` and `OP_VERIFY` (not shown). `OP_EQUAL` (not shown) checks the two values below it; in this @@ -209,13 +215,13 @@ of the process. the transaction validation fails. Otherwise it pops both itself and the *true* value off the stack. -* Finally, Alice's scriptPubKey pushes `OP_CHECKSIG`, which checks the +* Finally, Alice's pubkey script pushes `OP_CHECKSIG`, which checks the signature Bob provided against the now-authenticated public key he also provided. If the signature matches the public key and was generated using all of the data required to be signed, `OP_CHECKSIG` replaces itself with *true.* -If *false* is not at the top of the stack after the scriptPubKey has been +If *false* is not at the top of the stack after the pubkey script has been evaluated, the transaction is valid (provided there are no other problems with it). @@ -225,43 +231,43 @@ problems with it). {% autocrossref %} -Transaction scriptPubKeys are created by spenders who have little interest in the +Pubkey scripts are created by spenders who have little interest in the long-term security or usefulness of the particular satoshis they're currently spending. Receivers do care about the conditions imposed on -the satoshis by the scriptPubKey and, if they want, they can ask -spenders to use a particular scriptPubKey. Unfortunately, custom scriptPubKeys are -less convenient than short Bitcoin addresses and more difficult to -secure than P2PKH pubkey hashes. +the satoshis by the pubkey script and, if they want, they can ask +spenders to use a particular pubkey script. Unfortunately, custom +pubkey scripts are less convenient than short Bitcoin addresses and more +difficult to secure than P2PKH pubkey hashes. To solve these problems, pay-to-script-hash ([P2SH][]{:#term-p2sh}{:.term}) transactions were created in 2012 to let -a spender create a scriptPubKey containing a [hash of a second +a spender create a pubkey script containing a [hash of a second script][script hash]{:#term-script-hash}{:.term}, the -[redeemScript][]{:#term-redeemscript}{:.term}. +[redeem script][]{:#term-redeem-script}{:.term}. The basic P2SH workflow, illustrated below, looks almost identical to -the P2PKH workflow. Bob creates a redeemScript with whatever script he -wants, hashes the redeemScript, and provides the redeemScript +the P2PKH workflow. Bob creates a redeem script with whatever script he +wants, hashes the redeem script, and provides the redeem script hash to Alice. Alice creates a P2SH-style output containing -Bob's redeemScript hash. +Bob's redeem script hash. -![Creating A P2SH RedeemScript And Hash](/img/dev/en-creating-p2sh-output.svg) +![Creating A P2SH Redeem Script And Hash](/img/dev/en-creating-p2sh-output.svg) When Bob wants to spend the output, he provides his signature along with -the full (serialized) redeemScript in the input scriptSig. The -peer-to-peer network ensures the full redeemScript hashes to the same +the full (serialized) redeem script in the signature script. The +peer-to-peer network ensures the full redeem script hashes to the same value as the script hash Alice put in her output; it then processes the -redeemScript exactly as it would if it were the primary scriptPubKey, letting -Bob spend the output if the redeemScript returns true. +redeem script exactly as it would if it were the primary pubkey script, letting +Bob spend the output if the redeem script does not return false. ![Unlocking A P2SH Output For Spending](/img/dev/en-unlocking-p2sh-output.svg) -The hash of the redeemScript has the same properties as a pubkey +The hash of the redeem script has the same properties as a pubkey hash---so it can be transformed into the standard Bitcoin address format with only one small change to differentiate it from a standard address. This makes collecting a P2SH-style address as simple as collecting a P2PKH-style address. The hash also obfuscates any public keys in the -redeemScript, so P2SH scripts are as secure as P2PKH pubkey hashes. +redeem script, so P2SH scripts are as secure as P2PKH pubkey hashes. {% endautocrossref %} @@ -271,7 +277,7 @@ redeemScript, so P2SH scripts are as secure as P2PKH pubkey hashes. After the discovery of several dangerous bugs in early versions of Bitcoin, a test was added which only accepted transactions from the -network if their scriptPubKeys and scriptSigs matched a small set of +network if their pubkey scripts and signature scripts matched a small set of believed-to-be-safe templates, and if the rest of the transaction didn't violate another small set of rules enforcing good network behavior. This is the `IsStandard()` test, and transactions which pass it are called @@ -292,18 +298,18 @@ number, it would become useless as a tool for introducing backwards-incompatible features. -As of Bitcoin Core 0.9, the standard scriptPubKey types are: +As of Bitcoin Core 0.9, the standard pubkey script types are: -**Pubkey Hash (P2PKH)** +**Pay To Public Key Hash (P2PKH)** -P2PKH is the most common form of scriptPubKey used to send a transaction to one +P2PKH is the most common form of pubkey script used to send a transaction to one or multiple Bitcoin addresses. {% endautocrossref %} ~~~ -scriptPubKey: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG -scriptSig: +Pubkey script: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG +Signature script: ~~~ {% autocrossref %} @@ -311,14 +317,14 @@ scriptSig: **Pay To Script Hash (P2SH)** P2SH is used to send a transaction to a script hash. Each of the standard -scriptPubKeys can be used as a P2SH redeemScript, but in practice only the -multisig scriptPubKey makes sense until more transaction types are made standard. +pubkey scripts can be used as a P2SH redeem script, but in practice only the +multisig pubkey script makes sense until more transaction types are made standard. {% endautocrossref %} ~~~ -scriptPubKey: OP_HASH160 OP_EQUAL -scriptSig: [sig] [sig...] +Pubkey script: OP_HASH160 OP_EQUAL +Signature script: [sig] [sig...] ~~~ {% autocrossref %} @@ -328,7 +334,7 @@ scriptSig: [sig] [sig...] Although P2SH multisig is now generally used for multisig transactions, this base script can be used to require multiple signatures before a UTXO can be spent. -In multisig scriptPubKeys, called m-of-n, *m* is the *minimum* number of signatures +In multisig pubkey scripts, called m-of-n, *m* is the *minimum* number of signatures which must match a public key; *n* is the *number* of public keys being provided. Both *m* and *n* should be op codes `OP_1` through `OP_16`, corresponding to the number desired. @@ -336,14 +342,14 @@ corresponding to the number desired. Because of an off-by-one error in the original Bitcoin implementation which must be preserved for compatibility, `OP_CHECKMULTISIG` consumes one more value from the stack than indicated by *m*, so the -list of signatures in the scriptSig must be prefaced with an extra value +list of secp256k1 signatures in the signature script must be prefaced with an extra value (`OP_0`) which will be consumed but not used. {% endautocrossref %} ~~~ -scriptPubKey: [pubkey] [pubkey...] OP_CHECKMULTISIG -scriptSig: OP_0 [sig] [sig...] +Pubkey script: [pubkey] [pubkey...] OP_CHECKMULTISIG +Signature script: OP_0 [sig] [sig...] ~~~ {% autocrossref %} @@ -353,16 +359,16 @@ Although it’s not a separate transaction type, this is a P2SH multisig with 2- {% endautocrossref %} ~~~ -scriptPubKey: OP_HASH160 OP_EQUAL -redeemScript: OP_CHECKMULTISIG -scriptSig: OP_0 +Pubkey script: OP_HASH160 OP_EQUAL +Redeem script: OP_CHECKMULTISIG +Signature script: OP_0 ~~~ {% autocrossref %} **Pubkey** -[Pubkey][]{:#term-pubkey}{:.term} scripts are a simplified form of the P2PKH scriptPubKey, +[Pubkey][]{:#term-pubkey}{:.term} scripts are a simplified form of the P2PKH pubkey script, but they aren’t as secure as P2PKH, so they generally aren’t used in new transactions anymore. @@ -370,44 +376,44 @@ aren’t used in new transactions anymore. {% endautocrossref %} ~~~ -scriptPubKey: OP_CHECKSIG -scriptSig: +Pubkey script: OP_CHECKSIG +Signature script: ~~~ {% autocrossref %} **Null Data** -[Null data][]{:#term-null-data}{:.term} scriptPubKeys let you add a small amount of arbitrary data to the block +[Null data][]{:#term-null-data}{:.term} pubkey scripts let you add a small amount of arbitrary data to the block chain in exchange for paying a transaction fee, but doing so is discouraged. -(Null data is a standard scriptPubKey type only because some people were adding data +(Null data is a standard pubkey script type only because some people were adding data to the block chain in more harmful ways.) {% endautocrossref %} ~~~ -scriptScriptPubKey: OP_RETURN <0 to 40 bytes of data> -(Null data scripts cannot be spent, so there's no scriptSig) +Pubkey Script: OP_RETURN <0 to 40 bytes of data> +(Null data scripts cannot be spent, so there's no signature script.) ~~~ #### Non-Standard Transactions {% autocrossref %} -If you use anything besides a standard scriptPubKey in an output, peers +If you use anything besides a standard pubkey script in an output, peers and miners using the default Bitcoin Core settings will neither accept, broadcast, nor mine your transaction. When you try to broadcast your transaction to a peer running the default settings, you will receive an error. -If you create a redeemScript, hash it, and use the hash +If you create a redeem script, hash it, and use the hash in a P2SH output, the network sees only the hash, so it will accept the -output as valid no matter what the redeemScript says. +output as valid no matter what the redeem script says. This allows -payment to non-standard scriptPubKeys almost as easily as payment to -standard scriptPubKeys. However, when you go to +payment to non-standard pubkey script almost as easily as payment to +standard pubkey scripts. However, when you go to spend that output, peers and miners using the default settings will -check the redeemScript to see whether or not it's a standard scriptPubKey. +check the redeem script to see whether or not it's a standard pubkey script. If it isn't, they won't process it further---so it will be impossible to spend that output until you find a miner who disables the default settings. @@ -432,7 +438,7 @@ conditions: Multisig transactions which require more than 3 public keys are currently non-standard. -* The transaction's scriptSig must only push data to the script +* The transaction's signature script must only push data to the script evaluation stack. It cannot push new OP codes, with the exception of OP codes which solely push data to the stack. @@ -456,7 +462,7 @@ called [signature hash][]{:#term-signature-hash}{:.term} types. There are three currently available: * [`SIGHASH_ALL`][sighash_all]{:#term-sighash-all}{:.term}, the default, signs all the inputs and outputs, - protecting everything except the scriptSigs against modification. + protecting everything except the signature scripts against modification. * [`SIGHASH_NONE`][sighash_none]{:#term-sighash-none}{:.term} signs all of the inputs but none of the outputs, allowing anyone to change where the satoshis are going unless other @@ -657,13 +663,13 @@ fixed URI to which payments should be sent, please see the {% autocrossref %} -None of Bitcoin's signature hash types protect the scriptSig, leaving +None of Bitcoin's signature hash types protect the signature script, leaving the door open for a limited denial of service attack called [transaction -malleability][]{:.term}{:#term-transaction-malleability}. The scriptSig -contains the signature, which can't sign itself, allowing attackers to +malleability][]{:.term}{:#term-transaction-malleability}. The signature script +contains the secp256k1 signature, which can't sign itself, allowing attackers to make non-functional modifications to a transaction without rendering it -invalid. For example, an attacker can add some data to the scriptSig -which will be dropped before the previous scriptPubKey is processed. +invalid. For example, an attacker can add some data to the signature script +which will be dropped before the previous pubkey script is processed. Although the modifications are non-functional---so they do not change what inputs the transaction uses nor what outputs it pays---they do diff --git a/_includes/guide_wallets.md b/_includes/guide_wallets.md index f348f353..aa7ee6ac 100644 --- a/_includes/guide_wallets.md +++ b/_includes/guide_wallets.md @@ -223,7 +223,7 @@ design these minimalist wallets: ![Distributing-Only Wallets](/img/dev/en-wallets-distributing-only.svg) * Pre-populate a database with a number of public keys or addresses, and - then distribute on request an output scriptPubKey or address using one of + then distribute on request a pubkey script or address using one of the database entries. To [avoid key reuse][devguide avoiding key reuse], webservers should keep track of used keys and never run out of public keys. This can be made easier @@ -356,8 +356,8 @@ However, Bitcoin Core prior to 0.6 used uncompressed keys. This creates a few complications, as the hashed form of an uncompressed key is different than the hashed form of a compressed key, so the same key works with two different P2PKH addresses. This also means that the key -must be submitted in the correct format in the input scriptSig so it -matches the hash in the previous output scriptPubKey. +must be submitted in the correct format in the signature script so it +matches the hash in the previous output's pubkey script. For this reason, Bitcoin Core uses several different identifier bytes to help programs identify how keys should be used: diff --git a/_includes/ref_block_chain.md b/_includes/ref_block_chain.md index 134ddb9a..293fb3c5 100644 --- a/_includes/ref_block_chain.md +++ b/_includes/ref_block_chain.md @@ -39,8 +39,8 @@ fees and block reward. The coinbase transaction has the same basic format as any other transaction, but it references a single non-existent UTXO and a special -[coinbase field][]{:#term-coinbase-field}{:.term} replaces the field that would normally hold a scriptSig and -signature. In version 2 blocks, the coinbase parameter must begin with +[coinbase field][]{:#term-coinbase-field}{:.term} replaces the field that would normally hold a signature script and +secp256k1 signature. In version 2 blocks, the coinbase parameter must begin with the current block's block height and may contain additional arbitrary data or a script up to a maximum total of 100 bytes. diff --git a/_includes/ref_core_rpcs-abcdefg.md b/_includes/ref_core_rpcs-abcdefg.md index 758b8dd0..2e8f27df 100644 --- a/_includes/ref_core_rpcs-abcdefg.md +++ b/_includes/ref_core_rpcs-abcdefg.md @@ -17,7 +17,7 @@ Related RPCs: `createmultisig` {% autocrossref %} *Number; required:* the *minimum* (*m*) number of signatures required to -spend satoshis sent to this m-of-n P2SH multisig script. +spend satoshis sent to this m-of-n P2SH multisig pubkey script. {% endautocrossref %} @@ -31,7 +31,7 @@ spend satoshis sent to this m-of-n P2SH multisig script. *String; required:* A JSON array of hex-encoded public *keys* or *addresses* for public keys known to this Bitcoin Core instance. The multisig -script can only use full (unhashed) public keys, so you generally must +pubkey script can only use full (unhashed) public keys, so you generally must provide public keys for any address not known to this wallet. {% endautocrossref %} @@ -61,7 +61,7 @@ store the address. {% autocrossref %} -*String:* a hash of the P2SH multisig redeemScript, which is also stored +*String:* a hash of the P2SH multisig redeem script, which is also stored in the wallet so Bitcoin Core can monitor the network and block chain for transactions sent to that address (which will be displayed in the wallet as spendable balances). @@ -221,7 +221,7 @@ Related RPCs: `addmultisigaddress` {% autocrossref %} *Number; required:* the *minimum* (*m*) number of signatures required to -spend satoshis sent to this m-of-n multisig script. +spend satoshis sent to this m-of-n multisig pubkey script. {% endautocrossref %} @@ -235,7 +235,7 @@ spend satoshis sent to this m-of-n multisig script. *String; required:* A JSON array of hex-encoded public *keys* or *addresses* for public keys known to this Bitcoin Core instance. The multisig -script can only use full (unhashed) public keys, so you generally must +pubkey script can only use full (unhashed) public keys, so you generally must provide public keys for any address not known to this wallet. {% endautocrossref %} @@ -247,7 +247,7 @@ provide public keys for any address not known to this wallet. ] ~~~ -**Result: Address And Hex-Encoded RedeemScript** +**Result: Address And Hex-Encoded Redeem Script** {% autocrossref %} @@ -477,9 +477,9 @@ and *hex*, and the input sequence number. {% autocrossref %} A JSON array of outputs, with each output containing a *value* in decimal -bitcoins, an output index number (*n*), a script (*scriptPubKey*) in +bitcoins, an output index number (*n*), a pubkey script (*scriptPubKey*) in script-language psuedocode (*asm*) and *hex*, the number of signatures -required (*reqSigs*), the *type* of script (if it's a standard +required (*reqSigs*), the *type* of pubkey script (if it's a standard transaction), and an array of *addresses* used in the output. (More than one address means it's a multisig output.) @@ -595,15 +595,15 @@ decodescript {% autocrossref %} -Decode a hex-encoded P2SH redeemScript. +Decode a hex-encoded P2SH redeem script. {% endautocrossref %} -**Argument: A Hex-Encoded RedeemScript** +**Argument: A Hex-Encoded Redeem Script** {% autocrossref %} -*String; required:* an complete (not hashed) redeemScript in hex. +*String; required:* an complete (not hashed) redeem script in hex. {% endautocrossref %} @@ -611,7 +611,7 @@ Decode a hex-encoded P2SH redeemScript. {% autocrossref %} -A JSON object describing the redeemScript, with *asm* being the script +A JSON object describing the redeem script, with *asm* being the script in script-language psuedocode, *hex* being the a P2PKH public key (if applicable), *type* being the output type (typically public key, multisig, or nonstandard), *reqSigs* being the required signatures, @@ -638,7 +638,7 @@ public keys. {% autocrossref %} -A 2-of-3 P2SH multisig script: +A 2-of-3 P2SH multisig pubkey script: {% endautocrossref %} @@ -2994,9 +2994,9 @@ only to display UTXOs on the block chain with *false* (the default). *String:* A JSON object describing the output, with *bestblock* providing the header hash of the block which includes the UTXO (if any), the number of *confirmations* the UTXO has, the *value* of the output in -decimal bitcoins, and a JSON object describing the output script, +decimal bitcoins, and a JSON object describing the pubkey script, including the script in script psuedocode (*asm*), the script in *hex*, -the number of *required signatures*, the *type* of output script, and +the number of *required signatures*, the *type* of pubkey script, and the *addresses* it references (if known). Also provided are the UTXO's transaction *version* number and whether or not it's a *coinbase* transaction. diff --git a/_includes/ref_core_rpcs-hijklmn.md b/_includes/ref_core_rpcs-hijklmn.md index 2411255b..504b13aa 100644 --- a/_includes/ref_core_rpcs-hijklmn.md +++ b/_includes/ref_core_rpcs-hijklmn.md @@ -828,7 +828,7 @@ affecting these addresses will returned. A JSON array with a list of JSON objects, each object describing a single transaction: its *txid*, output index number (*vout*), *address*, -the *account* that address belongs to, the unsigned scriptSig +the *account* that address belongs to, the unsigned pubkey script (*scriptPubKey*) to spend it, the *amount* in decimal bitcoins, and the number of *confirmations* the transactions has. diff --git a/_includes/ref_core_rpcs-opqrst.md b/_includes/ref_core_rpcs-opqrst.md index 2aa55a26..d612452f 100644 --- a/_includes/ref_core_rpcs-opqrst.md +++ b/_includes/ref_core_rpcs-opqrst.md @@ -682,7 +682,7 @@ details about an unknown-to-this-node P2SH transaction that this transaction depends upon. Each previous P2SH transaction must include its *txid* in hex, output -index number (*vout*), public key (*scriptPubKey*) in hex, and +index number (*vout*), pubkey script (*scriptPubKey*) in hex, and *redeemScript* in hex. {% endautocrossref %} diff --git a/_includes/ref_transactions.md b/_includes/ref_transactions.md index 1a7e095f..da9cf728 100644 --- a/_includes/ref_transactions.md +++ b/_includes/ref_transactions.md @@ -6,7 +6,7 @@ The following subsections briefly document core transaction details. {% autocrossref %} -The op codes used in the scriptPubKeys of standard transactions are: +The op codes used in the pubkey scripts of standard transactions are: * Various data pushing op codes from 0x00 to 0x4e (1--78). These aren't typically shown in examples, but they must be used to push @@ -44,7 +44,7 @@ The op codes used in the scriptPubKeys of standard transactions are: The "one extra value" it consumes is the result of an off-by-one error in the Bitcoin Core implementation. This value is not used, so - scriptSigs prefix the signatures with a single OP_0 (0x00). + signature scripts prefix the secp256k1 signatures with a single OP_0 (0x00). * [`OP_RETURN`][op_return]{:#term-op-return}{:.term} terminates the script in failure when executed. @@ -53,8 +53,8 @@ Page][wiki script], with an authoritative list in the `opcodetype` enum of the Bitcoin Core [script header file][core script.h] Note: non-standard transactions can add non-data-pushing op codes to -their scriptSig, but scriptSig is run separately from the script (with a -shared stack), so scriptSig can't use arguments such as `OP_RETURN` to +their signature script, but signature scripts are run separately from the pubkey scripts (with a +shared stack), so signature scripts can't use arguments such as `OP_RETURN` to prevent the script from working as expected. {% endautocrossref %} @@ -69,7 +69,7 @@ addresses. First, get your hash. For P2PKH, you RIPEMD-160(SHA256()) hash a ECDSA public key derived from your 256-bit ECDSA private key (random data). -For P2SH, you RIPEMD-160(SHA256()) hash a redeemScript serialized in the +For P2SH, you RIPEMD-160(SHA256()) hash a redeem script serialized in the format used in raw transactions (described in a [following sub-section][raw transaction format]). Taking the resulting hash: @@ -173,8 +173,9 @@ fa 20 9c 6a 85 2d d9 06 ed ce 25 85 7f cd 37 04 00 00 00 00 previous output index -48 size of scriptSig (var_uint) -scriptSig for input 0: +48 size of signature script (var_uint) + +Signature script for input 0: 47 push 71 bytes to stack 30 44 02 20 4e 45 e1 69 32 b8 af 51 49 61 a1 d3 @@ -191,8 +192,9 @@ ff ff ff ff sequence number output 0: 00 ca 9a 3b 00 00 00 00 amount = 10.00000000 BTC -43 size of scriptPubKey (var_uint) -scriptPubKey for output 0: +43 size of pubkey script (var_uint) + +Pubkey script for output 0: 41 push 65 bytes to stack 04 ae 1a 62 fe 09 c5 f5 1b 13 90 5f 07 f0 6b 99 @@ -207,8 +209,9 @@ ac OP_CHECKSIG output 1: 00 28 6b ee 00 00 00 00 amount = 40.00000000 BTC -43 size of scriptPubKey (var_uint) -scriptPubKey for output 1: +43 size of pubkey script (var_uint) + +Pubkey script for output 1: 41 push 65 bytes to stack 04 11 db 93 e1 dc db 8a 01 6b 49 84 0f 8c 53 bc diff --git a/_includes/references.md b/_includes/references.md index bbf96e39..a79f55ad 100644 --- a/_includes/references.md +++ b/_includes/references.md @@ -66,12 +66,12 @@ [miner]: /en/developer-guide#term-miner "Creators of Bitcoin blocks who solve proof-of-work puzzles in exchange for block rewards and transaction fees" [miners]: /en/developer-guide#term-miner "Creators of Bitcoin blocks who solve proof-of-work puzzles in exchange for block rewards and transaction fees" [minimum fee]: /en/developer-guide#term-minimum-fee "The minimum fee a transaction must pay in must circumstances to be mined or broadcast by peers across the network" -[multisig]: /en/developer-guide#term-multisig "An output scriptPubKey using OP_CHECKMULTISIG to check for multiple signatures" +[multisig]: /en/developer-guide#term-multisig "An pubkey script using OP_CHECKMULTISIG to check for multiple signatures" [network]: /en/developer-guide#term-network "The Bitcoin P2P network which broadcasts transactions and blocks" [Null data]: /en/developer-guide#term-null-data "A standard transaction type which allows adding 40 bytes of arbitrary data to the block chain up to once per transaction" [op_checkmultisig]: /en/developer-reference#term-op-checkmultisig "Op code which returns true if one or more provided signatures (m) sign the correct parts of a transaction and match one or more provided public keys (n)" [op_checksig]: /en/developer-reference#term-op-checksig "Op code which returns true if a signature signs the correct parts of a transaction and matches a provided public key" -[op code]: /en/developer-reference#op-codes "Operation codes which run functions within a script" +[op code]: /en/developer-reference#op-codes "Operation codes which push data or run functions within a pubkey script or signature script" [op_dup]: /en/developer-reference#term-op-dup "Operation which duplicates the entry below it on the stack" [op_equal]: /en/developer-reference#term-op-equal "Operation which returns true if the two entries below it on the stack are equivalent" [op_equalverify]: /en/developer-reference#term-op-equalverify "Operation which terminates the script in failure unless the two entries below it on the stack are equivalent" @@ -79,12 +79,11 @@ [op_return]: /en/developer-reference#term-op-return "Operation which terminates the script in failure" [op_verify]: /en/developer-reference#term-op-verify "Operation which terminates the script if the entry below it on the stack is non-true (zero)" [orphan]: /en/developer-guide#term-orphan "Blocks which were successfully mined but which aren't included on the current valid block chain" -[output]: /en/developer-guide#term-output "The output of a transaction which transfers value to a scriptPubKey" +[output]: /en/developer-guide#term-output "The output of a transaction which transfers value to a pubkey script" [output index]: /en/developer-guide#term-output-index "The sequentially-numbered index of outputs in a single transaction starting from 0" -[outputs]: /en/developer-guide#term-output "The outputs of a transaction which transfer value to scriptPubKeys" -[P2PKH]: /en/developer-guide#term-p2pkh "A scriptPubKey which Pays To Pubkey Hashes (P2PKH), allowing spending of satoshis to anyone with a Bitcoin address" -[P2SH]: /en/developer-guide#term-p2sh "A scriptPubKey which Pays To Script Hashes (P2SH), allowing convenient spending of satoshis to an address referencing a script" -[P2SH multisig]: /en/developer-guide#term-p2sh-multisig "A multisig script embedded in the redeemScript of a pay-to-script-hash (P2SH) transaction" +[P2PKH]: /en/developer-guide#term-p2pkh "A pubkey script which Pays To PubKey Hashes (P2PKH), allowing spending of satoshis to anyone with a Bitcoin address" +[P2SH]: /en/developer-guide#term-p2sh "A pubkey script which Pays To Script Hashes (P2SH), allowing convenient spending of satoshis to an address referencing a redeem script" +[P2SH multisig]: /en/developer-guide#term-p2sh-multisig "A multisig script embedded in the redeem script of a pay-to-script-hash (P2SH) transaction" [parent chain code]: /en/developer-guide#term-parent-chain-code "A chain code which has helped create child public or private keys" [parent key]: /en/developer-guide#term-parent-key "In HD wallets, a key capable of deriving child keys" [parent private key]: /en/developer-guide#term-parent-private-key "A private key which has created child private keys" @@ -101,20 +100,21 @@ [private keys]: /en/developer-guide#term-private-key "The private portion of a keypair which can create signatures which other people can verify using the public key" [pubkey hash]: /en/developer-guide#term-pubkey-hash "The hash of a public key which can be included in a P2PKH output" [public key]: /en/developer-guide#term-public-key "The public portion of a keypair which can be safely distributed to other people so they can verify a signature created with the corresponding private key" -[pp amount]: /en/developer-examples#term-pp-amount "Part of the Output part of the PaymentDetails part of a payment protocol where receivers can specify the amount of satoshis they want paid to a particular output scriptPubKey" +[pp amount]: /en/developer-examples#term-pp-amount "Part of the Output part of the PaymentDetails part of a payment protocol where receivers can specify the amount of satoshis they want paid to a particular pubkey script" [pp expires]: /en/developer-examples#term-pp-expires "The expires field of a PaymentDetails where the receiver tells the spender when the PaymentDetails expires" [pp memo]: /en/developer-examples#term-pp-memo "The memo fields of PaymentDetails, Payment, and PaymentACK which allow spenders and receivers to send each other memos" [pp merchant data]: /en/developer-examples#term-pp-merchant-data "The merchant_data part of PaymentDetails and Payment which allows the receiver to send arbitrary data to the spender in PaymentDetails and receive it back in Payments" [pp PKI data]: /en/developer-examples#term-pp-pki-data "The pki_data field of a PaymentRequest which provides details such as certificates necessary to validate the request" [pp pki type]: /en/developer-examples#term-pp-pki-type "The PKI field of a PaymentRequest which tells spenders how to validate this request as being from a specific recipient" -[pp script]: /en/developer-examples#term-pp-script "The script field of a PaymentDetails where the receiver tells the spender what output scripts to pay" +[pp script]: /en/developer-examples#term-pp-script "The script field of a PaymentDetails where the receiver tells the spender what pubkey scripts to pay" [proof of work]: /en/developer-guide#term-proof-of-work "Proof that computationally-difficult work was performed which helps secure blocks against modification, protecting transaction history" -[Pubkey]: /en/developer-guide#term-pubkey "A standard output scriptPubKey which specifies the full public key to match a signature; used in coinbase transactions" +[Pubkey]: /en/developer-guide#term-pubkey "A cryptographic public key derived from a private key and which can match a signature made by that same private key" +[pubkey script]: /en/developer-guide#term-pubkey-script "The part of an output which sets the conditions for spending of the satoshis in that output" [r]: /en/developer-guide#term-r-parameter "The payment request parameter in a bitcoin: URI" [raw format]: /en/developer-reference#term-raw-format "Complete transactions in their binary format; often represented using hexidecimal" [receipt]: /en/developer-guide#term-receipt "A cryptographically-verifiable receipt created using parts of a payment request and a confirmed transaction" [recurrent rebilling]: /en/developer-guide#rebilling-recurring-payments "Billing a spender on a regular schedule" -[redeemScript]: /en/developer-guide#term-redeemscript "A script created by the recipient, hashed, and given to the spender for use in a P2SH output" +[redeem script]: /en/developer-guide#term-redeem-script "A pubkey script created by the recipient, hashed, and given to the spender for use in a P2SH output" [refund]: /en/developer-guide#issuing-refunds "A transaction which refunds some or all satoshis received in a previous transaction" [regression test mode]: /en/developer-examples#regtest-mode "A local testing environment in which developers can control blocks" [root certificate]: /en/developer-examples#term-root-certificate "A certificate belonging to a certificate authority (CA)" @@ -122,23 +122,21 @@ [satoshi]: /en/developer-guide#term-satoshi "The smallest unit of Bitcoin value; 0.00000001 bitcoins. Also used generically for any value of bitcoins" [satoshis]: /en/developer-guide#term-satoshi "The smallest unit of Bitcoin value; 0.00000001 bitcoins. Also used generically for any value of bitcoins" [sequence number]: /en/developer-guide#term-sequence-number "A number intended to allow time locked transactions to be updated before being finalized; not currently used except to disable locktime in a transaction" -[scriptPubKey]: /en/developer-guide#term-scriptpubkey "The part of an output which sets the conditions for spending of the satoshis in that output" -[scriptPubKeys]: /en/developer-guide#term-scriptpubkey "The part of an output which sets the conditions for spending of the satoshis in that output" -[scriptSig]: /en/developer-guide#term-scriptsig "Data generated by a spender which is almost always used as variables to satisfy an output script" -[script hash]: /en/developer-guide#term-script-hash "The hash of a redeemScript used to create a P2SH output" +[script hash]: /en/developer-guide#term-script-hash "The hash of a redeem script used to create a P2SH output" [sha_shacp]: /en/developer-guide#term-sighash-all-sighash-anyonecanpay "Signature hash type which allows other people to contribute satoshis without changing the number of satoshis sent nor where they go" [shacp]: /en/developer-guide#term-sighash-anyonecanpay "A signature hash type which modifies the behavior of other signature hash types" [shn_shacp]: /en/developer-guide#term-sighash-none-sighash-anyonecanpay "Signature hash type which allows unfettered modification of a transaction" [shs_shacp]: /en/developer-guide#term-sighash-single-sighash-anyonecanpay "Signature hash type which allows modification of the entire transaction except the signed input and the output with the same index number" -[sighash_all]: /en/developer-guide#term-sighash-all "Default signature hash type which signs the entire transaction except any scriptSigs, preventing modification of the signed parts" +[sighash_all]: /en/developer-guide#term-sighash-all "Default signature hash type which signs the entire transaction except any signature scripts, preventing modification of the signed parts" [sighash_none]: /en/developer-guide#term-sighash-none "Signature hash type which only signs the inputs, allowing anyone to change the outputs however they'd like" [sighash_single]: /en/developer-guide#term-sighash-single "Signature hash type which only signs its input and the output with the same index value, allowing modification of other inputs and outputs" [signature]: /en/developer-guide#term-signature "The result of combining a private key and some data in an ECDSA signature operation which allows anyone with the corresponding public key to verify the signature" [signature hash]: /en/developer-guide#term-signature-hash "A byte appended onto signatures generated in Bitcoin which allows the signer to specify what data was signed, allowing modification of the unsigned data" +[signature script]: /en/developer-guide#term-signature-script "Data generated by a spender which is almost always used as variables to satisfy a pubkey script" [spv]: /en/developer-guide#simplified-payment-verification-spv "A method for verifying particular transactions were included in blocks without downloading the entire contents of the block chain" [ssl signature]: /en/developer-examples#term-ssl-signature "Signatures created and recognized by major SSL implementations such as OpenSSL" [stack]: /en/developer-guide#term-stack "An evaluation stack used in Bitcoin's script language" -[standard script]: /en/developer-guide#standard-transactions "An output scriptPubKey which matches the isStandard() patterns specified in Bitcoin Core---or a transaction containing only standard outputs. Only standard transactions are mined or broadcast by peers running the default Bitcoin Core software" +[standard script]: /en/developer-guide#standard-transactions "A pubkey script which matches the IsStandard() patterns specified in Bitcoin Core---or a transaction containing only standard outputs. Only standard transactions are mined or broadcast by peers running the default Bitcoin Core software" [target]: /en/developer-guide#term-target "The threshold below which a block header hash must be in order for the block to be added to the block chain" [testnet]: /en/developer-examples#testnet "A Bitcoin-like network where the satoshis have no real-world value to allow risk-free testing" [transaction fee]: /en/developer-guide#term-transaction-fee "The amount remaining when all outputs are subtracted from all inputs in a transaction; the fee is paid to the miner who includes that transaction in a block" diff --git a/img/dev/en-creating-p2sh-output.dot b/img/dev/en-creating-p2sh-output.dot index 7980ff51..bcc72323 100644 --- a/img/dev/en-creating-p2sh-output.dot +++ b/img/dev/en-creating-p2sh-output.dot @@ -14,7 +14,7 @@ penwidth = 1.75; subgraph cluster_bob { private_key [ label = "Private\nKey" ]; full_public_key [ label = "Full\nPublic Key" ]; - redeemScript [ label = "RedeemScript" ]; + redeemScript [ label = "Redeem Script" ]; script_hash [ label = "Script\nHash" ]; label = "Bob's Computer" @@ -38,5 +38,5 @@ private_key -> full_public_key -> redeemScript -> script_hash -> spender_script_ -label = "Creating A P2SH RedeemScript Hash To Receive Payment" +label = "Creating A P2SH Redeem Script Hash To Receive Payment" } diff --git a/img/dev/en-creating-p2sh-output.png b/img/dev/en-creating-p2sh-output.png index 4ab87636..47a1b825 100644 Binary files a/img/dev/en-creating-p2sh-output.png and b/img/dev/en-creating-p2sh-output.png differ diff --git a/img/dev/en-creating-p2sh-output.svg b/img/dev/en-creating-p2sh-output.svg index f85b97c0..91fe52be 100644 --- a/img/dev/en-creating-p2sh-output.svg +++ b/img/dev/en-creating-p2sh-output.svg @@ -4,35 +4,35 @@ - - + + blockchain - -Creating A P2SH RedeemScript Hash To Receive Payment + +Creating A P2SH Redeem Script Hash To Receive Payment cluster_bob - -Bob's Computer + +Bob's Computer cluster_alice - -Alice's Computer + +Alice's Computer cluster_tx1 - -TX 1 + +TX 1 private_key -Private -Key +Private +Key full_public_key -Full -Public Key +Full +Public Key private_key->full_public_key @@ -41,48 +41,48 @@ redeemScript - -RedeemScript + +Redeem Script full_public_key->redeemScript - - + + script_hash - -Script -Hash + +Script +Hash redeemScript->script_hash - - + + spender_script_hash - -Copy Of -Script -Hash + +Copy Of +Script +Hash script_hash->spender_script_hash - - + + tx1_script_hash - -Copy Of -Script -Hash + +Copy Of +Script +Hash spender_script_hash->tx1_script_hash - - + + diff --git a/img/dev/en-p2pkh-stack.dot b/img/dev/en-p2pkh-stack.dot index 08a4b629..4fd184f3 100644 --- a/img/dev/en-p2pkh-stack.dot +++ b/img/dev/en-p2pkh-stack.dot @@ -23,7 +23,7 @@ subgraph cluster_alice { alice_pubkey [style = invis, label="PubKey", shape = "" ]; alice_sig [style = invis, label="Sig", shape = "" ]; - label = "Instructions And Data Provided By Alice In Transaction #1's Output Script" + label = "Instructions And Data Provided By Alice In Transaction #1's Pubkey Script" /* label = "Data Provided By Spender 1 To Spend Output" */ } @@ -37,7 +37,7 @@ subgraph cluster_bob { bob_pubkey [style = unfilled, label="PubKey", shape = "" ]; bob_sig [style = unfilled, label="Sig", shape = "" ]; - label = "Data Provided By Bob In Transaction #2's Input ScriptSig" + label = "Data Provided By Bob In Transaction #2's Input Signature Script" } alice_sig -> bob_sig; diff --git a/img/dev/en-p2pkh-stack.png b/img/dev/en-p2pkh-stack.png index b5bacc03..f383f58b 100644 Binary files a/img/dev/en-p2pkh-stack.png and b/img/dev/en-p2pkh-stack.png differ diff --git a/img/dev/en-p2pkh-stack.svg b/img/dev/en-p2pkh-stack.svg index 871b8e83..7ab80ca2 100644 --- a/img/dev/en-p2pkh-stack.svg +++ b/img/dev/en-p2pkh-stack.svg @@ -12,11 +12,11 @@ Evaluation Stack Over Time During Succesful P2PKH Script Validation cluster_alice -Instructions And Data Provided By Alice In Transaction #1's Output Script +Instructions And Data Provided By Alice In Transaction #1's Pubkey Script cluster_bob -Data Provided By Bob In Transaction #2's Input ScriptSig +Data Provided By Bob In Transaction #2's Input Signature Script alice_opchecksig diff --git a/img/dev/en-signing-output-to-spend.dot b/img/dev/en-signing-output-to-spend.dot index 88d8990d..7c49e928 100644 --- a/img/dev/en-signing-output-to-spend.dot +++ b/img/dev/en-signing-output-to-spend.dot @@ -2,7 +2,7 @@ digraph blockchain { size="6.25"; -//splines = "false"; +splines = "false"; rankdir=TB; ranksep=-0.1; //splines=ortho; @@ -16,7 +16,7 @@ penwidth = 1.75; subgraph cluster_tx1 { tx1_txid [ label = "TXID" ]; tx1_vout [ label = "Output Index Number" ]; - tx1_script [ label = "Script" ]; + tx1_script [ label = "Pubkey Script" ]; label = "Transaction 1 (TX 1)" } @@ -30,18 +30,18 @@ subgraph cluster_sig { sig_tx1_vout [ width = 2.3 ]; sig_tx1_script [ width = 1.6 ]; //nil_pubkey [ width = 1.3 ]; - sig_tx2t_script [ width = 0.75 ]; + sig_tx2t_script [ width = 1.65 ]; sig_tx2t_amount [ width = 0.95 ]; signature [ width = 1.25 ]; - label = "Signed Data" + label = " Signed Data" } subgraph cluster_tx2 { tx2_tx1_txid [ label = "TXID" ]; tx2_tx1_vout [ label = "Output Index Number" ]; - tx2_script [ label = "Script" ]; + tx2_script [ label = "Pubkey Script" ]; public_key [ label = "Full Public Key" ]; tx2_amount [ label = "Amount" ]; tx2_signature [ label = "Signature" ]; @@ -54,7 +54,7 @@ subgraph cluster_bob { label = "Bob's Computer" subgraph cluster_tx2t { - tx2t_script [ label = "Script" ]; + tx2t_script [ label = "Pubkey Script" ]; tx2t_amount [ label = "Amount" ]; label = "TX2 Template" @@ -65,22 +65,25 @@ subgraph cluster_tx2t { { edge [ arrowhead = "dot" ]; tx1_script -> sig_tx1_script; -tx1_txid -> sig_tx1_txid; -tx1_vout -> sig_tx1_vout; -tx2t_script -> sig_tx2t_script; -tx2t_amount -> sig_tx2t_amount; +tx1_txid -> sig_tx1_txid [ style = "invis" ]; +tx1_vout -> sig_tx1_vout [ style = "invis" ]; +tx2t_script -> sig_tx2t_script [ style = "invis" ]; +tx2t_amount -> sig_tx2t_amount [ style = "invis" ]; private_key -> signature [ style = "dotted" ]; } -sig_tx1_txid -> tx2_tx1_txid; -sig_tx1_vout -> tx2_tx1_vout; -sig_tx2t_script -> tx2_script; -sig_tx2t_amount -> tx2_amount; +sig_tx1_txid -> tx2_tx1_txid [ style = "invis" ]; +sig_tx1_vout -> tx2_tx1_vout [ style = "invis" ]; +sig_tx2t_script -> tx2_script [ style = "invis" ]; +sig_tx2t_amount -> tx2_amount [ style = "invis" ]; signature -> tx2_signature; - +tx1_txid -> tx2_tx1_txid [ constraint = false ]; +tx1_vout -> tx2_tx1_vout [ constraint = false ]; +tx2t_script -> tx2_script [ constraint = false ]; +tx2t_amount -> tx2_amount [ constraint = false ]; label = "Some Of The Data Signed By Default" diff --git a/img/dev/en-signing-output-to-spend.png b/img/dev/en-signing-output-to-spend.png index c5ee05ce..bec0cb9a 100644 Binary files a/img/dev/en-signing-output-to-spend.png and b/img/dev/en-signing-output-to-spend.png differ diff --git a/img/dev/en-signing-output-to-spend.svg b/img/dev/en-signing-output-to-spend.svg index f09b835f..a0551595 100644 --- a/img/dev/en-signing-output-to-spend.svg +++ b/img/dev/en-signing-output-to-spend.svg @@ -4,152 +4,140 @@ - - + + blockchain - -Some Of The Data Signed By Default + +Some Of The Data Signed By Default cluster_tx1 - -Transaction 1 (TX 1) + +Transaction 1 (TX 1) cluster_sig - -Signed Data + +           Signed Data cluster_tx2 - -Transaction 2 + +Transaction 2 cluster_bob - -Bob's Computer + +Bob's Computer cluster_tx2t - -TX2 Template + +TX2 Template tx1_txid - -TXID + +TXID -tx1_txid->sig_tx1_txid - - + +tx2_tx1_txid + +TXID + + +tx1_txid->tx2_tx1_txid + + tx1_vout - -Output Index Number + +Output Index Number -tx1_vout->sig_tx1_vout - - + +tx2_tx1_vout + +Output Index Number + + +tx1_vout->tx2_tx1_vout + + tx1_script - -Script + +Pubkey Script tx1_script->sig_tx1_script - - - - -tx2_tx1_txid - -TXID + + -sig_tx1_txid->tx2_tx1_txid - - - - -tx2_tx1_vout - -Output Index Number - -sig_tx1_vout->tx2_tx1_vout - - - tx2_script - -Script + +Pubkey Script -sig_tx2t_script->tx2_script - - - tx2_amount - -Amount + +Amount -sig_tx2t_amount->tx2_amount - - - tx2_signature - -Signature + +Signature signature->tx2_signature - - + + public_key - -Full Public Key + +Full Public Key private_key - -Private Key + +Private Key private_key->signature - - + + tx2t_script - -Script + +Pubkey Script -tx2t_script->sig_tx2t_script - - + +tx2t_script->tx2_script + + tx2t_amount - -Amount + +Amount -tx2t_amount->sig_tx2t_amount - - + +tx2t_amount->tx2_amount + + diff --git a/img/dev/en-unlocking-p2pkh-output.dot b/img/dev/en-unlocking-p2pkh-output.dot index 1d417a48..1e735f4b 100644 --- a/img/dev/en-unlocking-p2pkh-output.dot +++ b/img/dev/en-unlocking-p2pkh-output.dot @@ -15,10 +15,10 @@ graph [ fontname="Sans" ]; penwidth = 1.75; subgraph cluster_tx2 { - scriptSig [ label = "ScriptSig", shape = "none" ]; + scriptSig [ label = "Signature Script", shape = "none" ]; tx2_signature [ label = "Signature" ]; tx2_full_public_key [ label = "Full Public Key" ]; - script [ label = " \nScript", shape = "none" ]; + script [ label = " \nPubkey Script", shape = "none" ]; tx2_pubkey_hash [ label = "Public Key Hash" ]; } diff --git a/img/dev/en-unlocking-p2pkh-output.png b/img/dev/en-unlocking-p2pkh-output.png index 9f2b20a3..3760779e 100644 Binary files a/img/dev/en-unlocking-p2pkh-output.png and b/img/dev/en-unlocking-p2pkh-output.png differ diff --git a/img/dev/en-unlocking-p2pkh-output.svg b/img/dev/en-unlocking-p2pkh-output.svg index 4d70e373..8410c6d1 100644 --- a/img/dev/en-unlocking-p2pkh-output.svg +++ b/img/dev/en-unlocking-p2pkh-output.svg @@ -4,67 +4,67 @@ - - + + blockchain - - -Spending A P2PKH Output + + +Spending A P2PKH Output cluster_tx2 - + cluster_tx1 TX 1 Output cluster_bob - -Bob's Computer + +Bob's Computer scriptSig -ScriptSig +Signature Script tx2_signature - -Signature + +Signature private_key - -Private Key + +Private Key tx2_signature->private_key - - + + tx2_full_public_key - -Full Public Key + +Full Public Key full_public_key - -Full Public Key + +Full Public Key tx2_full_public_key->full_public_key - - + + script - -Script + +Pubkey Script tx2_pubkey_hash - -Public Key Hash + +Public Key Hash tx1_pubkey_hash @@ -73,8 +73,8 @@ tx1_pubkey_hash->tx2_pubkey_hash - - + + diff --git a/img/dev/en-unlocking-p2sh-output.dot b/img/dev/en-unlocking-p2sh-output.dot index 9d0a4392..165f173d 100644 --- a/img/dev/en-unlocking-p2sh-output.dot +++ b/img/dev/en-unlocking-p2sh-output.dot @@ -14,23 +14,23 @@ edge [ penwidth = 1.75, minlen = 2 ]; penwidth = 1.75; subgraph cluster_tx2 { - scriptSig [ label = "ScriptSig", shape = "none" ]; + scriptSig [ label = "Signature Script", shape = "none" ]; tx2_signature [ label = "Signature" ]; - tx2_redeemScript [ label = "Full RedeemScript" ]; - script [ label = " \nScript", shape = "none" ]; - tx2_redeemScript_hash [ label = "RedeemScript Hash" ]; + tx2_redeemScript [ label = "Full Redeem Script" ]; + script [ label = " \nPubkey Script", shape = "none" ]; + tx2_redeemScript_hash [ label = "Redeem Script Hash" ]; } subgraph cluster_tx1 { - tx1_redeemScript_hash [ label = "RedeemScript Hash" ]; + tx1_redeemScript_hash [ label = "Redeem Script Hash" ]; label = "TX 1 Output" } subgraph cluster_bob { private_key [ label = "Private Key" ]; - redeemScript [ label = "Full RedeemScript" ]; + redeemScript [ label = "Full Redeem Script" ]; label = "Bob's Computer" } diff --git a/img/dev/en-unlocking-p2sh-output.png b/img/dev/en-unlocking-p2sh-output.png index 5ee3e334..5fa0af0f 100644 Binary files a/img/dev/en-unlocking-p2sh-output.png and b/img/dev/en-unlocking-p2sh-output.png differ diff --git a/img/dev/en-unlocking-p2sh-output.svg b/img/dev/en-unlocking-p2sh-output.svg index 69ce831e..5a0f9c80 100644 --- a/img/dev/en-unlocking-p2sh-output.svg +++ b/img/dev/en-unlocking-p2sh-output.svg @@ -4,77 +4,77 @@ - - + + blockchain - - -Spending A P2SH Output + + +Spending A P2SH Output cluster_tx2 - + cluster_tx1 - -TX 1 Output + +TX 1 Output cluster_bob - -Bob's Computer + +Bob's Computer scriptSig -ScriptSig +Signature Script tx2_signature - -Signature + +Signature private_key - -Private Key + +Private Key tx2_signature->private_key - - + + tx2_redeemScript - -Full RedeemScript + +Full Redeem Script redeemScript - -Full RedeemScript + +Full Redeem Script tx2_redeemScript->redeemScript - - + + script - -Script + +Pubkey Script tx2_redeemScript_hash - -RedeemScript Hash + +Redeem Script Hash tx1_redeemScript_hash - -RedeemScript Hash + +Redeem Script Hash tx1_redeemScript_hash->tx2_redeemScript_hash - - + +