From 9183f98bc1d6f76e4424378250fd566fc3e6a2d1 Mon Sep 17 00:00:00 2001 From: Peter Todd Date: Thu, 18 Sep 2014 21:10:31 -0400 Subject: [PATCH] Fix incorrect usage of 'script' rather than 'scriptPubKey' This is causing quite a bit of confusion, for example by people looking in the Bitcoin Core sourcecode and seeing the term 'scriptPubKey' instead. --- _includes/guide_contracts.md | 13 ++--- _includes/guide_operating_modes.md | 2 +- _includes/guide_transactions.md | 94 +++++++++++++++--------------- _includes/guide_wallets.md | 4 +- _includes/ref_transactions.md | 13 +++-- _includes/references.md | 20 +++---- 6 files changed, 73 insertions(+), 73 deletions(-) diff --git a/_includes/guide_contracts.md b/_includes/guide_contracts.md index 1fabae77..3114655d 100644 --- a/_includes/guide_contracts.md +++ b/_includes/guide_contracts.md @@ -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 -script, more generically called a m-of-n script (where *m* is the +scriptPubKey, more generically called a m-of-n scriptPubKey (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 public key and Alice's public key are included. Then he hashes the -redeemScript, puts it in a P2SH output, and pays the satoshis to it. Bob +redeemScript, to create a P2SH scriptPubKey, 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 unhashed redeemScript Bob created and +Charlie along with a copy of the redeemScript Bob created and Charlie checked. After looking at the evidence, Alice thinks a 40% refund is sufficient, @@ -78,12 +78,11 @@ 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 input section of the script, Alice puts her signature +In the scriptSig Alice puts her signature and a copy of the unhashed serialized redeemScript 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 input -script: +his signature to create the following scriptSig: {% endautocrossref %} @@ -98,7 +97,7 @@ 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 -input script against the P2SH output Charlie previously paid, +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 diff --git a/_includes/guide_operating_modes.md b/_includes/guide_operating_modes.md index e42ddaaf..63099951 100644 --- a/_includes/guide_operating_modes.md +++ b/_includes/guide_operating_modes.md @@ -68,7 +68,7 @@ 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 input and outputs scripts, 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 scriptSig and scriptPubKeys, 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_transactions.md b/_includes/guide_transactions.md index ed75cef3..19703a67 100644 --- a/_includes/guide_transactions.md +++ b/_includes/guide_transactions.md @@ -79,7 +79,7 @@ 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 output [script][]{:#term-script}{:.term}. +Bob's hashed public key. These instructions are called the [scriptPubKey][]{:#term-scriptPubKey}{:.term}. 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 @@ -90,21 +90,21 @@ 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 collection of data parameters which satisfy the conditions Alice placed -in the previous output's script. +in the previous output's scriptPubKey. ![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 -script's conditions. For a P2PKH-style output, Bob's scriptSig will +scriptPubKey's conditions. For a P2PKH-style output, Bob's scriptSig will contain the following two pieces of data: -1. His full (unhashed) public key, so the script can check that it +1. His full (unhashed) public key, so the scriptPubKey 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 certain transaction data (described below) with Bob's private key. - This lets the script verify that Bob owns the private key which + This lets the scriptPubKey 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 @@ -115,7 +115,7 @@ broadcast it over the peer-to-peer network. As illustrated in the figure above, the data Bob signs includes the txid and output index of the previous transaction, the previous -output's script, the script Bob creates which will let the next +output's scriptPubKey, the scriptPubKey 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 @@ -133,8 +133,8 @@ transactions. {% autocrossref %} -The validation procedure requires evaluation of the script. In a P2PKH -output, the script is: +The validation procedure requires evaluation of the scriptSig and scriptPubKey. +In a P2PKH output, the scriptPubKey is: {% endautocrossref %} @@ -170,10 +170,10 @@ 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 script arguments +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 script. The figure below shows the -evaluation of a standard P2PKH script; below the figure is a description +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 of the process. ![P2PKH Stack Evaluation](/img/dev/en-p2pkh-stack.svg) @@ -182,7 +182,7 @@ of the process. 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. -* From Alice's script, the `OP_DUP` operation is pushed. `OP_DUP` replaces +* From Alice's scriptPubKey, 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 +190,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 script then pushes the pubkey hash that Bob gave her for the +* Alice's scriptPubKey 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 script adds `OP_EQUALVERIFY` to the +* Now it gets interesting: Alice's scriptPubKey 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 +209,13 @@ of the process. the transaction validation fails. Otherwise it pops both itself and the *true* value off the stack. -* Finally, Alice's script pushes `OP_CHECKSIG`, which checks the +* Finally, Alice's scriptPubKey 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 *true* is at the top of the stack after the script has been +If *false* is not at the top of the stack after the scriptPubKey has been evaluated, the transaction is valid (provided there are no other problems with it). @@ -225,17 +225,17 @@ problems with it). {% autocrossref %} -Output scripts are created by spenders who have little interest in the +Transaction output scriptPubKey's 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 output script and, if they want, they can ask -spenders to use a particular script. Unfortunately, custom scripts are +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. To solve these problems, pay-to-script-hash ([P2SH][]{:#term-p2sh}{:.term}) transactions were created in 2012 to let -a spender create an output script containing a [hash of a second +a spender create a scriptPubKey containing a [hash of a second script][script hash]{:#term-script-hash}{:.term}, the [redeemScript][]{:#term-redeemscript}{:.term}. @@ -251,7 +251,7 @@ 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 value as the script hash Alice put in her output; it then processes the -redeemScript exactly as it would if it were the primary script, letting +redeemScript exactly as it would if it were the primary scriptPubKey, letting Bob spend the output if the redeemScript returns true. ![Unlocking A P2SH Output For Spending](/img/dev/en-unlocking-p2sh-output.svg) @@ -271,15 +271,15 @@ 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 they had an output script which matched a small set of +network if they had only scriptPubKeys and scriptSigs which 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 +is the `IsStandard()` test, and transactions which pass it are called standard transactions. Non-standard transactions---those that fail the test---may be accepted by nodes not using the default Bitcoin Core settings. If they are -included in blocks, they will also avoid the isStandard test and be +included in blocks, they will also avoid the IsStandard test and be processed. Besides making it more difficult for someone to attack Bitcoin for @@ -292,33 +292,33 @@ number, it would become useless as a tool for introducing backwards-incompatible features. -As of Bitcoin Core 0.9, the standard script types are: +As of Bitcoin Core 0.9, the standard scriptPubKey types are: **Pubkey Hash (P2PKH)** -P2PKH is the most common form of script used to send a transaction to one +P2PKH is the most common form of scriptPubKey used to send a transaction to one or multiple Bitcoin addresses. {% endautocrossref %} ~~~ -script: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG +scriptPubKey: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG scriptSig: ~~~ {% autocrossref %} -**Script Hash (P2SH)** +**Pay 2 Script Hash (P2SH)** P2SH is used to send a transaction to a script hash. Each of the standard -scripts can be used inside a P2SH redeemScript, but in practice only the -multisig script makes sense until more transaction types are made 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. {% endautocrossref %} ~~~ -script: OP_HASH160 OP_EQUAL -scriptSig: [sig] [sig...] +scriptPubKey: OP_HASH160 OP_EQUAL +scriptSig: [sig] [sig...] ~~~ {% autocrossref %} @@ -328,7 +328,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 scripts, called m-of-n, *m* is the *minimum* number of signatures +In multisig scriptPubKeys, 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. @@ -342,7 +342,7 @@ list of signatures in the scriptSig must be prefaced with an extra value {% endautocrossref %} ~~~ -script: [pubkey] [pubkey...] OP_CHECKMULTISIG +scriptPubKey: [pubkey] [pubkey...] OP_CHECKMULTISIG scriptSig: OP_0 [sig] [sig...] ~~~ @@ -353,16 +353,16 @@ Although it’s not a separate transaction type, this is a P2SH multisig with 2- {% endautocrossref %} ~~~ -script: OP_HASH160 OP_EQUAL +scriptPubKey: OP_HASH160 OP_EQUAL redeemScript: OP_CHECKMULTISIG -scriptSig: OP_0 +scriptSig: OP_0 ~~~ {% autocrossref %} **Pubkey** -[Pubkey][]{:#term-pubkey}{:.term} scripts are a simplified form of the P2PKH script, +[Pubkey][]{:#term-pubkey}{:.term} scripts are a simplified form of the P2PKH scriptPubKey, but they aren’t as secure as P2PKH, so they generally aren’t used in new transactions anymore. @@ -370,7 +370,7 @@ aren’t used in new transactions anymore. {% endautocrossref %} ~~~ -script: OP_CHECKSIG +scriptPubKey: OP_CHECKSIG scriptSig: ~~~ @@ -378,15 +378,15 @@ scriptSig: **Null Data** -[Null data][]{:#term-null-data}{:.term} scripts let you add a small amount of arbitrary data to the block +[Null data][]{:#term-null-data}{:.term} scriptPubKeys 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 script type only because some people were adding data +(Null data is a standard scriptPubKey type only because some people were adding data to the block chain in more harmful ways.) {% endautocrossref %} ~~~ -script: OP_RETURN +scriptScriptPubKey: OP_RETURN <0 to 40 bytes of data> (Null data scripts cannot be spent, so there's no scriptSig) ~~~ @@ -394,7 +394,7 @@ script: OP_RETURN {% autocrossref %} -If you use anything besides a standard script in an output, peers +If you use anything besides a standard scriptPubKey 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 @@ -404,11 +404,11 @@ If you create a redeemScript, 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. This allows -payment to non-standard output scripts almost as easily as payment to -standard output scripts. However, when you go to +payment to non-standard scriptPubKeys almost as easily as payment to +standard scriptPubKeys. 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 output -script. If it isn't, they won't process it further---so it will be +check the redeemScript to see whether or not it's a standard scriptPubKey. +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. @@ -663,7 +663,7 @@ malleability][]{:.term}{:#term-transaction-malleability}. The scriptSig contains the 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 output script is processed. +which will be dropped before the previous scriptPubKey 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 0573db5f..f348f353 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 script or address using one of + then distribute on request an output scriptPubKey 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 @@ -357,7 +357,7 @@ 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 script. +matches the hash in the previous output scriptPubKey. For this reason, Bitcoin Core uses several different identifier bytes to help programs identify how keys should be used: diff --git a/_includes/ref_transactions.md b/_includes/ref_transactions.md index 455a0b12..22b010cd 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 standard transactions are, +The op codes used in the scriptPubKeys 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 @@ -173,7 +173,8 @@ 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 script (var_uint) +48 size of scriptSig (var_uint) +scriptSig 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 @@ -190,8 +191,8 @@ ff ff ff ff sequence number output 0: 00 ca 9a 3b 00 00 00 00 amount = 10.00000000 BTC -43 size of script (var_uint) -script for output 0: +43 size of scriptPubKey (var_uint) +scriptPubKey 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 @@ -206,8 +207,8 @@ ac OP_CHECKSIG output 1: 00 28 6b ee 00 00 00 00 amount = 40.00000000 BTC -43 size of script (var_uint) -script for output 1: +43 size of scriptPubKey (var_uint) +scriptPubKey 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 ed395870..98d0fbc9 100644 --- a/_includes/references.md +++ b/_includes/references.md @@ -66,7 +66,7 @@ [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 script using OP_CHECKMULTISIG to check for multiple signatures" +[multisig]: /en/developer-guide#term-multisig "An output scriptPubKey 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)" @@ -79,11 +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 script" +[output]: /en/developer-guide#term-output "The output of a transaction which transfers value to a scriptPubKey" [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 scripts" -[P2PKH]: /en/developer-guide#term-p2pkh "A script which Pays To Pubkey Hashes (P2PKH), allowing spending of satoshis to anyone with a Bitcoin address" -[P2SH]: /en/developer-guide#term-p2sh "A script which Pays To Script Hashes (P2SH), allowing convenient spending of satoshis to an address referencing a script" +[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" [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" @@ -101,7 +101,7 @@ [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 script" +[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 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" @@ -109,7 +109,7 @@ [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" [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 script which specifies the full public key to match a signature; used in coinbase transactions" +[Pubkey]: /en/developer-guide#term-pubkey "A standard output scriptPubKey which specifies the full public key to match a signature; used in coinbase transactions" [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" @@ -122,8 +122,8 @@ [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" -[script]: /en/developer-guide#term-script "The part of an output which sets the conditions for spending of the satoshis in that output" -[scripts]: /en/developer-guide#term-script "The part of an output which sets the conditions for spending of the satoshis in that output" +[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" [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" @@ -138,7 +138,7 @@ [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 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" +[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" [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"