joshua/dash-docs
1
0
Fork 0
mirror of https://github.com/seigler/dash-docs synced 2025-07-27 09:46:12 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Fix incorrect usage of 'script' rather than 'scriptPubKey'

Browse source 
This is causing quite a bit of confusion, for example by people looking
in the Bitcoin Core sourcecode and seeing the term 'scriptPubKey'
instead.
This commit is contained in:
Peter Todd 2014-09-18 21:10:31 -04:00 • committed by David Harding
parent d27cf78449
commit 9183f98bc1
6 changed files with 73 additions and 73 deletions
Download patch file Download diff file Expand all files Collapse all files

13
_includes/guide_contracts.md
View file

@ -58,19 +58,19 @@ OP_2 [A's pubkey] [B's pubkey] [C's pubkey] OP_3 OP_CHECKMULTISIG
stack. `OP_2` stack. `OP_2`
specifies that 2 signatures are required to sign; `OP_3` specifies that 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 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 *minimum* matching signatures required and *n* in the *number* of public
keys provided). keys provided).
Bob gives the redeemScript to Charlie, who checks to make sure his 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 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. sees the payment get added to the block chain and ships the merchandise.
Unfortunately, the merchandise gets slightly damaged in transit. Charlie Unfortunately, the merchandise gets slightly damaged in transit. Charlie
wants a full refund, but Bob thinks a 10% refund is sufficient. They 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 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. Charlie checked.
After looking at the evidence, Alice thinks a 40% refund is sufficient, 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 of the satoshis to Bob's public key and one that spends the remaining
40% to Charlie's public key. 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 and a copy of the unhashed serialized redeemScript
that Bob created. She gives a copy of the incomplete transaction to 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 both Bob and Charlie. Either one of them can complete it by adding
his signature to create the following input his signature to create the following scriptSig:
script:
{% endautocrossref %} {% 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.) implementation which must be preserved for compatibility.)
When the transaction is broadcast to the network, each peer checks the 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 ensuring that the redeemScript matches the redeemScript hash previously
provided. Then the redeemScript is evaluated, with the two signatures provided. Then the redeemScript is evaluated, with the two signatures
being used as input<!--noref--> data. Assuming the redeemScript being used as input<!--noref--> data. Assuming the redeemScript

2
_includes/guide_operating_modes.md
View file

@ -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. 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. 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.

94
_includes/guide_transactions.md
View file

@ -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 can create the first transaction. She creates a standard P2PKH
transaction output containing instructions which allow anyone to spend that transaction output containing instructions which allow anyone to spend that
output if they can prove they control the private key corresponding to 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. 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 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 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 [scriptSig][]{:#term-scriptsig}{:.term}---a
collection of data parameters which satisfy the conditions Alice placed 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) ![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 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 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: 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. 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. A [signature][]{:#term-signature}{:.term} made by using the ECDSA cryptographic formula to combine
certain transaction data (described below) with Bob's private key. 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. created the public key.
Bob's signature doesn't just prove Bob controls his private key; it also 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 As illustrated in the figure above, the data Bob signs includes the
txid and output index of the previous transaction, the previous 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 recipient spend this transaction's output, and the amount of satoshis to
spend to the next recipient. In essence, the entire transaction is spend to the next recipient. In essence, the entire transaction is
signed except for any scriptSigs, which hold the full public keys and signed except for any scriptSigs, which hold the full public keys and
@ -133,8 +133,8 @@ transactions.
{% autocrossref %} {% autocrossref %}
The validation procedure requires evaluation of the script. In a P2PKH The validation procedure requires evaluation of the scriptSig and scriptPubKey.
output, the script is: In a P2PKH output, the scriptPubKey is:
{% endautocrossref %} {% endautocrossref %}
@ -170,10 +170,10 @@ sections about stacks. These are programming terms. Also "above",
"below", "top", and "bottom" are commonly used relative directions or "below", "top", and "bottom" are commonly used relative directions or
locations in stack descriptions. -harding --> 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 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 and continuing to the end of Alice's scriptPubKey. The figure below shows the
evaluation of a standard P2PKH script; below the figure is a description evaluation of a standard P2PKH scriptPubKey; below the figure is a description
of the process. of the process.
![P2PKH Stack Evaluation](/img/dev/en-p2pkh-stack.svg) ![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. 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 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 itself with a copy of the data from one level below it---in this
case creating a copy of the public key Bob provided. 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. of the data from one level below it---in this case, Bob's public key.
This creates a hash of 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 first transaction. At this point, there should be two copies of Bob's
pubkey hash at the top of the stack. 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). stack. `OP_EQUALVERIFY` expands to `OP_EQUAL` and `OP_VERIFY` (not shown).
`OP_EQUAL` (not shown) checks the two values below it; in this `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 transaction validation fails. Otherwise it pops both itself and
the *true* value off the stack. 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 signature Bob provided against the now-authenticated public key he
also provided. If the signature matches the public key and was also provided. If the signature matches the public key and was
generated using all of the data required to be signed, `OP_CHECKSIG` generated using all of the data required to be signed, `OP_CHECKSIG`
replaces itself with *true.* 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 evaluated, the transaction is valid (provided there are no other
problems with it). problems with it).
@ -225,17 +225,17 @@ problems with it).
{% autocrossref %} {% 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 long-term security or usefulness of the particular satoshis they're
currently spending. Receivers do care about the conditions imposed on currently spending. Receivers do care about the conditions imposed on
the satoshis by the output script and, if they want, they can ask the satoshis by the scriptPubKey and, if they want, they can ask
spenders to use a particular script. Unfortunately, custom scripts are spenders to use a particular scriptPubKey. Unfortunately, custom scriptPubKeys are
less convenient than short Bitcoin addresses and more difficult to less convenient than short Bitcoin addresses and more difficult to
secure than P2PKH pubkey hashes. secure than P2PKH pubkey hashes.
To solve these problems, pay-to-script-hash To solve these problems, pay-to-script-hash
([P2SH][]{:#term-p2sh}{:.term}) transactions were created in 2012 to let ([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 script][script hash]{:#term-script-hash}{:.term}, the
[redeemScript][]{:#term-redeemscript}{:.term}. [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 the full (serialized) redeemScript in the input scriptSig. The
peer-to-peer network ensures the full redeemScript hashes to the same 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 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. Bob spend the output if the redeemScript returns true.
![Unlocking A P2SH Output For Spending](/img/dev/en-unlocking-p2sh-output.svg) ![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 After the discovery of several dangerous bugs in early versions of
Bitcoin, a test was added which only accepted transactions from the 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 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 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. standard transactions.
Non-standard transactions---those that fail the test---may be accepted Non-standard transactions---those that fail the test---may be accepted
by nodes not using the default Bitcoin Core settings. If they are 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. processed.
Besides making it more difficult for someone to attack Bitcoin for 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. 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)** **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. or multiple Bitcoin addresses.
{% endautocrossref %} {% endautocrossref %}
~~~ ~~~
script: OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG scriptPubKey: OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubkey> scriptSig: <sig> <pubkey>
~~~ ~~~
{% autocrossref %} {% autocrossref %}
**Script Hash (P2SH)** **Pay 2 Script Hash (P2SH)**
P2SH is used to send a transaction to a script hash. Each of the standard 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 scriptPubKeys can be used as a P2SH redeemScript, but in practice only the
multisig script makes sense until more transaction types are made standard. multisig scriptPubKey makes sense until more transaction types are made standard.
{% endautocrossref %} {% endautocrossref %}
~~~ ~~~
script: OP_HASH160 <redeemscripthash> OP_EQUAL scriptPubKey: OP_HASH160 <Hash160(redeemScript)> OP_EQUAL
scriptSig: <sig> [sig] [sig...] <redeemscript> scriptSig: <sig> [sig] [sig...] <redeemScript>
~~~ ~~~
{% autocrossref %} {% autocrossref %}
@ -328,7 +328,7 @@ scriptSig: <sig> [sig] [sig...] <redeemscript>
Although P2SH multisig is now generally used for multisig transactions, this base script 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. 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 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`, provided. Both *m* and *n* should be op codes `OP_1` through `OP_16`,
corresponding to the number desired. corresponding to the number desired.
@ -342,7 +342,7 @@ list of signatures in the scriptSig must be prefaced with an extra value
{% endautocrossref %} {% endautocrossref %}
~~~ ~~~
script: <m> <pubkey> [pubkey] [pubkey...] <n> OP_CHECKMULTISIG scriptPubKey: <m> <pubkey> [pubkey] [pubkey...] <n> OP_CHECKMULTISIG
scriptSig: OP_0 <sig> [sig] [sig...] scriptSig: OP_0 <sig> [sig] [sig...]
~~~ ~~~
@ -353,16 +353,16 @@ Although it’s not a separate transaction type, this is a P2SH multisig with 2-
{% endautocrossref %} {% endautocrossref %}
~~~ ~~~
script: OP_HASH160 <redeemscripthash> OP_EQUAL scriptPubKey: OP_HASH160 <Hash160(redeemScript)> OP_EQUAL
redeemScript: <OP_2> <pubkey> <pubkey> <pubkey> <OP_3> OP_CHECKMULTISIG redeemScript: <OP_2> <pubkey> <pubkey> <pubkey> <OP_3> OP_CHECKMULTISIG
scriptSig: OP_0 <sig> <sig> <redeemscript> scriptSig: OP_0 <sig> <sig> <redeemScript>
~~~ ~~~
{% autocrossref %} {% autocrossref %}
**Pubkey** **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 but they aren’t as
secure as P2PKH, so they generally secure as P2PKH, so they generally
aren’t used in new transactions anymore. aren’t used in new transactions anymore.
@ -370,7 +370,7 @@ aren’t used in new transactions anymore.
{% endautocrossref %} {% endautocrossref %}
~~~ ~~~
script: <pubkey> OP_CHECKSIG scriptPubKey: <pubkey> OP_CHECKSIG
scriptSig: <sig> scriptSig: <sig>
~~~ ~~~
@ -378,15 +378,15 @@ scriptSig: <sig>
**Null Data** **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. 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.) to the block chain in more harmful ways.)
{% endautocrossref %} {% endautocrossref %}
~~~ ~~~
script: OP_RETURN <data> scriptScriptPubKey: OP_RETURN <0 to 40 bytes of data>
(Null data scripts cannot be spent, so there's no scriptSig) (Null data scripts cannot be spent, so there's no scriptSig)
~~~ ~~~
@ -394,7 +394,7 @@ script: OP_RETURN <data>
{% autocrossref %} {% 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 and miners using the default Bitcoin Core settings will neither
accept, broadcast, nor mine your transaction. When you try to broadcast accept, broadcast, nor mine your transaction. When you try to broadcast
your transaction to a peer running the default settings, you will 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 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 redeemScript says.
This allows This allows
payment to non-standard output scripts almost as easily as payment to payment to non-standard scriptPubKeys almost as easily as payment to
standard output scripts. However, when you go to standard scriptPubKeys. However, when you go to
spend that output, peers and miners using the default settings will spend that output, peers and miners using the default settings will
check the redeemScript to see whether or not it's a standard output check the redeemScript to see whether or not it's a standard scriptPubKey.
script. If it isn't, they won't process it further---so it will be 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 impossible to spend that output until you find a miner who disables the
default settings. default settings.
@ -663,7 +663,7 @@ malleability][]{:.term}{:#term-transaction-malleability}. The scriptSig
contains the signature, which can't sign itself, allowing attackers to contains the signature, which can't sign itself, allowing attackers to
make non-functional modifications to a transaction without rendering it make non-functional modifications to a transaction without rendering it
invalid. For example, an attacker can add some data to the scriptSig 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 Although the modifications are non-functional---so they do not change
what inputs the transaction uses nor what outputs it pays---they do what inputs the transaction uses nor what outputs it pays---they do

4
_includes/guide_wallets.md
View file

@ -223,7 +223,7 @@ design these minimalist wallets:
![Distributing-Only Wallets](/img/dev/en-wallets-distributing-only.svg) ![Distributing-Only Wallets](/img/dev/en-wallets-distributing-only.svg)
* Pre-populate a database with a number of public keys or addresses, and * 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 the database entries. To [avoid key reuse][devguide avoiding key
reuse], webservers should keep track reuse], webservers should keep track
of used keys and never run out of public keys. This can be made easier 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 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 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 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 For this reason, Bitcoin Core uses several different identifier bytes to
help programs identify how keys should be used: help programs identify how keys should be used:

13
_includes/ref_transactions.md
View file

@ -6,7 +6,7 @@ The following subsections briefly document core transaction details.
{% autocrossref %} {% 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 * 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 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 ed ce 25 85 7f cd 37 04
00 00 00 00 previous output index 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 47 push 71 bytes to stack
30 44 02 20 4e 45 e1 69 30 44 02 20 4e 45 e1 69
32 b8 af 51 49 61 a1 d3 32 b8 af 51 49 61 a1 d3
@ -190,8 +191,8 @@ ff ff ff ff sequence number
output 0: output 0:
00 ca 9a 3b 00 00 00 00 amount = 10.00000000 BTC 00 ca 9a 3b 00 00 00 00 amount = 10.00000000 BTC
43 size of script (var_uint) 43 size of scriptPubKey (var_uint)
script for output 0: scriptPubKey for output 0:
41 push 65 bytes to stack 41 push 65 bytes to stack
04 ae 1a 62 fe 09 c5 f5 04 ae 1a 62 fe 09 c5 f5
1b 13 90 5f 07 f0 6b 99 1b 13 90 5f 07 f0 6b 99
@ -206,8 +207,8 @@ ac OP_CHECKSIG
output 1: output 1:
00 28 6b ee 00 00 00 00 amount = 40.00000000 BTC 00 28 6b ee 00 00 00 00 amount = 40.00000000 BTC
43 size of script (var_uint) 43 size of scriptPubKey (var_uint)
script for output 1: scriptPubKey for output 1:
41 push 65 bytes to stack 41 push 65 bytes to stack
04 11 db 93 e1 dc db 8a 04 11 db 93 e1 dc db 8a
01 6b 49 84 0f 8c 53 bc 01 6b 49 84 0f 8c 53 bc

20
_includes/references.md
View file

@ -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" [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" [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" [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" [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" [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_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_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)" [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" [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" [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" [outputs]: /en/developer-guide#term-output "The outputs of a transaction which transfer value to scriptPubKeys"
[P2PKH]: /en/developer-guide#term-p2pkh "A script which Pays To Pubkey Hashes (P2PKH), allowing spending of satoshis to anyone with a Bitcoin address" [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 script which Pays To Script Hashes (P2SH), allowing convenient spending of satoshis to an address referencing a script" [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" [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 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 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" [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" [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" [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 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 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 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 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 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" [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" [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" [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" [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" [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" [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" [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" [scriptPubKey]: /en/developer-guide#term-scriptPubKey "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" [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" [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 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" [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" [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" [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" [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" [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" [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" [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"