mirror of
https://github.com/seigler/dash-docs
synced 2025-07-28 10:16:15 +00:00
Merge remote-tracking branch 'remotes/luke-jr/master' into master
This commit is contained in:
Saivann
commit
89b86f6b66
12 changed files with 394 additions and 75 deletions
|
|
@ -49,7 +49,7 @@ chmod 0600 bitcoin.conf
|
|||
For development, it's safer and cheaper to use Bitcoin's test network (testnet)
|
||||
or regression test mode (regtest) described below.
|
||||
|
||||
Questions about Bitcoin development are best sent to the Bitcoin [Forum][forum
|
||||
Questions about Bitcoin use are best sent to the [BitcoinTalk forum][forum
|
||||
tech support] and [IRC channels][]. Errors or suggestions related to
|
||||
documentation on Bitcoin.org can be [submitted as an issue][docs issue]
|
||||
or posted to the [bitcoin-documentation mailing list][].
|
||||
|
|
|
|||
|
|
@ -2,8 +2,8 @@
|
|||
|
||||
{% autocrossref %}
|
||||
|
||||
The block chain provides Bitcoin's public ledger, a timestamped record
|
||||
of all confirmed transactions. This system is used to protect against double spending
|
||||
The block chain provides Bitcoin's public ledger, an ordered and timestamped record
|
||||
of transactions. This system is used to protect against double spending
|
||||
and modification of previous transaction records, using proof of
|
||||
work verified by the peer-to-peer network to maintain a global consensus.
|
||||
|
||||
|
|
@ -20,35 +20,33 @@ A [block][]{:#term-block}{:.term} of one or more new transactions
|
|||
is collected into the transaction data part of a block.
|
||||
Copies of each transaction are hashed, and the hashes are then paired,
|
||||
hashed, paired again, and hashed again until a single hash remains, the
|
||||
[Merkle root][]{:#term-merkle-root}{:.term} of a Merkle tree.
|
||||
[merkle root][]{:#term-merkle-root}{:.term} of a merkle tree.
|
||||
|
||||
The Merkle root is stored in the block header. Each block also
|
||||
The merkle root is stored in the block header. Each block also
|
||||
stores the hash of the previous block's header, chaining the blocks
|
||||
together. This ensures a transaction cannot be modified without
|
||||
modifying the block that records it and all following blocks.
|
||||
|
||||
Transactions are also chained together. Bitcoin wallet software gives
|
||||
the impression that satoshis are sent from and to addresses, but
|
||||
bitcoins really move from transaction to transaction. Each standard
|
||||
transaction spends the satoshis previously spent in one or more earlier
|
||||
the impression that satoshis are sent from and to wallets, but
|
||||
bitcoins really move from transaction to transaction. Each
|
||||
transaction spends the satoshis previously received in one or more earlier
|
||||
transactions, so the input of one transaction is the output of a
|
||||
previous transaction.
|
||||
|
||||
|
||||
|
||||
A single transaction can spend bitcoins to multiple outputs, as would be
|
||||
the case when sending satoshis to multiple addresses, but each output of
|
||||
A single transaction can create multiple outputs, as would be
|
||||
the case when sending to multiple addresses, but each output of
|
||||
a particular transaction can only be used as an input once in the
|
||||
block chain. Any subsequent reference is a forbidden double
|
||||
spend---an attempt to spend the same satoshis twice.
|
||||
|
||||
Outputs are not the same as Bitcoin addresses. You can use the same
|
||||
address in multiple transactions, but you can only use each output once.
|
||||
Outputs are tied to [transaction identifiers (TXIDs)][txid]{:#term-txid}{:.term}, which are the hashes
|
||||
of signed transactions.
|
||||
|
||||
Because each output of a particular transaction can only be spent once,
|
||||
all transactions included in the block chain can be categorized as either
|
||||
the outputs of all transactions included in the block chain can be categorized as either
|
||||
[Unspent Transaction Outputs (UTXOs)][utxo]{:#term-utxo}{:.term} or spent transaction outputs. For a
|
||||
payment to be valid, it must only use UTXOs as inputs.
|
||||
|
||||
|
|
@ -66,10 +64,10 @@ satoshi transaction fee.
|
|||
|
||||
{% autocrossref %}
|
||||
|
||||
The block chain is collaboratively maintained on a peer-to-peer network, so
|
||||
Bitcoin requires each block prove a significant amount of work was invested in
|
||||
The block chain is collaboratively maintained by anonymous peers on the network, so
|
||||
Bitcoin requires that each block prove a significant amount of work was invested in
|
||||
its creation to ensure that untrustworthy peers who want to modify past blocks have
|
||||
to work harder than trustworthy peers who only want to add new blocks to the
|
||||
to work harder than honest peers who only want to add new blocks to the
|
||||
block chain.
|
||||
|
||||
Chaining blocks together makes it impossible to modify transactions included
|
||||
|
|
@ -89,18 +87,17 @@ hash of the block header which does not exceed a certain value. For
|
|||
example, if the maximum possible hash value is <span
|
||||
class="math">2<sup>256</sup> − 1</span>, you can prove that you
|
||||
tried up to two combinations by producing a hash value less than <span
|
||||
class="math">2<sup>256</sup> − 1</span>.
|
||||
class="math">2<sup>255</sup></span>.
|
||||
|
||||
In the example given above, you will almost certainly produce a
|
||||
successful hash on your first try. You can even estimate the probability
|
||||
In the example given above, you will produce a successful hash on average every other try.
|
||||
You can even estimate the probability
|
||||
that a given hash attempt will generate a number below the [target][]{:#term-target}{:.term}
|
||||
threshold. Bitcoin itself does not track probabilities but instead
|
||||
simply assumes that the lower it makes the target threshold, the more
|
||||
hash attempts, on average, will need to be tried.
|
||||
threshold.
|
||||
Bitcoin assumes a linear probability that the lower it makes the target threshold, the more hash attempts (on average) will need to be tried.
|
||||
|
||||
New blocks will only be added to the block chain if their hash is at
|
||||
least as challenging as a [difficulty][]{:#term-difficulty}{:.term} value expected by the peer-to-peer
|
||||
network. Every 2,016 blocks, the network uses timestamps stored in each
|
||||
least as challenging as a [difficulty][]{:#term-difficulty}{:.term} value expected by the consensus protocol.
|
||||
Every 2,016 blocks, the network uses timestamps stored in each
|
||||
block header to calculate the number of seconds elapsed between generation
|
||||
of the first and last of those last 2,016 blocks. The ideal value is
|
||||
1,209,600 seconds (two weeks).
|
||||
|
|
@ -125,7 +122,7 @@ propagate a modified block as the entire Bitcoin network expended
|
|||
between the time the original block was created and the present time.
|
||||
Only if you acquired a majority of the network's hashing power
|
||||
could you reliably execute such a [51 percent attack][]{:#term-51-attack}{:.term} against
|
||||
transaction history.
|
||||
transaction history (although, it should be noted, that even less than 50% of the hashing power still has a good chance of performing such attacks).
|
||||
|
||||
The block header provides several easy-to-modify fields, such as a
|
||||
dedicated nonce field, so obtaining new hashes doesn't require waiting
|
||||
|
|
@ -140,11 +137,12 @@ a block does not slow down hashing with extra I/O.
|
|||
{% autocrossref %}
|
||||
|
||||
Any Bitcoin miner who successfully hashes a block header to a value
|
||||
below the target threshold can add the entire block to the block chain.
|
||||
(Assuming the block is otherwise valid.) These blocks are commonly addressed
|
||||
below the target threshold can add the entire block to the block chain
|
||||
(assuming the block is otherwise valid).
|
||||
These blocks are commonly addressed
|
||||
by their [block height][]{:#term-block-height}{:.term}---the number of blocks between them and the first Bitcoin
|
||||
block (block 0, most commonly known as the [genesis block]{:#term-genesis-block}{:.term}). For example,
|
||||
block 2016 is where difficulty could have been first adjusted.
|
||||
block 2016 is where difficulty could have first been adjusted.
|
||||
|
||||
|
||||
|
||||
|
|
@ -154,15 +152,18 @@ creates an apparent [fork][accidental fork]{:#term-accidental-fork}{:.term} in t
|
|||
illustration above.
|
||||
|
||||
When miners produce simultaneous blocks at the end of the block chain, each
|
||||
peer individually chooses which block to trust. (In the absence of
|
||||
other considerations, discussed below, peers usually trust the first
|
||||
block they see.)
|
||||
node individually chooses which block to accept. In the absence of
|
||||
other considerations, discussed below, nodes usually use the first
|
||||
block they see.
|
||||
|
||||
Eventually a miner produces another block which attaches to only one of
|
||||
the competing simultaneously-mined blocks. This makes that side of
|
||||
the fork longer than the other side. Assuming a fork only contains valid
|
||||
blocks, normal peers always follow the longest fork (the most difficult chain
|
||||
to recreate) and throw away ([orphan][]{:#term-orphan}{:.term}) blocks belonging to shorter forks.
|
||||
the fork stronger than the other side.
|
||||
Assuming a fork only contains valid
|
||||
blocks, normal peers always follow the the most difficult chain
|
||||
to recreate and throw away [stale blocks][stale block]{:#term-stale-block}{:.term} belonging to shorter forks.
|
||||
(Stale blocks are also sometimes called orphans or orphan blocks, but
|
||||
those terms are also used for blocks without a known parent block.)
|
||||
|
||||
[Long-term forks][long-term fork]{:#term-long-term-fork}{:.term} are possible if different miners work at cross-purposes,
|
||||
such as some miners diligently working to extend the block chain at the
|
||||
|
|
@ -171,7 +172,7 @@ transaction history.
|
|||
|
||||
Since multiple blocks can have the same height during a block chain fork, block
|
||||
height should not be used as a globally unique identifier. Instead, blocks
|
||||
are usually referenced by the SHA256(SHA256()) hash of their header.
|
||||
are usually referenced by the hash of their header (often with the byte order reversed, and in hexadecimal).
|
||||
|
||||
{% endautocrossref %}
|
||||
|
||||
|
|
@ -180,34 +181,33 @@ are usually referenced by the SHA256(SHA256()) hash of their header.
|
|||
{% autocrossref %}
|
||||
|
||||
Every block must include one or more transactions. The first one of these
|
||||
transactions must be a coinbase transaction which should collect and
|
||||
spend the block reward and any transaction fees paid by transactions included in this block.
|
||||
transactions must be a coinbase transaction, also called a generation transaction, which should collect and
|
||||
spend the block reward (comprised of a block subsidy and any transaction fees paid by transactions included in this block).
|
||||
|
||||
The UTXO of a coinbase transaction has the special condition that
|
||||
it cannot be spent (used as an input) for at least 100 blocks. This temporarily
|
||||
prevents a miner from spending the transaction fees and block reward from a
|
||||
block that may later be orphaned (destroyed) after a block chain fork.
|
||||
block that may later be determined to be stale (and therefore the coinbase transaction destroyed) after a block chain fork.
|
||||
|
||||
Blocks are not required to include any non-coinbase transactions, but
|
||||
miners almost always do include additional transactions in order to
|
||||
collect their transaction fees.
|
||||
|
||||
All transactions, including the coinbase transaction, are encoded into
|
||||
blocks in binary rawtransaction format prefixed by a block transaction
|
||||
sequence number.
|
||||
blocks in binary rawtransaction format.
|
||||
|
||||
The rawtransaction format is hashed to create the transaction
|
||||
identifier (txid). From these txids, the [Merkle tree][]{:#term-merkle-tree}{:.term} is constructed by pairing each
|
||||
identifier (txid). From these txids, the [merkle tree][]{:#term-merkle-tree}{:.term} is constructed by pairing each
|
||||
txid with one other txid and then hashing them together. If there are
|
||||
an odd number of txids, the txid without a partner is hashed with a
|
||||
copy of itself.
|
||||
|
||||
The resulting hashes themselves are each paired with one other hash and
|
||||
hashed together. Any hash without a partner is hashed with itself. The
|
||||
process repeats until only one hash remains, the Merkle root.
|
||||
process repeats until only one hash remains, the merkle root.
|
||||
|
||||
For example, if transactions were merely joined (not hashed), a
|
||||
five-transaction Merkle tree would look like the following text diagram:
|
||||
five-transaction merkle tree would look like the following text diagram:
|
||||
|
||||
{% endautocrossref %}
|
||||
|
||||
|
|
@ -224,19 +224,23 @@ A B C D E .........Transactions
|
|||
{% autocrossref %}
|
||||
|
||||
As discussed in the Simplified Payment Verification (SPV) subsection,
|
||||
the Merkle tree allows clients to verify for
|
||||
the merkle tree allows clients to verify for
|
||||
themselves that a transaction was included in a block by obtaining the
|
||||
Merkle root from a block header and a list of the intermediate hashes
|
||||
merkle root from a block header and a list of the intermediate hashes
|
||||
from a full peer. The full peer does not need to be trusted: it is
|
||||
expensive to fake block headers and the intermediate hashes cannot be faked or
|
||||
the verification will fail.
|
||||
|
||||
For example, to verify transaction D was added to the
|
||||
block, an SPV client only needs a copy of the C, AB, and EEEE hashes in addition to the
|
||||
Merkle root; the client doesn't need to know anything about any of the
|
||||
merkle root; the client doesn't need to know anything about any of the
|
||||
other transactions. If the five transactions in this block were all at
|
||||
the maximum size, downloading the entire block would require over
|
||||
500,000 bytes---but downloading three hashes plus the block header
|
||||
requires only 140 bytes.
|
||||
|
||||
Note: If identical txids are found within the same block, there is a possibility that the merkle tree may collide with a block with some or all duplicates removed due to how unbalanced merkle trees are implemented (duplicating the lone hash).
|
||||
Since it is impractical to have separate transactions with identical txids, this does not impose a burden on honest software, but must be checked if the invalid status of a block is to be cached;
|
||||
otherwise, a valid block with the duplicates eliminated could have the same merkle root and block hash, but be rejected by the cached invalid outcome, resulting in security bugs such as CVE-2012-2459.
|
||||
|
||||
{% endautocrossref %}
|
||||
|
|
|
|||
|
|
@ -5,8 +5,8 @@ Bitcoin and start building Bitcoin-based applications. To make the best use of
|
|||
this documentation, you may want to install the current version of Bitcoin
|
||||
Core, either from [source][core git] or from a [pre-compiled executable][core executable].
|
||||
|
||||
Questions about Bitcoin development are best sent to the Bitcoin [Forum][forum
|
||||
tech support] and [IRC channels][]. Errors or suggestions related to
|
||||
Questions about Bitcoin development are best asked in the Bitcoin [IRC channels][].
|
||||
Errors or suggestions related to
|
||||
documentation on Bitcoin.org can be [submitted as an issue][docs issue]
|
||||
or posted to the [bitcoin-documentation mailing list][].
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ The mining hardware iterates through every possible value for the block
|
|||
header nonce and generates the corresponding hash.
|
||||
|
||||
If none of the hashes are below the threshold, the mining hardware gets
|
||||
an updated block header with a new Merkle root from the mining software;
|
||||
an updated block header with a new merkle root from the mining software;
|
||||
this new block header is created by adding extra nonce data to the
|
||||
coinbase field of the coinbase transaction.
|
||||
|
||||
|
|
@ -71,7 +71,7 @@ miner checked a percentage of the possible hash values.
|
|||
|
||||
The miner then sends to the pool a copy of the information the pool
|
||||
needs to validate that the header will hash below the target and that
|
||||
the the block of transactions referred to by the header Merkle root field
|
||||
the the block of transactions referred to by the header merkle root field
|
||||
is valid for the pool's purposes. (This usually means that the coinbase
|
||||
transaction must pay the pool.)
|
||||
|
||||
|
|
@ -139,10 +139,10 @@ provides the mining software with much more information:
|
|||
|
||||
Using the transactions received, the mining software adds a nonce to the
|
||||
coinbase extra nonce field and then converts all the transactions into a
|
||||
Merkle tree to derive a Merkle root it can use in a block header.
|
||||
merkle tree to derive a merkle root it can use in a block header.
|
||||
Whenever the extra nonce field needs to be changed, the mining software
|
||||
rebuilds the necessary parts of the Merkle tree and updates the time and
|
||||
Merkle root fields in the block header.
|
||||
rebuilds the necessary parts of the merkle tree and updates the time and
|
||||
merkle root fields in the block header.
|
||||
|
||||
Like all `bitcoind` RPCs, `getblocktemplate` is sent over HTTP. To
|
||||
ensure they get the most recent work, most miners use [HTTP longpoll][] to
|
||||
|
|
@ -164,26 +164,26 @@ need to construct block headers on their own:
|
|||
1. The information necessary to construct a coinbase transaction
|
||||
paying the pool.
|
||||
|
||||
2. The parts of the Merkle tree which need to be re-hashed to
|
||||
create a new Merkle root when the coinbase transaction is
|
||||
updated with a new extra nonce. The other parts of the Merkle
|
||||
2. The parts of the merkle tree which need to be re-hashed to
|
||||
create a new merkle root when the coinbase transaction is
|
||||
updated with a new extra nonce. The other parts of the merkle
|
||||
tree, if any, are not sent, effectively limiting the amount of data which needs
|
||||
to be sent to (at most) about a kilobyte at current transaction
|
||||
volume.
|
||||
|
||||
3. All of the other non-Merkle root information necessary to construct a
|
||||
3. All of the other non-merkle root information necessary to construct a
|
||||
block header for the next block.
|
||||
|
||||
4. The mining pool's current target threshold for accepting shares.
|
||||
|
||||
Using the coinbase transaction received, the mining software adds a
|
||||
nonce to the coinbase extra nonce field, hashes the coinbase
|
||||
transaction, and adds the hash to the received parts of the Merkle tree.
|
||||
The tree is hashed as necessary to create a Merkle root, which is added
|
||||
transaction, and adds the hash to the received parts of the merkle tree.
|
||||
The tree is hashed as necessary to create a merkle root, which is added
|
||||
to the block header information received. Whenever the extra nonce field
|
||||
needs to be changed, the mining software updates and re-hashes the
|
||||
coinbase transaction, rebuilds the Merkle root, and updates the header
|
||||
Merkle root field.
|
||||
coinbase transaction, rebuilds the merkle root, and updates the header
|
||||
merkle root field.
|
||||
|
||||
Unlike `getblocktemplate`, miners using Stratum cannot inspect or add
|
||||
transactions to the block they're currently mining. Also unlike
|
||||
|
|
|
|||
|
|
@ -24,9 +24,9 @@ For a client to be fooled, an adversary would need to give a complete alternativ
|
|||
|
||||
An alternative approach detailed in the [original Bitcoin paper][bitcoinpdf] is a client that only downloads the headers of blocks during the initial syncing process and then requests transactions from full nodes as needed. This scales linearly with the height of the block chain at only 80 bytes per block header, or up to 4.2MB per year, regardless of total block size.
|
||||
|
||||
As described in the white paper, the Merkle root in the block header along with a Merkle branch can prove to the SPV client that the transaction in question is embedded in a block in the block chain. This does not guarantee validity of the transactions that are embedded. Instead it demonstrates the amount of work required to perform a double-spend attack.
|
||||
As described in the white paper, the merkle root in the block header along with a merkle branch can prove to the SPV client that the transaction in question is embedded in a block in the block chain. This does not guarantee validity of the transactions that are embedded. Instead it demonstrates the amount of work required to perform a double-spend attack.
|
||||
|
||||
The block's depth in the block chain corresponds to the cumulative difficulty that has been performed to build on top of that particular block. The SPV client knows the Merkle root and associated transaction information, and requests the respective Merkle branch from a full node. Once the Merkle branch has been retrieved, proving the existence of the transaction in the block, the SPV client can then look to block *depth* as a proxy for transaction validity and security. The cost of an attack on a user by a malicious node who inserts an invalid transaction grows with the cumulative difficulty built on top of that block, since the malicious node alone will be mining this forged chain.
|
||||
The block's depth in the block chain corresponds to the cumulative difficulty that has been performed to build on top of that particular block. The SPV client knows the merkle root and associated transaction information, and requests the respective merkle branch from a full node. Once the merkle branch has been retrieved, proving the existence of the transaction in the block, the SPV client can then look to block *depth* as a proxy for transaction validity and security. The cost of an attack on a user by a malicious node who inserts an invalid transaction grows with the cumulative difficulty built on top of that block, since the malicious node alone will be mining this forged chain.
|
||||
|
||||
{% endautocrossref %}
|
||||
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ The 80-byte block header contains the following six fields:
|
|||
block chain and ensures no previous block can be changed without also
|
||||
changing this block's header.
|
||||
|
||||
3. The *Merkle root* is a hash derived from hashes of all the
|
||||
3. The *merkle root* is a hash derived from hashes of all the
|
||||
transactions included in this block. It ensures no transactions can
|
||||
be modified in this block without changing the block header hash.
|
||||
|
||||
|
|
@ -89,7 +89,7 @@ The 80-byte block header contains the following six fields:
|
|||
hash values for the header until they find a hash value less than or
|
||||
equal to the target threshold. If all values within the nonce's four
|
||||
bytes are tested, the time can be updated or the
|
||||
coinbase transaction can be changed and the Merkle
|
||||
coinbase transaction can be changed and the merkle
|
||||
root updated.
|
||||
|
||||
{% endautocrossref %}
|
||||
|
|
|
|||
|
|
@ -1232,7 +1232,7 @@ A hex-encoded block or the following JSON object described in segments.
|
|||
|
||||
The block header *hash* (same as you provided); the number of
|
||||
*confirmations* (subsequent blocks), the *size* of the block in bytes,
|
||||
the block *height*, the block *version*, and the *Merkle root* hash.
|
||||
the block *height*, the block *version*, and the *merkle root* hash.
|
||||
|
||||
{% endautocrossref %}
|
||||
|
||||
|
|
@ -3231,7 +3231,7 @@ block, and lets a miner return a successful header.
|
|||
|
||||
*String; optional:* if header data is provided, it will be checked to
|
||||
see if it meets the target threshold (difficulty) and then affixed to a
|
||||
block of transactions (which produces a matching Merkle root). Then the
|
||||
block of transactions (which produces a matching merkle root). Then the
|
||||
complete block will be broadcast to the network. Data is in the same
|
||||
format as provided by the *data* output parameter (see below).
|
||||
|
||||
|
|
|
|||
|
|
@ -5,8 +5,8 @@ to help you start building Bitcoin-based applications. To make the best use of
|
|||
this documentation, you may want to install the current version of Bitcoin
|
||||
Core, either from [source][core git] or from a [pre-compiled executable][core executable].
|
||||
|
||||
Questions about Bitcoin development are best sent to the Bitcoin [Forum][forum
|
||||
tech support] and [IRC channels][]. Errors or suggestions related to
|
||||
Questions about Bitcoin development are best asked in the Bitcoin [IRC channels][].
|
||||
Errors or suggestions related to
|
||||
documentation on Bitcoin.org can be [submitted as an issue][docs issue]
|
||||
or posted to the [bitcoin-documentation mailing list][].
|
||||
|
||||
|
|
|
|||
|
|
@ -58,8 +58,8 @@
|
|||
[merge]: /en/developer-guide#term-merge "Spending, in the same transaction, multiple outputs which can be traced back to different previous spenders, leaking information about how many satoshis you control"
|
||||
[merge avoidance]: /en/developer-guide#term-merge-avoidance "A strategy for selecting which outputs to spend that avoids merging outputs with different histories that could leak private information"
|
||||
[message]: /en/developer-guide#term-message "A parameter of bitcoin: URIs which allows the receiver to optionally specify a message to the spender"
|
||||
[Merkle root]: /en/developer-guide#term-merkle-root "The root node of a Merkle tree descended from all the hashed pairs in the tree"
|
||||
[Merkle tree]: /en/developer-guide#term-merkle-tree "A tree constructed by hashing paired data, then pairing and hashing the results until a single hash remains, the Merkle root"
|
||||
[merkle root]: /en/developer-guide#term-merkle-root "The root node of a merkle tree descended from all the hashed pairs in the tree"
|
||||
[merkle tree]: /en/developer-guide#term-merkle-tree "A tree constructed by hashing paired data, then pairing and hashing the results until a single hash remains, the merkle root"
|
||||
[micropayment channel]: /en/developer-guide#term-micropayment-channel
|
||||
[millibits]: /en/developer-guide#term-millibits "0.001 bitcoins (100,000 satoshis)"
|
||||
[mine]: /en/developer-guide#term-miner "Creating Bitcoin blocks which solve proof-of-work puzzles in exchange for block rewards and transaction fees"
|
||||
|
|
@ -78,7 +78,6 @@
|
|||
[op_hash160]: /en/developer-reference#term-op-hash160 "Operation which converts the entry below it on the stack into a RIPEMD(SHA256()) hashed version of itself"
|
||||
[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 pubkey script"
|
||||
[output index]: /en/developer-guide#term-output-index "The sequentially-numbered index of outputs in a single transaction starting from 0"
|
||||
[P2PKH]: /en/developer-guide#term-p2pkh "A pubkey script which Pays To PubKey Hashes (P2PKH), allowing spending of satoshis to anyone with a Bitcoin address"
|
||||
|
|
@ -136,6 +135,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"
|
||||
[stale block]: /en/developer-guide#term-stale-block "Blocks which were successfully mined but which aren't included on the current valid block chain"
|
||||
[standard script]: /en/developer-guide#standard-transactions "A pubkey script which matches the IsStandard() patterns specified in Bitcoin Core---or a transaction containing only standard outputs. Only standard transactions are mined or broadcast by peers running the default Bitcoin Core software"
|
||||
[target]: /en/developer-guide#term-target "The threshold below which a block header hash must be in order for the block to be added to the block chain"
|
||||
[testnet]: /en/developer-examples#testnet "A Bitcoin-like network where the satoshis have no real-world value to allow risk-free testing"
|
||||
|
|
@ -176,6 +176,7 @@
|
|||
[core git]: https://github.com/bitcoin/bitcoin
|
||||
[core paymentrequest.proto]: https://github.com/bitcoin/bitcoin/blob/master/src/qt/paymentrequest.proto
|
||||
[core script.h]: https://github.com/bitcoin/bitcoin/blob/master/src/script.h
|
||||
[CVE-2012-2459]: https://en.bitcoin.it/wiki/CVEs#CVE-2012-2459
|
||||
[DER]: https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One
|
||||
[devex complex raw transaction]: /en/developer-examples#complex-raw-transaction
|
||||
[devex payment protocol]: /en/developer-examples#payment-protocol
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue