joshua/dash-docs
1
0
Fork 0
mirror of https://github.com/seigler/dash-docs synced 2025-07-28 02:06:13 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge pull #793: Dev Docs: New Glossary & JS Search Box

Browse source
This commit is contained in:
David A. Harding 2015-04-10 19:05:27 -04:00
commit e3dcf0ce1f
No known key found for this signature in database
GPG key ID: 4B29C30FF29EC4B7
126 changed files with 3827 additions and 470 deletions
Download patch file Download diff file Expand all files Collapse all files

2
_includes/example_testing.md
View file

@ -20,7 +20,7 @@ test their applications with reduced risks and limitations.
{% autocrossref %}
When run with no arguments, all Bitcoin Core programs default to Bitcoin's main
network ([mainnet][mainnet]{:#term-mainnet}{:.term}). However, for development,
network ([mainnet][/en/glossary/mainnet]{:#term-mainnet}{:.term}). However, for development,
it's safer and cheaper to use Bitcoin's test network (testnet)
where the satoshis spent have no real-world value. Testnet also relaxes some
restrictions (such as standard transaction checks) so you can test functions

4
_includes/example_transactions.md
View file

@ -22,7 +22,7 @@ of data to create transactions with the same attributes as those
described below.
In order to use this tutorial, you will need to setup [Bitcoin Core][core executable]
and create a [regression test mode][] environment with 50 BTC in your test
and create a regression test mode environment with 50 BTC in your test
wallet.
{% endautocrossref %}
@ -915,7 +915,7 @@ way to reference the underlying full (unhashed) public keys it knows
about, so we get the three new addresses above in order to use their
public keys.
[Recall from the Guide][address] that the hashed public keys used in addresses
Recall from the Guide that the hashed public keys used in addresses
obfuscate the full public key, so you cannot give an address to another
person or device as part of creating a typical multisig output or P2SH multisig
redeem script. You must give them a full public key.

40
_includes/guide_block_chain.md
View file

@ -16,9 +16,9 @@ and modification of previous transaction records.
Each full node in the Bitcoin network independently stores a block chain
containing only blocks validated by that node. When several nodes all
have the same blocks in their block chain, they are considered to be in
[consensus][]{:#term-consensus}{:.term}. The validation rules these
[consensus][/en/glossary/consensus]{:#term-consensus}{:.term}. The validation rules these
nodes follow to maintain consensus are called [consensus
rules][]{:#term-consensus-rules}{:.term}. This section describes many of
rules][/en/glossary/consensus-rules]{:#term-consensus-rules}{:.term}. This section describes many of
the consensus rules used by Bitcoin Core.
{% endautocrossref %}
@ -31,11 +31,11 @@ the consensus rules used by Bitcoin Core.
![Block Chain Overview](/img/dev/en-blockchain-overview.svg)
The illustration above shows a simplified version of a block chain.
A [block][]{:#term-block}{:.term} of one or more new transactions
A [block][/en/glossary/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][/en/glossary/merkle-root]{:#term-merkle-root}{:.term} of a merkle tree.
The merkle root is stored in the block header. Each block also
stores the hash of the previous block's header, chaining the blocks
@ -57,20 +57,20 @@ 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 tied to [transaction identifiers (TXIDs)][txid]{:#term-txid}{:.term}, which are the hashes
Outputs are tied to [transaction identifiers (TXIDs)][/en/glossary/txid]{:#term-txid}{:.term}, which are the hashes
of signed transactions.
Because each output of a particular transaction can only be spent once,
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
[Unspent Transaction Outputs (UTXOs)][/en/glossary/unspent-transaction-output]{:#term-utxo}{:.term} or spent transaction outputs. For a
payment to be valid, it must only use UTXOs as inputs.
Ignoring coinbase transactions (described later), if the value of a
transaction's outputs exceed its inputs, the transaction will be
rejected---but if the inputs exceed the value of the outputs, any
difference in value may be claimed as a [transaction
fee][]{:#term-transaction-fee}{:.term} by the Bitcoin
[miner][]{:#term-miner}{:.term} who creates the block containing that
fee][/en/glossary/transaction-fee]{:#term-transaction-fee}{:.term} by the Bitcoin
[miner][/en/glossary/mining]{:#term-miner}{:.term} who creates the block containing that
transaction.
For example, in the illustration above, each transaction spends 10,000 satoshis
fewer than it receives from its combined inputs, effectively paying a 10,000
@ -94,7 +94,7 @@ in any block without modifying all following blocks. As a
result, the cost to modify a particular block increases with every new block
added to the block chain, magnifying the effect of the proof of work.
The [proof of work][]{:#term-proof-of-work}{:.term} used in Bitcoin
The [proof of work][/en/glossary/proof-of-work]{:#term-proof-of-work}{:.term} used in Bitcoin
takes advantage of the apparently random nature of cryptographic hashes.
A good cryptographic hash algorithm converts arbitrary data into a
seemingly-random number. If the data is modified in any way and
@ -110,12 +110,12 @@ class="math">2<sup>255</sup></span>.
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}
that a given hash attempt will generate a number below the [target][/en/glossary/nbits]{:#term-target}{:.term}
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 consensus protocol.
least as challenging as a [difficulty][/en/glossary/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
@ -140,7 +140,7 @@ preceded it, it requires (on average) as much hashing power to
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
could you reliably execute such a [51 percent attack][/en/glossary/51-percent-attack]{:#term-51-attack}{:.term} against
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
@ -162,15 +162,15 @@ 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
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,
by their [block height][/en/glossary/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][/en/glossary/genesis-block]{:#term-genesis-block}{:.term}). For example,
block 2016 is where difficulty could have first been adjusted.
![Common And Uncommon Block Chain Forks](/img/dev/en-blockchain-fork.svg)
Multiple blocks can all have the same block height, as is common when
two or more miners each produce a block at roughly the same time. This
creates an apparent [fork][]{:#term-fork}{:.term} in the block chain, as shown in the
creates an apparent [fork][/en/glossary/fork]{:#term-fork}{:.term} in the block chain, as shown in the
illustration above.
When miners produce simultaneous blocks at the end of the block chain, each
@ -183,11 +183,11 @@ the competing simultaneously-mined blocks. This makes that side of
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.
to recreate and throw away [stale blocks][/en/glossary/stale-block]{:#term-stale-block}{:.term} belonging to shorter forks.
(Stale blocks are also sometimes called orphans or orphan blocks<!--noref-->, but
those terms are also used for true orphan 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,
Long-term forks are possible if different miners work at cross-purposes,
such as some miners diligently working to extend the block chain at the
same time other miners are attempting a 51 percent attack to revise
transaction history.
@ -220,7 +220,7 @@ All transactions, including the coinbase transaction, are encoded into
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][/en/glossary/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.
@ -297,7 +297,7 @@ which gets block chain data from those non-upgraded nodes refuses to
build on the same chain as mining software getting data from upgraded
nodes. This creates permanently divergent chains---one for non-upgraded
nodes and one for upgraded nodes---called a [hard
fork][]{:#term-hard-fork}{:.term}.
fork][/en/glossary/hard-fork]{:#term-hard-fork}{:.term}.
![Hard Fork](/img/dev/en-hard-fork.svg)
@ -307,7 +307,7 @@ majority of the hash rate. That's because, in this case, non-upgraded
nodes will accept as valid all the same blocks as upgraded nodes, so the
upgraded nodes can build a stronger chain that the non-upgraded nodes
will accept as the best valid block chain. This is called a [soft
fork][]{:#term-soft-fork}{:.term}.
fork][/en/glossary/soft-fork]{:#term-soft-fork}{:.term}.
![Soft Fork](/img/dev/en-soft-fork.svg)

6
_includes/guide_contracts.md
View file

@ -42,15 +42,15 @@ merchandise, but Charlie can't get the merchandise and keep his payment.
This simple contract isn't much help if there's a dispute, so Bob and
Charlie enlist the help of Alice-the-arbitrator to create an [escrow
contract][]{:#term-escrow-contract}{:.term}. Charlie spends his satoshis
contract][/en/glossary/escrow-contract]{:#term-escrow-contract}{:.term}. Charlie spends his satoshis
to an output which can only be spent if two of the three people sign the
input. Now Charlie can pay Bob if everything is ok, Bob can refund
Charlie's money if there's a problem, or Alice can arbitrate and decide
who should get the satoshis if there's a dispute.
To create a multiple-signature ([multisig][]{:#term-multisig}{:.term})
To create a multiple-signature ([multisig][/en/glossary/multisig]{:#term-multisig}{:.term})
output, they each give the others a public key. Then Bob creates the
following [P2SH multisig][]{:#term-p2sh-multisig}{:.term} redeem script:
following [P2SH multisig][/en/glossary/p2sh-multisig]{:#term-p2sh-multisig}{:.term} redeem script:
{% endautocrossref %}

8
_includes/guide_p2p_network.md
View file

@ -37,8 +37,8 @@ IP addresses.
When started for the first time, programs don't know the IP
addresses of any active full nodes. In order to discover some IP
addresses, they query one or more DNS names (called [DNS seeds][dns
seed]{:#term-dns-seed}{:.term}) hardcoded into Bitcoin Core and
addresses, they query one or more DNS names (called [DNS seeds][/en/glossary/dns-seed]{:#term-dns-seed}{:.term})
hardcoded into Bitcoin Core and
BitcoinJ. The response to the lookup should include one or more [DNS
A records][] with the IP addresses of full nodes that may accept new
incoming connections. For example, using the [Unix `dig`
@ -317,7 +317,7 @@ to the reference page for that message.
Bitcoin Core 0.10.0 uses an initial block download (IBD) method called
*headers-first*. The goal is to download the headers for the best [header
chain][]{:#term-header-chain}{:.term}, partially validate them as best
chain][/en/glossary/header-chain]{:#term-header-chain}{:.term}, partially validate them as best
as possible, and then download the corresponding blocks in parallel. This
solves several problems with the older blocks-first IBD method.
@ -469,7 +469,7 @@ block retrieval method.)
| **Payload** | The inventory of the new block | The inventory of the new block | One or more header hashes on the HF node's best header chain (BHC) | Up to 2,000 headers connecting HF node's BHC to relay node's BHC
| **Message** | [`block`][block message] | [`merkleblock`][merkleblock message] | [`tx`][tx message] |
| **From→To** | Relay→BF/HF | Relay→SPV | Relay→SPV |
| **Payload** | The new block in [serialized format][serialized block] | The new block filtered into a merkle block | Serialized transactions from the new block that match the bloom filter |
| **Payload** | The new block in [serialized format][section serialized blocks] | The new block filtered into a merkle block | Serialized transactions from the new block that match the bloom filter |
{% endautocrossref %}

12
_includes/guide_payment_processing.md
View file

@ -257,7 +257,7 @@ displayed on high-resolution screens.
{% autocrossref %}
Bitcoin Core 0.9 supports the new [payment protocol][]{:#term-payment-protocol}{:.term}. The payment protocol
Bitcoin Core 0.9 supports the new [payment protocol][/en/glossary/payment-protocol]{:#term-payment-protocol}{:.term}. The payment protocol
adds many important features to payment requests:
- Supports X.509 certificates and SSL encryption to verify receivers' identity
@ -423,7 +423,7 @@ for more details.
{% autocrossref %}
As explained in the [Transactions][] and [Block Chain][] sections, broadcasting
As explained in the [Transactions][] and [Block Chain][section block chain] sections, broadcasting
a transaction to the network doesn't ensure that the receiver gets
paid. A malicious spender can create one transaction that pays the
receiver and a second one that pays the same input back to himself. Only
@ -431,20 +431,20 @@ one of these transactions will be added to the block chain, and nobody
can say for sure which one it will be.
Two or more transactions spending the same input are commonly referred
to as a [double spend][]{:#term-double-spend}{:.term}.
to as a [double spend][/en/glossary/double-spend]{:#term-double-spend}{:.term}.
Once the transaction is included in a block, double spends are
impossible without modifying block chain history to replace the
transaction, which is quite difficult. Using this system,
the Bitcoin protocol can give each of your transactions an updating confidence
score based on the number of blocks which would need to be modified to replace
a transaction. For each block, the transaction gains one [confirmation][]{:#term-confirmation}{:.term}. Since
a transaction. For each block, the transaction gains one [confirmation][/en/glossary/confirmation-score]{:#term-confirmation}{:.term}. Since
modifying blocks is quite difficult, higher confirmation scores indicate
greater protection.
**0 confirmations**: The transaction has been broadcast but is still not
included in any block. Zero confirmation transactions ([unconfirmed
transactions][]{:#term-unconfirmed-transactions}{:.term}) should generally not be
included in any block. Zero confirmation transactions (unconfirmed
transactions) should generally not be
trusted without risk analysis. Although miners usually confirm the first
transaction they receive, fraudsters may be able to manipulate the
network into including their version of a transaction.

65
_includes/guide_transactions.md
View file

@ -33,8 +33,8 @@ about coinbase transactions in the block chain section of this guide.
![The Parts Of A Transaction](/img/dev/en-tx-overview.svg)
The figure above shows the main parts of a Bitcoin transaction. Each
transaction has at least one input and one output. Each [input][]{:#term-input}{:.term} spends the
satoshis paid to a previous output. Each [output][]{:#term-output}{:.term} then waits as an Unspent
transaction has at least one input and one output. Each [input][/en/glossary/input]{:#term-input}{:.term} spends the
satoshis paid to a previous output. Each [output][/en/glossary/output]{:#term-output}{:.term} then waits as an Unspent
Transaction Output (UTXO) until a later input spends it. When your
Bitcoin wallet tells you that you have a 10,000 satoshi balance, it really
means that you have 10,000 satoshis waiting in one or more UTXOs.
@ -63,7 +63,7 @@ The figures below help illustrate how these features are used by
showing the workflow Alice uses to send Bob a transaction and which Bob
later uses to spend that transaction. Both Alice and Bob will use the
most common form of the standard Pay-To-Public-Key-Hash (P2PKH) transaction
type. [P2PKH][]{:#term-p2pkh}{:.term} lets Alice spend satoshis to a typical Bitcoin address,
type. [P2PKH][/en/glossary/p2pkh-address]{:#term-p2pkh}{:.term} lets Alice spend satoshis to a typical Bitcoin address,
and then lets Bob further spend those satoshis using a simple
cryptographic key pair.
@ -71,10 +71,9 @@ cryptographic key pair.
Bob must first generate a private/public [key pair][]{:#term-key-pair}{:.term} before Alice can create the
first transaction. Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA) with
the secp256k1 curve; secp256k1 [private keys][private
key]{:#term-private-key}{:.term} are 256 bits of random
the secp256k1 curve; secp256k1 [private keys][/en/glossary/private-key]{:#term-private-key}{:.term} are 256 bits of random
data. A copy of that data is deterministically transformed into an secp256k1 [public
key][]{:#term-public-key}{:.term}. Because the transformation can be reliably repeated later, the
key][/en/glossary/public-key]{:#term-public-key}{:.term}. Because the transformation can be reliably repeated later, the
public key does not need to be stored.
The public key (pubkey) is then cryptographically hashed. This pubkey hash can
@ -89,8 +88,8 @@ and "full public key" to provide quick differentiation between the
different states of a public key and to help the text better match the
space-constrained diagrams where "public-key hash" wouldn't fit. -harding -->
Bob provides the [pubkey hash][]{:#term-pubkey-hash}{:.term} to Alice. Pubkey hashes are almost always
sent encoded as Bitcoin [addresses][]{:#term-address}{:.term}, which are base58-encoded strings
Bob provides the pubkey hash to Alice. Pubkey hashes are almost always
sent encoded as Bitcoin [addresses][/en/glossary/address]{:#term-address}{:.term}, which are base58-encoded strings
containing an address version number, the hash, and an error-detection
checksum to catch typos. The address can be transmitted
through any medium, including one-way mediums which prevent the spender
@ -102,7 +101,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 [pubkey script][]{:#term-pubkey-script}{:.term}
Bob's hashed public key. These instructions are called the [pubkey script][/en/glossary/pubkey-script]{:#term-pubkey-script}{:.term}
or scriptPubKey.
Alice broadcasts the transaction and it is added to the block chain.
@ -113,7 +112,7 @@ When, some time later, Bob decides to spend the UTXO, he must create an
input which references the transaction Alice created by its hash, called
a Transaction Identifier (txid), and the specific output she used by its
index number ([output index][]{:#term-output-index}{:.term}). He must then create a [signature
script][]{:#term-signature-script}{:.term}---a
script][/en/glossary/signature-script]{:#term-signature-script}{:.term}---a
collection of data parameters which satisfy the conditions Alice placed
in the previous output's pubkey script. Signature scripts are also
called scriptSigs.
@ -130,7 +129,7 @@ pieces of data:
1. His full (unhashed) public key, so the pubkey script can check that it
hashes to the same value as the pubkey hash provided by Alice.
2. An secp256k1 [signature][]{:#term-signature}{:.term} made by using the ECDSA cryptographic formula to combine
2. An secp256k1 [signature][/en/glossary/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 pubkey script verify that Bob owns the private key which
created the public key.
@ -187,7 +186,7 @@ and full public key (pubkey), creating the following concatenation:
The script language is a
[Forth-like](https://en.wikipedia.org/wiki/Forth_%28programming_language%29)
[stack][]{:#term-stack}{:.term}-based language deliberately designed to be stateless and not
stack-based language deliberately designed to be stateless and not
Turing complete. Statelessness ensures that once a transaction is added
to the block chain, there is no condition which renders it permanently
unspendable. Turing-incompleteness (specifically, a lack of loops or
@ -263,10 +262,10 @@ between programs prior to widespread implementation of the BIP70 Payment
Protocol discussed later.
To solve these problems, pay-to-script-hash
([P2SH][]{:#term-p2sh}{:.term}) transactions were created in 2012 to let
a spender create a pubkey script containing a [hash of a second
script][script hash]{:#term-script-hash}{:.term}, the
[redeem script][]{:#term-redeem-script}{:.term}.
([P2SH][/en/glossary/p2sh-address]{:#term-p2sh}{:.term}) transactions were created in 2012 to let
a spender create a pubkey script containing a hash of a second
script, the
[redeem script][/en/glossary/redeem-script]{:#term-redeem-script}{:.term}.
The basic P2SH workflow, illustrated below, looks almost identical to
the P2PKH workflow. Bob creates a redeem script with whatever script he
@ -409,7 +408,7 @@ Signature script: OP_0 <A sig> <C sig> <redeemScript>
{% autocrossref %}
[Pubkey][]{:#term-pubkey}{:.term} scripts are a simplified form of the P2PKH pubkey script,
Pubkey outputs are a simplified form of the P2PKH pubkey script,
but they aren’t as
secure as P2PKH, so they generally
aren’t used in new transactions anymore.
@ -427,7 +426,7 @@ Signature script: <sig>
{% autocrossref %}
[Null data][]{:#term-null-data}{:.term} pubkey scripts let you add a small amount of arbitrary data to the block
[Null data][/en/glossary/null-data-transaction]{:#term-null-data}{:.term} pubkey scripts let you add a small amount of arbitrary data to the block
chain in exchange for paying a transaction fee, but doing so is discouraged.
(Null data is a standard pubkey script type only because some people were adding data
to the block chain in more harmful ways.)
@ -508,36 +507,36 @@ from modification, this lets signers selectively choose to let other
people modify their transactions.
The various options for what to sign are
called [signature hash][]{:#term-signature-hash}{:.term} types. There are three base SIGHASH types
called [signature hash][/en/glossary/signature-hash]{:#term-signature-hash}{:.term} types. There are three base SIGHASH types
currently available:
* [`SIGHASH_ALL`][sighash_all]{:#term-sighash-all}{:.term}, the default, signs all the inputs and outputs,
* [`SIGHASH_ALL`][/en/glossary/sighash-all]{:#term-sighash-all}{:.term}, the default, signs all the inputs and outputs,
protecting everything except the signature scripts against modification.
* [`SIGHASH_NONE`][sighash_none]{:#term-sighash-none}{:.term} signs all of the inputs but none of the outputs,
* [`SIGHASH_NONE`][/en/glossary/sighash-none]{:#term-sighash-none}{:.term} signs all of the inputs but none of the outputs,
allowing anyone to change where the satoshis are going unless other
signatures using other signature hash flags protect the outputs.
* [`SIGHASH_SINGLE`][sighash_single]{:#term-sighash-single}{:.term} signs only this input and only one corresponding
* [`SIGHASH_SINGLE`][/en/glossary/sighash-none]{:#term-sighash-single}{:.term} signs only this input and only one corresponding
output (the output with the same output index number as the input), ensuring
nobody can change your part of the transaction but allowing other
signers to change their part of the transaction. The corresponding
output must exist or the value "1" will be signed, breaking the security
scheme.
The base types can be modified with the [`SIGHASH_ANYONECANPAY`][shacp]{:#term-sighash-anyonecanpay}{:.term} (anyone can
The base types can be modified with the [`SIGHASH_ANYONECANPAY`][/en/glossary/sighash-anyonecanpay]{:#term-sighash-anyonecanpay}{:.term} (anyone can
pay) flag, creating three new combined types:
* [`SIGHASH_ALL|SIGHASH_ANYONECANPAY`][sha_shacp]{:#term-sighash-all-sighash-anyonecanpay}{:.term} signs all of the outputs but only
* `SIGHASH_ALL|SIGHASH_ANYONECANPAY` signs all of the outputs but only
this one input, and it also allows anyone to add or remove other
inputs, so anyone can contribute additional satoshis but they cannot
change how many satoshis are sent nor where they go.
* [`SIGHASH_NONE|SIGHASH_ANYONECANPAY`][shn_shacp]{:#term-sighash-none-sighash-anyonecanpay}{:.term} signs only this one input and
* `SIGHASH_NONE|SIGHASH_ANYONECANPAY` signs only this one input and
allows anyone to add or remove other inputs or outputs, so anyone who
gets a copy of this input can spend it however they'd like.
* [`SIGHASH_SINGLE|SIGHASH_ANYONECANPAY`][shs_shacp]{:#term-sighash-single-sighash-anyonecanpay}{:.term} signs only this input and only
* `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` signs only this input and only
one corresponding output, but it also allows anyone to add or remove
other inputs.
@ -564,7 +563,7 @@ hash types sign, including the procedure for inserting the subscript -->
{% autocrossref %}
One thing all signature hash types sign is the transaction's [locktime][]{:#term-locktime}{:.term}.
One thing all signature hash types sign is the transaction's [locktime][/en/glossary/locktime]{:#term-locktime}{:.term}.
(Called nLockTime in the Bitcoin Core source code.)
The locktime indicates the earliest time a transaction can be added to
the block chain.
@ -591,7 +590,7 @@ Previous versions of Bitcoin Core provided a feature which prevented
transaction signers from using the method described above to cancel a
time-locked transaction, but a necessary part of this feature was
disabled to prevent denial of service attacks. A legacy of this system are four-byte
[sequence numbers][sequence number]{:#term-sequence-number}{:.term} in every input. Sequence numbers were meant to allow
[sequence numbers][/en/glossary/sequence-number]{:#term-sequence-number}{:.term} in every input. Sequence numbers were meant to allow
multiple signers to agree to update a transaction; when they finished
updating the transaction, they could agree to set every input's
sequence number to the four-byte unsigned maximum (0xffffffff),
@ -625,20 +624,20 @@ enable locktime.
Transactions typically pay transaction fees based on the total byte size
of the signed transaction. The transaction fee is given to the
Bitcoin miner, as explained in the [block chain section][block chain], and so it is
Bitcoin miner, as explained in the [block chain section][section block chain], and so it is
ultimately up to each miner to choose the minimum transaction fee they
will accept.
<!-- TODO: check: 50 KB or 50 KiB? Not that transactors care... -->
By default, miners reserve 50 KB of each block for [high-priority
transactions][]{:#term-high-priority-transactions}{:.term} which spend satoshis that haven't been spent for a long
transactions][/en/glossary/high-priority-transaction]{:#term-high-priority-transactions}{:.term} which spend satoshis that haven't been spent for a long
time. The remaining space in each block is typically allocated to transactions
based on their fee per byte, with higher-paying transactions being added
in sequence until all of the available space is filled.
As of Bitcoin Core 0.9, transactions which do not count as high-priority transactions
need to pay a [minimum fee][]{:#term-minimum-fee}{:.term} (currently 1,000 satoshis) to be
need to pay a [minimum fee][/en/glossary/minimum-relay-fee]{:#term-minimum-fee}{:.term} (currently 1,000 satoshis) to be
broadcast across the network. Any transaction paying only the minimum fee
should be prepared to wait a long time before there's enough spare space
in a block to include it. Please see the [verifying payment section][section verifying payment]
@ -650,7 +649,7 @@ UTXOs must be spent or given to a miner as a transaction fee. Few
people will have UTXOs that exactly match the amount they want to pay,
so most transactions include a change output.
[Change outputs][change output]{:#term-change-output}{:.term} are regular outputs which spend the surplus satoshis
[Change outputs][/en/glossary/change-address]{:#term-change-output}{:.term} are regular outputs which spend the surplus satoshis
from the UTXOs back to the spender. They can reuse the same P2PKH pubkey hash
or P2SH script hash as was used in the UTXO, but for the reasons
described in the [next subsection](#avoiding-key-reuse), it is highly recommended that change
@ -719,7 +718,7 @@ fixed URI to which payments should be sent, please see the
None of Bitcoin's signature hash types protect the signature script, leaving
the door open for a limited denial of service attack called [transaction
malleability][]{:.term}{:#term-transaction-malleability}. The signature script
malleability][/en/glossary/malleability]{:.term}{:#term-transaction-malleability}. The signature script
contains the secp256k1 signature, which can't sign itself, allowing attackers to
make non-functional modifications to a transaction without rendering it
invalid. For example, an attacker can add some data to the signature script

33
_includes/guide_wallets.md
View file

@ -284,7 +284,7 @@ Private keys are what are used to unlock satoshis from a particular address. In
{% autocrossref %}
In order to make copying of private keys less prone to error, [Wallet Import Format][]{:#term-wallet-import-format}{:.term} may be utilized. WIF uses base58Check encoding on an private key, greatly decreasing the chance of copying error, much like standard Bitcoin addresses.
In order to make copying of private keys less prone to error, [Wallet Import Format][/en/glossary/wallet-import-format]{:#term-wallet-import-format}{:.term} may be utilized. WIF uses base58Check encoding on an private key, greatly decreasing the chance of copying error, much like standard Bitcoin addresses.
1. Take a private key.
@ -403,7 +403,7 @@ For consistent word ordering:
{% autocrossref %}
The hierarchical deterministic key creation and transfer protocol ([HD
protocol][]{:#term-hd-protocol}{:.term}) greatly simplifies wallet
protocol][/en/glossary/hd-protocol]{:#term-hd-protocol}{:.term}) greatly simplifies wallet
backups, eliminates the need for repeated communication between multiple
programs using the same wallet, permits creation of child accounts which
can operate independently, gives each parent account the ability to
@ -424,9 +424,8 @@ point (the public key):
{% autocrossref %}
Because of the way `point()` functions, it's possible to create a [child
public key][]{:#term-child-public-key}{:.term} by combining an
existing [(parent) public key][parent public
key]{:#term-parent-public-key}{:.term} with another public key created from any
public key][/en/glossary/child-key]{:#term-child-public-key}{:.term} by combining an
existing [(parent) public key][/en/glossary/parent-key]{:#term-parent-public-key}{:.term} with another public key created from any
integer (*i*) value. This child public key is the same public key which
would be created by the `point()` function if you added the *i* value to
the original (parent) private key and then found the remainder of that
@ -439,8 +438,8 @@ sum divided by a global constant used by all Bitcoin software (*G*):
{% autocrossref %}
This means that two or more independent programs which agree on a
sequence of integers can create a series of unique [child key][]{:#term-child-key}{:.term} pairs from
a single [parent key][]{:#term-parent-key}{:.term} pair without any further communication.
sequence of integers can create a series of unique [child key][/en/glossary/child-key]{:#term-child-key}{:.term} pairs from
a single [parent key][/en/glossary/parent-key]{:#term-parent-key}{:.term} pair without any further communication.
Moreover, the program which distributes new public keys for receiving
payment can do so without any access to the private keys, allowing the
public key distribution program to run on a possibly-insecure platform such as
@ -469,10 +468,10 @@ The HD protocol uses a single root seed to create a hierarchy of
child, grandchild, and other descended keys with unlinkable
deterministically-generated integer values. Each child key also gets
a deterministically-generated seed from its parent, called a [chain
code][]{:#term-chain-code}{:.term}, so the compromising of one chain
code][/en/glossary/chain-code]{:#term-chain-code}{:.term}, so the compromising of one chain
code doesn't necessary compromise the integer sequence for the whole
hierarchy, allowing the [master chain
code][]{:#term-master-chain-code}{:.term} to continue being useful
code][/en/glossary/master-chain-code-and-private-key]{:#term-master-chain-code}{:.term} to continue being useful
even if, for example, a web-based public key distribution program
gets hacked.
@ -480,10 +479,10 @@ gets hacked.
As illustrated above, HD key derivation takes four inputs<!--noref-->:
* The *[parent private key][]{:#term-parent-private-key}{:.term}* and
* The *[parent private key][/en/glossary/parent-key]{:#term-parent-private-key}{:.term}* and
*parent public key* are regular uncompressed 256-bit ECDSA keys.
* The [parent chain code][]{:#term-parent-chain-code}{:.term} is 256
* The [parent chain code][/en/glossary/chain-code]{:#term-parent-chain-code}{:.term} is 256
bits of seemingly-random data.
* The [index][key index]{:#term-key-index}{:.term} number is a 32-bit integer specified by the program.
@ -511,17 +510,17 @@ child keys using the child chain code will create unlinkable grandchild keys.
Because creating child keys requires both a key and a chain code, the
key and chain code together are called the [extended
key][]{:#term-extended-key}{:.term}. An [extended private
key][]{:#term-extended-private-key}{:.term} and its corresponding
[extended public key][]{:#term-extended-public-key}{:.term} have the
key][/en/glossary/extended-key]{:#term-extended-key}{:.term}. An [extended private
key][/en/glossary/extended-key]{:#term-extended-private-key}{:.term} and its corresponding
[extended public key][/en/glossary/extended-key]{:#term-extended-public-key}{:.term} have the
same chain code. The (top-level parent) [master private
key][]{:#term-master-private-key}{:.term} and master chain
key][/en/glossary/master-chain-code-and-private-key]{:#term-master-private-key}{:.term} and master chain
code are derived from random data,
as illustrated below.
![Creating A Root Extended Key Pair](/img/dev/en-hd-root-keys.svg)
A [root seed][]{:#term-root-seed}{:.term} is created from either 128
A [root seed][/en/glossary/hd-wallet-seed]{:#term-root-seed}{:.term} is created from either 128
bits, 256 bits, or 512 bits of random data. This root seed of as little
as 128 bits is the the only data the user needs to backup in order to
derive every key created by a particular wallet program using
@ -589,7 +588,7 @@ knowing the parent private key. In other words, parent extended public
keys can't create hardened child public keys.
Because of that, a [hardened extended private
key][]{:#term-hardened-extended-private-key}{:.term} is much less
key][/en/glossary/hardened-extended-key]{:#term-hardened-extended-private-key}{:.term} is much less
useful than a normal extended private key---however,
hardened extended private keys create a firewall through which
multi-level key derivation compromises cannot happen. Because hardened

2
_includes/helpers/subhead-links.md
View file

@ -7,5 +7,5 @@ http://opensource.org/licenses/MIT.
| <a href="https://github.com/bitcoin/bitcoin.org/issues/new?body=Source%20File%3A%20{{filename|uri_escape}}%0A%0A">Report Issue</a>
| <a href="/en/development#devcommunities">Discuss</a></div>
{% else %}
{% die %}
{% die "source filename not set" %}
{% endif %}

2
_includes/ref/bitcoin-core/rpcs/rpcs/addmultisigaddress.md
View file

@ -90,6 +90,6 @@ Result:
* [CreateMultiSig][rpc createmultisig]: {{summary_createMultiSig}}
* [DecodeScript][rpc decodescript]: {{summary_decodeScript}}
* [Pay-To-Script-Hash (P2SH)][P2SH]
* [Pay-To-Script-Hash (P2SH)][/en/glossary/p2sh-address]
{% endautocrossref %}

2
_includes/ref/bitcoin-core/rpcs/rpcs/createmultisig.md
View file

@ -86,6 +86,6 @@ Result:
* [AddMultiSigAddress][rpc addmultisigaddress]: {{summary_addMultiSigAddress}}
* [DecodeScript][rpc decodescript]: {{summary_decodeScript}}
* [Pay-To-Script-Hash (P2SH)][P2SH]
* [Pay-To-Script-Hash (P2SH)][/en/glossary/p2sh-address]
{% endautocrossref %}

2
_includes/ref/bitcoin-core/rpcs/rpcs/createrawtransaction.md
View file

@ -88,6 +88,6 @@ Result (wrapped):
* [DecodeRawTransaction][rpc decoderawtransaction]: {{summary_decodeRawTransaction}}
* [SignRawTransaction][rpc signrawtransaction]: {{summary_signRawTransaction}}
* [SendRawTransaction][rpc sendrawtransaction]: {{summary_sendRawTransaction}}
* [Serialized Transaction Format][raw format]
* [Serialized Transaction Format][raw transaction format]
{% endautocrossref %}

2
_includes/ref/bitcoin-core/rpcs/rpcs/decodescript.md
View file

@ -93,6 +93,6 @@ Result:
*See also*
* [CreateMultiSig][rpc createmultisig]: {{summary_createMultiSig}}
* [Pay-To-Script-Hash (P2SH)][P2SH]
* [Pay-To-Script-Hash (P2SH)][/en/glossary/p2sh-address]
{% endautocrossref %}

2
_includes/ref/bitcoin-core/rpcs/rpcs/getchaintips.md
View file

@ -48,7 +48,7 @@ The `getchaintips` RPC {{summary_getChainTips}}
- n: "→ →<br>`status`"
t: "string"
p: "Required<br>(exactly 1)"
d: "The status of this chain. Valid values are:<br>• `active` for the local best block chain<br>• `invalid` for a chain that contains one or more invalid blocks<br>• `headers-only` for a chain with valid headers whose corresponding blocks both haven't been validated and aren't stored locally<br>• `valid-headers` for a chain with valid headers whose corresponding blocks are stored locally, but which haven't been fully validated<br>• `valid-fork` for a chain which is fully validated but which isn't part of the local best block chain (it was probably the local best block chain at some point)<br>• `unknown` for a chain whose reason for not being the active chain is unknown"
d: "The status of this chain. Valid values are:<br>• `active` for the local best block chain<br>• `invalid` for a chain that contains one or more invalid blocks<br>• `headers-only`<!--noref--> for a chain with valid headers whose corresponding blocks both haven't been validated and aren't stored locally<br>• `valid-headers` for a chain with valid headers whose corresponding blocks are stored locally, but which haven't been fully validated<br>• `valid-fork` for a chain which is fully validated but which isn't part of the local best block chain (it was probably the local best block chain at some point)<br>• `unknown` for a chain whose reason for not being the active chain is unknown"
{% enditemplate %}

13
_includes/ref_block_chain.md
View file

@ -20,10 +20,10 @@ serialized header format part of the consensus rules.
| Bytes | Name | Data Type | Description
|-------|---------------------|-----------|----------------
| 4 | version | uint32_t | The [block version][]{:#term-block-version}{:.term} number indicates which set of block validation rules to follow. See the list of block versions below.
| 4 | version | uint32_t | The [block version][/en/glossary/block]{:#term-block-version}{:.term} number indicates which set of block validation rules to follow. See the list of block versions below.
| 32 | [previous block header hash][]{:#term-previous-block-header-hash}{:.term} | char[32] | A SHA256(SHA256()) hash in internal byte order of the previous block's header. This ensures no previous block can be changed without also changing this block's header.
| 32 | merkle root hash | char[32] | A SHA256(SHA256()) hash in internal byte order. The merkle root is derived from the hashes of all transactions included in this block, ensuring that none of those transactions can be modified without modifying the header. See the [merkle trees section][section merkle trees] below.
| 4 | time | uint32_t | The [block time][]{:#term-block-time}{:.term} is a Unix epoch time when the miner started hashing the header (according to the miner). Must be greater than or equal to the median time of the previous 11 blocks. Full nodes will not accept blocks with headers more than two hours in the future according to their clock.
| 4 | time | uint32_t | The block time is a Unix epoch time when the miner started hashing the header (according to the miner). Must be greater than or equal to the median time of the previous 11 blocks. Full nodes will not accept blocks with headers more than two hours in the future according to their clock.
| 4 | nBits | uint32_t | An encoded version of the target threshold this block's header hash must be less than or equal to. See the nBits format described below.
| 4 | nonce | uint32_t | An arbitrary number miners change to modify the header hash in order to produce a hash below the target threshold. If all 32-bit values are tested, the time can be updated or the coinbase transaction can be changed and the merkle root updated.
@ -92,9 +92,6 @@ fe9f0864 ........................... Nonce
{% autocrossref %}
*For an overview of merkle trees, see the [block chain guide][merkle
tree].*
The merkle root is constructed using all the TXIDs of transactions in
this block, but first the TXIDs are placed in order as required by the
consensus rules:
@ -213,12 +210,12 @@ serialized size is less than or equal to 1 MB. All fields described
below are counted towards the serialized size.
| Bytes | Name | Data Type | Description
| 80 | block header | block_header | The block header in the format described in the [block header section][block header].
| 80 | block header | block_header | The block header in the format described in the [block header section][section block header].
| *Varies* | txn_count | compactSize uint | The total number of transactions in this block, including the coinbase transaction.
| *Varies* | txns | raw transaction | Every transaction in this block, one after another, in raw transaction format. Transactions must appear in the data stream in the same order their TXIDs appeared in the first row of the merkle tree. See the [merkle tree section][section merkle trees] for details.
The first transaction in a block must be a [coinbase
transaction][]{:#term-coinbase-tx}{:.term} which should collect and
transaction][/en/glossary/coinbase-transaction]{:#term-coinbase-tx}{:.term} which should collect and
spend any transaction fees paid by transactions included in this block.
All blocks with a block height less than 6,930,000 are entitled to
@ -228,7 +225,7 @@ at 50 bitcoins and is being halved every 210,000 blocks---approximately
once every four years. As of November 2014, it's 25 bitcoins.)
Together, the transaction fees and block subsidy are called the [block
reward][]{:#term-block-reward}{:.term}. A coinbase transaction is
reward][/en/glossary/block-reward]{:#term-block-reward}{:.term}. A coinbase transaction is
invalid if it tries to spend more value than is available from the
block reward.

22
_includes/ref_p2p_networking.md
View file

@ -11,7 +11,7 @@ http://opensource.org/licenses/MIT.
This section describes the Bitcoin P2P network protocol (but it is [not a
specification][]). It does not describe the discontinued direct [IP-to-IP
payment protocol][], the [BIP70 payment protocol][payment protocol], the
payment protocol][], the [BIP70 payment protocol][/en/glossary/payment-protocol], the
[GetBlockTemplate mining protocol][section getblocktemplate], or any
network protocol never implemented in an official version of Bitcoin Core.
@ -30,7 +30,7 @@ integers mentioned in this section are transmitted in little-endian order.
The following constants and defaults are taken from Bitcoin Core's
[chainparams.cpp][core chainparams.cpp] source code file.
| Network | Default Port | [Start String][]{:#term-start-string}{:.term} | Max nBits
| Network | Default Port | [Start String][/en/glossary/start-string]{:#term-start-string}{:.term} | Max nBits
|---------|--------------|-----------------------------------------------|---------------
| Mainnet | 8333 | 0xf9beb4d9 | 0x1d00ffff
| Testnet | 18333 | 0x0b110907 | 0x1d00ffff
@ -118,7 +118,7 @@ transactions and blocks.
![Overview Of P2P Protocol Data Request And Reply Messages](/img/dev/en-p2p-data-messages.svg)
Many of the data messages use
[inventories][inventory]{:#term-inventory}{:.term} as unique identifiers
[inventories][/en/glossary/inventory]{:#term-inventory}{:.term} as unique identifiers
for transactions and blocks. Inventories have a simple 36-byte
structure:
@ -147,7 +147,7 @@ one of these unknown types.
{% autocrossref %}
The `block` message transmits a single serialized block in the format
described in the [serialized blocks section][serialized block].
described in the [serialized blocks section][section serialized blocks].
See that section for an example hexdump. It can be sent for two
different reasons:
@ -272,7 +272,7 @@ previously requested certain headers with a `getheaders` message.
| Bytes | Name | Data Type | Description
|----------|---------|------------------|-----------------
| *Varies* | count | compactSize uint | Number of block headers up to a maximum of 2,000. Note: headers-first sync assumes the sending node will send the maximum number of headers whenever possible.
| *Varies* | headers | block_header | Block headers: each 80-byte block header is in the format described in the [block headers section][block header] with an additional 0x00 suffixed. This 0x00 is called the transaction count, but because the headers message doesn't include any transactions, the transaction count is always zero.
| *Varies* | headers | block_header | Block headers: each 80-byte block header is in the format described in the [block headers section][section block header] with an additional 0x00 suffixed. This 0x00 is called the transaction count, but because the headers message doesn't include any transactions, the transaction count is always zero.
The following annotated hexdump shows a `headers` message. (The message
header has been omitted.)
@ -375,7 +375,7 @@ be complete:
being processed by the filter.
There is no payload in a `mempool` message. See the [message header
section][message header] for an example of a message without a payload.
section][section message header] for an example of a message without a payload.
{% endautocrossref %}
@ -401,7 +401,7 @@ proof of work.
| Bytes | Name | Data Type | Description
|----------|--------------------|------------------|----------------
| 80 | block header | block_header | The block header in the format described in the [block header section][block header].
| 80 | block header | block_header | The block header in the format described in the [block header section][section block header].
| 4 | transaction count | uint32_t | The number of transactions in the block (including ones that don't match the filter).
| *Varies* | hash count | compactSize uint | The number of hashes in the following field.
| *Varies* | hashes | char[32] | One or more hashes of both transactions and merkle nodes in internal byte order. Each hash is 32 bits.
@ -606,7 +606,7 @@ format. It can be sent in a variety of situations;
transactions it originates.
For an example hexdump of the raw transaction format, see the [raw
transaction section][raw format].
transaction section][raw transaction format].
{% endautocrossref %}
@ -845,7 +845,7 @@ replacement filter is loaded with `filterload`. It also doesn't require
a `filterload` message before a `filterclear` message.
There is no payload in a `filterclear` message. See the [message header
section][message header] for an example of a message without a payload.
section][section message header] for an example of a message without a payload.
{% endautocrossref %}
@ -1100,7 +1100,7 @@ database of available nodes rather than waiting for unsolicited `addr`
messages to arrive over time.
There is no payload in a `getaddr` message. See the [message header
section][message header] for an example of a message without a payload.
section][section message header] for an example of a message without a payload.
{% endautocrossref %}
@ -1218,7 +1218,7 @@ The `verack` message acknowledges a previously-received `version`
message, informing the connecting node that it can begin to send
other messages. The `verack` message has no payload; for an example
of a message with no payload, see the [message headers
section][message header].
section][section message header].
{% endautocrossref %}

14
_includes/ref_transactions.md
View file

@ -161,7 +161,7 @@ bytes commonly used by Bitcoin are:
4. Append the checksum to the version and hash, and encode it as a base58
string: <!--[-->`BASE58(version . hash . checksum)`<!--]-->
Bitcoin's base58 encoding, called [Base58Check][]{:#term-base58check}{:.term} may not match other implementations. Tier
Bitcoin's base58 encoding, called [Base58Check][/en/glossary/base58check]{:#term-base58check}{:.term} may not match other implementations. Tier
Nolan provided the following example encoding algorithm to the Bitcoin
Wiki [Base58Check
encoding](https://en.bitcoin.it/wiki/Base58Check_encoding) page under
@ -202,7 +202,7 @@ against the extracted checksum, and then remove the version byte.
{% autocrossref %}
Bitcoin transactions are broadcast between peers
in a serialized byte format, called [raw format][]{:#term-raw-format}{:.term}.
in a serialized byte format, called [raw format][/en/glossary/serialized-transaction]{:#term-raw-format}{:.term}.
It is this form of a transaction which is SHA256(SHA256()) hashed to create
the TXID and, ultimately, the merkle root of a block containing the
transaction---making the transaction format part of the consensus rules.
@ -229,7 +229,7 @@ A raw transaction has the following top-level format:
A transaction may have multiple inputs and outputs, so the txIn and
txOut structures may recur within a transaction. CompactSize unsigned
integers are a form of variable-length integers; they are described in
the [CompactSize section][CompactSize unsigned integer].
the [CompactSize section][section CompactSize unsigned integer].
{% endautocrossref %}
@ -247,7 +247,7 @@ Each non-coinbase input spends an outpoint from a previous transaction.
| 36 | previous_output | outpoint | The previous outpoint being spent. See description of outpoint below.
| *Varies* | script bytes | compactSize uint | The number of bytes in the signature script. Maximum is 10,000 bytes.
| *Varies* | signature script | char[] | A script-language script which satisfies the conditions placed in the outpoint's pubkey script. Should only contain data pushes; see the [signature script modification warning][].
| 4 | sequence | uint32_t | Sequence number; see [sequence number][]. Default for Bitcoin Core and almost all other programs is 0xffffffff.
| 4 | sequence | uint32_t | Sequence number. Default for Bitcoin Core and almost all other programs is 0xffffffff.
{% endautocrossref %}
@ -341,9 +341,9 @@ has the following format.
| 32 | hash (null) | char[32] | A 32-byte null, as a coinbase has no previous outpoint.
| 4 | index (UINT32_MAX) | uint32_t | 0xffffffff, as a coinbase has no previous outpoint.
| *Varies* | script bytes | compactSize uint | The number of bytes in the coinbase script, up to a maximum of 100 bytes.
| *Varies* (4) | height | script | The [block height][]{:#term-coinbase-block-height}{:.term} of this block as required by BIP34. Uses script language: starts with a data-pushing op code that indicates how many bytes to push to the stack followed by the block height as a little-endian unsigned integer. This script must be as short as possible, otherwise it may be rejected.<br/><br/> The data-pushing op code will be 0x03 and the total size four bytes until block 16,777,216 about 300 years from now.
| *Varies* | coinbase script | *None* | The [coinbase field][]{:#term-coinbase-field}{:.term}: Arbitrary data not exceeding 100 bytes minus the (4) height bytes. Miners commonly place an extra nonce in this field to update the block header merkle root during hashing.
| 4 | sequence | uint32_t | Sequence number; see [sequence number][].
| *Varies* (4) | height | script | The [block height][/en/glossary/coinbase]{:#term-coinbase-block-height}{:.term} of this block as required by BIP34. Uses script language: starts with a data-pushing op code that indicates how many bytes to push to the stack followed by the block height as a little-endian unsigned integer. This script must be as short as possible, otherwise it may be rejected.<br/><br/> The data-pushing op code will be 0x03 and the total size four bytes until block 16,777,216 about 300 years from now.
| *Varies* | coinbase script | *None* | The [coinbase field][/en/glossary/coinbase]{:#term-coinbase-field}{:.term}: Arbitrary data not exceeding 100 bytes minus the (4) height bytes. Miners commonly place an extra nonce in this field to update the block header merkle root during hashing.
| 4 | sequence | uint32_t | Sequence number.
Most (but not all) blocks prior to block height 227,836 used block
version 1 which did not require the height parameter to be prefixed to

180
_includes/references.md
View file

@ -4,147 +4,43 @@ http://opensource.org/licenses/MIT.
{% endcomment %}
<!-- Terms; must have tooltip description in "quotes"; alphabetical order -->
[51 percent attack]: /en/developer-guide#term-51-attack "The ability of someone controlling a majority of hashing power to revise transactions history and prevent new transactions from confirming"
[addr message]: /en/developer-reference#addr "The P2P network message which relays IP addresses and port numbers of active nodes to other nodes and clients, allowing decentralized peer discovery."
[addresses]: /en/developer-guide#term-address "A 20-byte hash formatted as a P2PKH or P2SH Bitcoin Address"
[address]: /en/developer-guide#term-address "A 20-byte hash formatted as a P2PKH or P2SH Bitcoin Address"
[alert message]: /en/developer-reference#alert "The P2P network message which sends alerts in case of major software problems."
[base58Check]: /en/developer-reference#term-base58check "The method used in Bitcoin for converting 160-bit hashes into Bitcoin addresses"
[bitcoin URI]: /en/developer-guide#term-bitcoin-uri "A URI which allows receivers to encode payment details so spenders don't have to manually enter addresses and other details"
[bitcoins]: /en/developer-guide#term-bitcoins "A primary accounting unit used in Bitcoin; 100 million satoshis"
[bits]: /en/developer-guide#term-bits "0.000001 bitcoins (100 satoshis)"
[block]: /en/developer-guide#term-block "A block of transactions protected by proof of work"
[blocks]: /en/developer-guide#term-block "Blocks of transactions protected by proof of work"
[blocks-first sync]: /en/developer-guide#blocks-first "Synchronizing the block chain by downloading each block from a peer and then validating it"
[block chain]: /en/developer-guide#block-chain "A chain of blocks with each block linking to the block that preceded; the most-difficult-to-recreate chain is The Block Chain"
[block header]: /en/developer-reference#block-headers "An 80-byte header belonging to a single block which is hashed repeatedly to create proof of work"
[block height]: /en/developer-guide#term-block-height "The number of chained blocks preceding this block"
[block message]: /en/developer-reference#block "The P2P network message which sends a serialized block"
[block reward]: /en/developer-reference#term-block-reward "New satoshis given to a miner for creating one of the first 6,929,999 blocks"
[block time]: /en/developer-reference#term-block-time "The time field in the block header"
[block version]: /en/developer-reference#term-block-version "The version field in the block header"
[bloom filter]: /en/developer-guide#bloom-filters "A filter used primarily by SPV nodes to request only matching transactions and merkle blocks from full nodes"
[broadcast]: /en/developer-guide#transaction-broadcasting "Sending transactions or blocks to all other peers on the Bitcoin network (compare to privately transmitting to a single peer or partner"
[broadcasts]: /en/developer-guide#transaction-broadcasting "Sending transactions or blocks to all other peers on the Bitcoin network (compare to privately transmitting to a single peer or partner"
[broadcasting]: /en/developer-guide#transaction-broadcasting "Sending transactions or blocks to all other peers on the Bitcoin network (compare to privately transmitting to a single peer or partner)"
[certificate chain]: /en/developer-examples#term-certificate-chain "A chain of certificates connecting a individual's leaf certificate to the certificate authority's root certificate"
[chain code]: /en/developer-guide#term-chain-code "In HD wallets, 256 bits of entropy added to the master public and private keys to help them generate secure child keys; the chain code is usually derived from a seed along with the master private key"
[change address]: /en/developer-guide#term-change-output "An output used by a spender to send back to himself some of the satoshis from the inputs"
[change output]: /en/developer-guide#term-change-output "An output used by a spender to send back to himself some of the satoshis from the inputs"
[child key]: /en/developer-guide#term-child-key "In HD wallets, a key derived from a parent key"
[child public key]: /en/developer-guide#term-child-public-key "In HD wallets, a public key derived from a parent public key or a corresponding child private key"
[coinbase block height]: /en/developer-reference#term-coinbase-block-height "The current block's height encoded into the first bytes of the coinbase field"
[coinbase field]: /en/developer-reference#term-coinbase-field "A special input-like field for coinbase transactions"
[coinbase transaction]: /en/developer-reference#term-coinbase-tx "A special transaction which miners must create when they generate a block"
[compactsize unsigned integer]: /en/developer-reference#compactsize-unsigned-integers "A type of variable-length integer"
[compressed public key]: /en/developer-guide#public-key-formats "A public key that is 33 bytes long rather than the 65 bytes of an uncompressed public key"
[confirm]: /en/developer-guide#term-confirmation "A transaction included in a block currently on the block chain"
[confirmed]: /en/developer-guide#term-confirmation "A transaction included in a block currently on the block chain"
[confirmed transactions]: /en/developer-guide#term-confirmation "Transactions included in a block currently on the block chain"
[confirmation]: /en/developer-guide#term-confirmation "The number of blocks which would need to be modified to remove or modify a transaction"
[confirmations]: /en/developer-guide#term-confirmation "The number of blocks which would need to be modified to remove or modify a transaction"
[consensus]: /en/developer-guide#term-consensus "When several nodes (usually most nodes on the network) all have the same blocks in their locally-validated block chain."
[consensus rules]: /en/developer-guide#term-consensus-rules "The block validation rules that full nodes follow to stay in consensus with other nodes."
[data-pushing op code]: https://en.bitcoin.it/wiki/Script#Constants "Any op code from 0x01 to 0x4e which pushes data on to the script evaluation stack"
[denomination]: /en/developer-guide#term-denomination "bitcoins (BTC), bitcents (cBTC), millibitcoins (mBTC), bits (uBTC, microbitcoins), or satoshis"
[difficulty]: /en/developer-guide#term-difficulty "A number corresponding to the target threshold which indicates how difficult it will be to find the next block"
[dns seed]: /en/developer-guide#term-dns-seed "A DNS server which returns IP addresses of full nodes on the Bitcoin network to assist in peer discovery."
[double spend]: /en/developer-guide#term-double-spend "Attempting to spend the same satoshis which were spent in a previous transaction"
[extended key]: /en/developer-guide#term-extended-key "A public or private key extended with the chain code to allow them to derive child keys"
[extended private key]: /en/developer-guide#term-extended-private-key "A private key extended with the chain code so that it can derive child private keys"
[extended public key]: /en/developer-guide#term-extended-public-key "A public key extended with the chain code so that it can derive child public keys"
[escrow contract]: /en/developer-guide#term-escrow-contract "A contract in which the spender and receiver store satoshis in a multisig output until both parties agree to release the satoshis"
[fiat]: /en/developer-guide#term-fiat "National currencies such as the dollar or euro"
[filteradd message]: /en/developer-reference#filteradd "A P2P protocol message used to add a data element to an existing bloom filter."
[filterclear message]: /en/developer-reference#filterclear "A P2P protocol message used to remove an existing bloom filter."
[filterload message]: /en/developer-reference#filterclear "A P2P protocol message used to send a filter to a remote peer, requesting that they only send transactions which match the filter."
[fork]: /en/developer-guide#term-fork "When two or more blocks have the same block height, forking the block chain."
[genesis block]: /en/developer-guide#term-genesis-block "The first block created; also called block 0"
[getaddr message]: /en/developer-reference#getaddr "A P2P protool message used to request an addr message containing connection information for other nodes"
[getblocks message]: /en/developer-reference#getblocks "A P2P protocol message used to request an inv message containing a range of block header hashes"
[getdata message]: /en/developer-reference#getdata "A P2P protocol message used to request one or more transactions, blocks, or merkle blocks"
[getheaders message]: /en/developer-reference#getheaders "A P2P protocol message used to request a range of block headers"
[hard fork]: /en/developer-guide#term-hard-fork "A permanent divergence in the the block chain, commonly occurs when non-upgraded nodes can't validate blocks created by upgraded nodes following newer consensus rules."
[hardened extended private key]: /en/developer-guide#term-hardened-extended-private-key "A private key whose corresponding public key cannot derive child keys"
[HD protocol]: /en/developer-guide#term-hd-protocol "The Hierarchical Deterministic (HD) key creation and transfer protocol"
[header chain]: /en/developer-guide#term-header-chain "A chain of block headers with each header linking to the header that preceded it; the most-difficult-to-recreate chain is the best header chain"
[headers-first sync]: /en/developer-guide#headers-first "Synchronizing the block chain by downloading block headers before downloading the full blocks"
[headers message]: /en/developer-reference#headers "A P2P protocol message containing one or more block headers"
[high-priority transactions]: /en/developer-guide#term-high-priority-transactions "Transactions which don't pay a transaction fee; only transactions spending long-idle outputs are eligible"
[initial block download]: /en/developer-guide#initial-block-download "The process used by a new node (or long-offline node) to download a large number of blocks to catch up to the tip of the best block chain"
[input]: /en/developer-guide#term-input "The input to a transaction linking to the output of a previous transaction which permits spending of satoshis"
[inputs]: /en/developer-guide#term-input "The input to a transaction linking to the output of a previous transaction which permits spending of satoshis"
[intermediate certificate]: /en/developer-examples#term-intermediate-certificate "A intermediate certificate authority certificate which helps connect a leaf (receiver) certificate to a root certificate authority"
[internal byte order]: /en/developer-reference#hash-byte-order "The standard order in which hash digests are displayed as strings---the same format used in blocks"
[inv message]: /en/developer-reference#inv "A P2P protocol message used to send inventories of transactions and blocks known to the transmitting peer"
[inventory]: /en/developer-reference#term-inventory "A data type identifier and a hash; used to identify transactions and blocks available for download through the P2P network."
[key index]: /en/developer-guide#term-key-index "An index number used in the HD wallet formula to generate child keys from a parent key"
[key pair]: /en/developer-guide#term-key-pair "A private key and its derived public key"
[label]: /en/developer-guide#term-label "The label parameter of a bitcoin: URI which provides the spender with the receiver's name (unauthenticated)"
[leaf certificate]: /en/developer-examples#term-leaf-certificate "The end-node in a certificate chain; in the payment protocol, it is the certificate belonging to the receiver of satoshis"
[locktime]: /en/developer-guide#term-locktime "Part of a transaction which indicates the earliest time or earliest block when that transaction can be added to the block chain"
[long-term fork]: /en/developer-guide#term-long-term-fork "When a series of blocks have corresponding block heights, indicating a possibly serious problem"
[mainnet]: /en/developer-examples#term-mainnet "The Bitcoin main network used to transfer satoshis (compare to testnet, the test network)"
[master chain code]: /en/developer-guide#term-master-chain-code "The chain code derived from the root seed"
[master private key]: /en/developer-guide#term-master-private-key "A private key derived from the root seed"
[mempool message]: /en/developer-reference#mempool "A P2P protocol message used to request one or more inv messages with currently-unconfirmed transactions"
[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"
[merkle block]: /en/developer-reference#merkleblock "A partial merkle tree connecting transactions matching a bloom filter to the merkle root of a block"
[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"
[merkleblock message]: /en/developer-reference#merkleblock "A P2P protocol message used to request a filtered block useful for SPV proofs"
[message]: /en/developer-guide#term-message "A parameter of bitcoin: URIs which allows the receiver to optionally specify a message to the spender"
[message header]: /en/developer-reference#message-headers "The four header fields prefixed to all messages on the P2P network"
[millibitcoins]: /en/developer-guide#term-millibitcoins "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"
[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 most circumstances to be mined or broadcast by peers across the network"
[msg_tx]: /en/developer-reference#term-msg_tx "The TXID data type identifier of an inventory on the P2P network"
[msg_block]: /en/developer-reference#term-msg_block "The block header hash data type identifier of an inventory on the P2P network"
[msg_filtered_block]: /en/developer-reference#term-msg_block "An alternative to the block header hash data type identifier of an inventory on the P2P network used to request a merkle block"
[multisig]: /en/developer-guide#term-multisig "An pubkey script using OP_CHECKMULTISIG to check for multiple signatures"
[nbits]: /en/developer-reference#target-nbits "The encoded form of the target threshold as it appears in the block header"
[network]: /en/developer-guide#term-network "The Bitcoin P2P network which broadcasts transactions and blocks"
[notfound message]: /en/developer-reference#notfound "A P2P protocol message sent to indicate that the requested data was not available"
[Null data]: /en/developer-guide#term-null-data "A standard transaction type which allows adding 40 bytes of arbitrary data to the block chain up to once per transaction"
[op_checkmultisig]: /en/developer-reference#term-op-checkmultisig "Op code which returns true if one or more provided signatures (m) sign the correct parts of a transaction and match one or more provided public keys (n)"
[op_checksig]: /en/developer-reference#term-op-checksig "Op code which returns true if a signature signs the correct parts of a transaction and matches a provided public key"
[op code]: /en/developer-reference#op-codes "Operation codes which push data or run functions within a pubkey script or signature script"
[op_dup]: /en/developer-reference#term-op-dup "Operation which duplicates the entry below it on the stack"
[op_equal]: /en/developer-reference#term-op-equal "Operation which returns true if the two entries below it on the stack are equivalent"
[op_equalverify]: /en/developer-reference#term-op-equalverify "Operation which terminates the script in failure unless the two entries below it on the stack are equivalent"
[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)"
[outpoint]: /en/developer-reference#outpoint "The structure used to refer to a particular transaction output, consisting of a 32-byte TXID and a 4-byte output index number (vout)."
[orphan block]: /en/developer-guide#orphan-blocks "Blocks whose parent block has not been processed by the local node; not to be confused with stale blocks"
[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"
[P2SH]: /en/developer-guide#term-p2sh "A pubkey script which Pays To Script Hashes (P2SH), allowing convenient spending of satoshis to an address referencing a redeem script"
[P2SH multisig]: /en/developer-guide#term-p2sh-multisig "A multisig script embedded in the redeem script of a pay-to-script-hash (P2SH) transaction"
[parent chain code]: /en/developer-guide#term-parent-chain-code "A chain code which has helped create child public or private keys"
[parent key]: /en/developer-guide#term-parent-key "In HD wallets, a key capable of deriving child keys"
[parent private key]: /en/developer-guide#term-parent-private-key "A private key which has created child private keys"
[parent public key]: /en/developer-guide#term-parent-public-key "A public key corresponding to a parent private key which has child private keys"
[payment protocol]: /en/developer-guide#term-payment-protocol "The protocol defined in BIP70 which lets spenders get signed payment details from receivers"
[PaymentDetails]: /en/developer-examples#term-paymentdetails "The PaymentDetails of the payment protocol which allows the receiver to specify the payment details to the spender"
[PaymentRequest]: /en/developer-examples#term-paymentrequest "The PaymentRequest of the payment protocol which contains and allows signing of the PaymentDetails"
[PaymentRequests]: /en/developer-examples#term-paymentrequest "The PaymentRequest of the payment protocol which contains and allows signing of the PaymentDetails"
[peer]: /en/developer-guide#term-peer "Peer on the P2P network who receives and broadcasts transactions and blocks"
[peers]: /en/developer-guide#term-peer "Peers on the P2P network who receive and broadcast transactions and blocks"
[ping message]: /en/developer-reference#ping "A P2P network message used to see if the remote host is still connected"
[PKI]: /en/developer-examples#term-pki "Public Key Infrastructure; usually meant to indicate the X.509 certificate system used for HTTP Secure (https)."
[point function]: /en/developer-guide#term-point-function "The ECDSA function used to create a public key from a private key"
[pong message]: /en/developer-reference#pong "A P2P network message used to reply to a P2P network ping message"
[previous block header hash]: /en/developer-reference#term-previous-block-header-hash "A field in the block header which contains the SHA256(SHA256()) hash of the previous block's header"
[private key]: /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"
[proper money handling]: /en/developer-reference#term-proper-money-handling "Bitcoin amounts need to be correctly processed without introducing rounding errors that could cause monetary loss"
[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 pubkey script"
[pp expires]: /en/developer-examples#term-pp-expires "The expires field of a PaymentDetails where the receiver tells the spender when the PaymentDetails expires"
[pp memo]: /en/developer-examples#term-pp-memo "The memo fields of PaymentDetails, Payment, and PaymentACK which allow spenders and receivers to send each other memos"
@ -152,70 +48,28 @@ http://opensource.org/licenses/MIT.
[pp PKI data]: /en/developer-examples#term-pp-pki-data "The pki_data field of a PaymentRequest which provides details such as certificates necessary to validate the request"
[pp pki type]: /en/developer-examples#term-pp-pki-type "The PKI field of a PaymentRequest which tells spenders how to validate this request as being from a specific recipient"
[pp script]: /en/developer-examples#term-pp-script "The script field of a PaymentDetails where the receiver tells the spender what pubkey scripts to pay"
[proof of work]: /en/developer-guide#term-proof-of-work "Proof that computationally-difficult work was performed which helps secure blocks against modification, protecting transaction history"
[Pubkey]: /en/developer-guide#term-pubkey "A cryptographic public key derived from a private key and which can match a signature made by that same private key"
[pubkey script]: /en/developer-guide#term-pubkey-script "The part of an output which sets the conditions for spending of the satoshis in that output"
[previous block header hash]: /en/developer-reference#term-previous-block-header-hash "A field in the block header which contains the SHA256(SHA256()) hash of the previous block's header"
[proper money handling]: /en/developer-reference#term-proper-money-handling "Bitcoin amounts need to be correctly processed without introducing rounding errors that could cause monetary loss"
[r]: /en/developer-guide#term-r-parameter "The payment request parameter in a bitcoin: URI"
[raw format]: /en/developer-reference#term-raw-format "Complete transactions in their binary format; often represented using hexidecimal"
[receipt]: /en/developer-guide#term-receipt "A cryptographically-verifiable receipt created using parts of a payment request and a confirmed transaction"
[recurrent rebilling]: /en/developer-guide#rebilling-recurring-payments "Billing a spender on a regular schedule"
[redeem script]: /en/developer-guide#term-redeem-script "A pubkey script created by the recipient, hashed, and given to the spender for use in a P2SH output"
[refund]: /en/developer-guide#issuing-refunds "A transaction which refunds some or all satoshis received in a previous transaction"
[regression test mode]: /en/developer-examples#regtest-mode "A local testing environment in which developers can control blocks"
[reject message]: /en/developer-reference#reject "A P2P network message used to indicate a previously-received message was rejected for some reason"
[root certificate]: /en/developer-examples#term-root-certificate "A certificate belonging to a certificate authority (CA)"
[root seed]: /en/developer-guide#term-root-seed "A potentially-short value used as a seed to generate a master private key and master chain code for an HD wallet"
[RPC byte order]: /en/developer-reference#hash-byte-order "A hash digest displayed with the byte order reversed; used in Bitcoin Core RPCs and other software."
[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"
[script hash]: /en/developer-guide#term-script-hash "The hash of a redeem script used to create a P2SH output"
[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"
[serialized block]: /en/developer-reference#serialized-blocks "A block in the serialized form used to compute block byte size"
[sha_shacp]: /en/developer-guide#term-sighash-all-sighash-anyonecanpay "Signature hash type which allows other people to contribute satoshis without changing the number of satoshis sent nor where they go"
[shacp]: /en/developer-guide#term-sighash-anyonecanpay "A signature hash type which modifies the behavior of other signature hash types"
[shn_shacp]: /en/developer-guide#term-sighash-none-sighash-anyonecanpay "Signature hash type which allows unfettered modification of a transaction"
[shs_shacp]: /en/developer-guide#term-sighash-single-sighash-anyonecanpay "Signature hash type which allows modification of the entire transaction except the signed input and the output with the same index number"
[sighash_all]: /en/developer-guide#term-sighash-all "Default signature hash type which signs the entire transaction except any signature scripts, preventing modification of the signed parts"
[sighash_none]: /en/developer-guide#term-sighash-none "Signature hash type which only signs the inputs, allowing anyone to change the outputs however they'd like"
[sighash_single]: /en/developer-guide#term-sighash-single "Signature hash type which only signs its input and the output with the same index value, allowing modification of other inputs and outputs"
[signature]: /en/developer-guide#term-signature "The result of combining a private key and some data in an ECDSA signature operation which allows anyone with the corresponding public key to verify the signature"
[signature hash]: /en/developer-guide#term-signature-hash "A byte appended onto signatures generated in Bitcoin which allows the signer to specify what data was signed, allowing modification of the unsigned data"
[signature script]: /en/developer-guide#term-signature-script "Data generated by a spender which is almost always used as variables to satisfy a pubkey script"
[soft fork]: /en/developer-guide#term-soft-fork "A temporary fork in the block chain which commonly occurs when miners using non-upgraded nodes violate a new consensus rule their nodes don't know about."
[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; not to be confused with orphan blocks"
[standard block relay]: /en/developer-guide#term-standard-block-relay "The regular block relay method: announcing a block with an inv message and waiting for a response"
[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"
[start string]: /en/developer-reference#term-start-string "Four defined bytes which start every message in the P2P protocol to allow seeking to the next message"
[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"
[transaction fees]: /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 malleability]: /en/developer-guide#transaction-malleability "The ability of an attacker to change the transaction identifier (txid) of unconfirmed transactions, making dependent transactions invalid"
[transaction]: /en/developer-guide#transactions "A transaction spending satoshis"
[transaction version number]: /en/developer-guide#term-transaction-version-number "A version number prefixed to transactions to allow upgrading""
[transactions]: /en/developer-guide#transactions "A transaction spending satoshis"
[tx message]: /en/developer-reference#tx "A P2P protocol message which sends a single serialized transaction"
[txid]: /en/developer-guide#term-txid "A hash of a completed transaction which allows other transactions to spend its outputs"
[unconfirmed]: /en/developer-guide#term-unconfirmed-transactions "A transaction which has not yet been added to the block chain"
[unconfirmed transactions]: /en/developer-guide#term-unconfirmed-transactions "A transaction which has not yet been added to the block chain"
[unencrypted wallet]: /en/developer-reference#encryptwallet "A wallet that has not been encrypted with the encryptwallet RPC"
[unique addresses]: /en/developer-guide#term-unique-address "Address which are only used once to protect privacy and increase security"
[unlocked wallet]: /en/developer-reference#walletpassphrase "An encrypted wallet that has been unlocked with the walletpassphrase RPC"
[unsolicited block push]: /en/developer-guide#term-unsolicited-block-push "When a miner sends a block message without sending an inv message first"
[URI QR Code]: /en/developer-guide#term-uri-qr-code "A QR code containing a bitcoin: URI"
[utxo]: /en/developer-guide#term-utxo "Unspent Transaction Output (UTXO) holding satoshis which have not yet been spent"
[verack message]: /en/developer-reference#verack "A P2P network message sent in reply to a version message to confirm a connection has been established"
[verified payments]: /en/developer-guide#verifying-payment "Payments which the receiver believes won't be double spent"
[version message]: /en/developer-reference#version "A P2P network message sent at the begining of a connection to allow protocol version negotiation"
[v2 block]: /en/developer-reference#term-v2-block "The current version of Bitcoin blocks"
[watch-only]: /en/developer-reference#importaddress "An address or pubkey script stored in the wallet without the corresponding private key, allowing the wallet to watch for outputs but not spend them"
[wallet]: /en/developer-guide#wallets "Software which stores private keys to allow users to spend and receive satoshis"
[Wallet Import Format]: /en/developer-guide#term-wallet-import-format "A private key specially formatted to allow easy import into a wallet"
[verified payments]: /en/developer-guide#verifying-payment "Payments which the receiver believes won't be double spent"
[wallet support]: /en/developer-reference#term-wallet-support "A Bitcoin Core ./configure option that enables (default) or disables the wallet"
[wallets]: /en/developer-guide#wallets "Software which stores private keys to allow users to spend and receive satoshis"
<!-- RPCs; alphabetical order -->
[rpc addmultisigaddress]: /en/developer-reference#addmultisigaddress
@ -305,6 +159,28 @@ http://opensource.org/licenses/MIT.
[rest get block-notxdetails]: /en/developer-reference#get-blocknotxdetails
[rest get tx]: /en/developer-reference#get-tx
<!-- P2P protocol messages; alphabetical order -->
[addr message]: /en/developer-reference#addr "The P2P network message which relays IP addresses and port numbers of active nodes to other nodes and clients, allowing decentralized peer discovery."
[alert message]: /en/developer-reference#alert "The P2P network message which sends alerts in case of major software problems."
[block message]: /en/developer-reference#block "The P2P network message which sends a serialized block"
[filteradd message]: /en/developer-reference#filteradd "A P2P protocol message used to add a data element to an existing bloom filter."
[filterclear message]: /en/developer-reference#filterclear "A P2P protocol message used to remove an existing bloom filter."
[filterload message]: /en/developer-reference#filterclear "A P2P protocol message used to send a filter to a remote peer, requesting that they only send transactions which match the filter."
[getaddr message]: /en/developer-reference#getaddr "A P2P protool message used to request an addr message containing connection information for other nodes"
[getblocks message]: /en/developer-reference#getblocks "A P2P protocol message used to request an inv message containing a range of block header hashes"
[getdata message]: /en/developer-reference#getdata "A P2P protocol message used to request one or more transactions, blocks, or merkle blocks"
[getheaders message]: /en/developer-reference#getheaders "A P2P protocol message used to request a range of block headers"
[headers message]: /en/developer-reference#headers "A P2P protocol message containing one or more block headers"
[inv message]: /en/developer-reference#inv "A P2P protocol message used to send inventories of transactions and blocks known to the transmitting peer"
[mempool message]: /en/developer-reference#mempool "A P2P protocol message used to request one or more inv messages with currently-unconfirmed transactions"
[merkleblock message]: /en/developer-reference#merkleblock "A P2P protocol message used to request a filtered block useful for SPV proofs"
[notfound message]: /en/developer-reference#notfound "A P2P protocol message sent to indicate that the requested data was not available"
[ping message]: /en/developer-reference#ping "A P2P network message used to see if the remote host is still connected"
[pong message]: /en/developer-reference#pong "A P2P network message used to reply to a P2P network ping message"
[reject message]: /en/developer-reference#reject "A P2P network message used to indicate a previously-received message was rejected for some reason"
[tx message]: /en/developer-reference#tx "A P2P protocol message which sends a single serialized transaction"
[verack message]: /en/developer-reference#verack "A P2P network message sent in reply to a version message to confirm a connection has been established"
[version message]: /en/developer-reference#version "A P2P network message sent at the begining of a connection to allow protocol version negotiation"
<!-- Other internal site links; alphabetical order -->
[Bitcoin Core 0.6.0]: /en/release/v0.6.0
[Bitcoin Core 0.6.1]: /en/release/v0.6.1
@ -336,13 +212,17 @@ http://opensource.org/licenses/MIT.
[raw transaction format]: /en/developer-reference#raw-transaction-format
[RPC]: /en/developer-reference#remote-procedure-calls-rpcs
[RPCs]: /en/developer-reference#remote-procedure-calls-rpcs
[section block chain]: /en/developer-guide#block-chain
[section block header]: /en/developer-reference#block-headers
[section block versions]: /en/developer-reference#block-versions
[section creating a bloom filter]: /en/developer-examples#creating-a-bloom-filter
[section compactSize unsigned integer]: /en/developer-reference#compactsize-unsigned-integers
[section detecting forks]: /en/developer-guide#detecting-forks
[section getblocktemplate]: /en/developer-guide#getblocktemplate-rpc
[section hash byte order]: /en/developer-reference#hash-byte-order
[section merkle trees]: /en/developer-reference#merkle-trees
[section merkleblock example]: /en/developer-examples#parsing-a-merkleblock
[section message header]: /en/developer-reference#message-headers
[section p2p reference]: /en/developer-reference#p2p-network
[section protocol versions]: /en/developer-reference#protocol-versions
[section rpc quick reference]: /en/developer-reference#rpc-quick-reference
@ -355,7 +235,7 @@ http://opensource.org/licenses/MIT.
[X509Certificates]: /en/developer-examples#term-x509certificates
<!-- Official reference documents (BIPs should not use zero padding:
BIP32 not BIP0032; alphabetical order -->
BIP32 not BIP0032); alphabetical order -->
[BIP14]: https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki
[BIP16]: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
[BIP21]: https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki