mirror of
https://github.com/seigler/dash-docs
synced 2025-07-27 09:46:12 +00:00
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.
This commit is contained in:
parent
d27cf78449
commit
9183f98bc1
6 changed files with 73 additions and 73 deletions
|
@ -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<!--noref--> data. Assuming the redeemScript
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
||||

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

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

|
||||
|
@ -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 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
|
||||
scriptPubKey: OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
|
||||
scriptSig: <sig> <pubkey>
|
||||
~~~
|
||||
|
||||
{% 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 <redeemscripthash> OP_EQUAL
|
||||
scriptSig: <sig> [sig] [sig...] <redeemscript>
|
||||
scriptPubKey: OP_HASH160 <Hash160(redeemScript)> OP_EQUAL
|
||||
scriptSig: <sig> [sig] [sig...] <redeemScript>
|
||||
~~~
|
||||
|
||||
{% autocrossref %}
|
||||
|
@ -328,7 +328,7 @@ scriptSig: <sig> [sig] [sig...] <redeemscript>
|
|||
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: <m> <pubkey> [pubkey] [pubkey...] <n> OP_CHECKMULTISIG
|
||||
scriptPubKey: <m> <pubkey> [pubkey] [pubkey...] <n> OP_CHECKMULTISIG
|
||||
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 %}
|
||||
|
||||
~~~
|
||||
script: OP_HASH160 <redeemscripthash> OP_EQUAL
|
||||
scriptPubKey: OP_HASH160 <Hash160(redeemScript)> OP_EQUAL
|
||||
redeemScript: <OP_2> <pubkey> <pubkey> <pubkey> <OP_3> OP_CHECKMULTISIG
|
||||
scriptSig: OP_0 <sig> <sig> <redeemscript>
|
||||
scriptSig: OP_0 <sig> <sig> <redeemScript>
|
||||
~~~
|
||||
|
||||
{% 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: <pubkey> OP_CHECKSIG
|
||||
scriptPubKey: <pubkey> OP_CHECKSIG
|
||||
scriptSig: <sig>
|
||||
~~~
|
||||
|
||||
|
@ -378,15 +378,15 @@ scriptSig: <sig>
|
|||
|
||||
**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 <data>
|
||||
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 <data>
|
|||
|
||||
{% 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
|
||||
|
|
|
@ -223,7 +223,7 @@ design these minimalist wallets:
|
|||

|
||||
|
||||
* 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:
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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"
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue