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

Fix links for new glossary entries

Browse source
This commit is contained in:
David A. Harding 2015-03-16 12:14:28 -04:00
parent 494dfaced7
commit 801ea9f4ad
No known key found for this signature in database
GPG key ID: 4B29C30FF29EC4B7
16 changed files with 112 additions and 117 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 %} {% autocrossref %}
When run with no arguments, all Bitcoin Core programs default to Bitcoin's main 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) 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 where the satoshis spent have no real-world value. Testnet also relaxes some
restrictions (such as standard transaction checks) so you can test functions 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. described below.
In order to use this tutorial, you will need to setup [Bitcoin Core][core executable] 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. wallet.
{% endautocrossref %} {% 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 about, so we get the three new addresses above in order to use their
public keys. 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 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 person or device as part of creating a typical multisig output or P2SH multisig
redeem script. You must give them a full public key. 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 Each full node in the Bitcoin network independently stores a block chain
containing only blocks validated by that node. When several nodes all 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 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 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. the consensus rules used by Bitcoin Core.
{% endautocrossref %} {% endautocrossref %}
@ -31,11 +31,11 @@ the consensus rules used by Bitcoin Core.
![Block Chain Overview](/img/dev/en-blockchain-overview.svg) ![Block Chain Overview](/img/dev/en-blockchain-overview.svg)
The illustration above shows a simplified version of a block chain. 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. is collected into the transaction data part of a block.
Copies of each transaction are hashed, and the hashes are then paired, Copies of each transaction are hashed, and the hashes are then paired,
hashed, paired again, and hashed again until a single hash remains, the 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 The merkle root is stored in the block header. Each block also
stores the hash of the previous block's header, chaining the blocks 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 block chain. Any subsequent reference is a forbidden double
spend---an attempt to spend the same satoshis twice. 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. of signed transactions.
Because each output of a particular transaction can only be spent once, 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 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. payment to be valid, it must only use UTXOs as inputs.
Ignoring coinbase transactions (described later), if the value of a Ignoring coinbase transactions (described later), if the value of a
transaction's outputs exceed its inputs, the transaction will be transaction's outputs exceed its inputs, the transaction will be
rejected---but if the inputs exceed the value of the outputs, any rejected---but if the inputs exceed the value of the outputs, any
difference in value may be claimed as a [transaction difference in value may be claimed as a [transaction
fee][]{:#term-transaction-fee}{:.term} by the Bitcoin fee][/en/glossary/transaction-fee]{:#term-transaction-fee}{:.term} by the Bitcoin
[miner][]{:#term-miner}{:.term} who creates the block containing that [miner][/en/glossary/mining]{:#term-miner}{:.term} who creates the block containing that
transaction. transaction.
For example, in the illustration above, each transaction spends 10,000 satoshis 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 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 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. 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. takes advantage of the apparently random nature of cryptographic hashes.
A good cryptographic hash algorithm converts arbitrary data into a A good cryptographic hash algorithm converts arbitrary data into a
seemingly-random number. If the data is modified in any way and 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. In the example given above, you will produce a successful hash on average every other try.
You can even estimate the probability 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. 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. 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 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 Every 2,016 blocks, the network uses timestamps stored in each
block header to calculate the number of seconds elapsed between generation 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 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 propagate a modified block as the entire Bitcoin network expended
between the time the original block was created and the present time. between the time the original block was created and the present time.
Only if you acquired a majority of the network's hashing power 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). 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 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 below the target threshold can add the entire block to the block chain
(assuming the block is otherwise valid). (assuming the block is otherwise valid).
These blocks are commonly addressed These blocks are commonly addressed
by their [block height][]{:#term-block-height}{:.term}---the number of blocks between them and the first Bitcoin 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]{:#term-genesis-block}{:.term}). For example, 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. block 2016 is where difficulty could have first been adjusted.
![Common And Uncommon Block Chain Forks](/img/dev/en-blockchain-fork.svg) ![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 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 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. illustration above.
When miners produce simultaneous blocks at the end of the block chain, each 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. the fork stronger than the other side.
Assuming a fork only contains valid Assuming a fork only contains valid
blocks, normal peers always follow the the most difficult chain 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 (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.) 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 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 same time other miners are attempting a 51 percent attack to revise
transaction history. transaction history.
@ -220,7 +220,7 @@ All transactions, including the coinbase transaction, are encoded into
blocks in binary rawtransaction format. blocks in binary rawtransaction format.
The rawtransaction format is hashed to create the transaction 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 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 an odd number of txids, the txid without a partner is hashed with a
copy of itself. 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 build on the same chain as mining software getting data from upgraded
nodes. This creates permanently divergent chains---one for non-upgraded nodes. This creates permanently divergent chains---one for non-upgraded
nodes and one for upgraded nodes---called a [hard 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) ![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 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 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 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) ![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 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 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 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 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 Charlie's money if there's a problem, or Alice can arbitrate and decide
who should get the satoshis if there's a dispute. 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 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 %} {% 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 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 of any active full nodes. In order to discover some IP
addresses, they query one or more DNS names (called [DNS seeds][dns addresses, they query one or more DNS names (called [DNS seeds][/en/glossary/dns-seed]{:#term-dns-seed}{:.term})
seed]{:#term-dns-seed}{:.term}) hardcoded into Bitcoin Core and hardcoded into Bitcoin Core and
BitcoinJ. The response to the lookup should include one or more [DNS 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 A records][] with the IP addresses of full nodes that may accept new
incoming connections. For example, using the [Unix `dig` 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 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 *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 as possible, and then download the corresponding blocks in parallel. This
solves several problems with the older blocks-first IBD method. 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 | **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] | | **Message** | [`block`][block message] | [`merkleblock`][merkleblock message] | [`tx`][tx message] |
| **From→To** | Relay→BF/HF | Relay→SPV | Relay→SPV | | **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 %} {% endautocrossref %}

12
_includes/guide_payment_processing.md
View file

@ -257,7 +257,7 @@ displayed on high-resolution screens.
{% autocrossref %} {% 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: adds many important features to payment requests:
- Supports X.509 certificates and SSL encryption to verify receivers' identity - Supports X.509 certificates and SSL encryption to verify receivers' identity
@ -423,7 +423,7 @@ for more details.
{% autocrossref %} {% 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 a transaction to the network doesn't ensure that the receiver gets
paid. A malicious spender can create one transaction that pays the 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 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. can say for sure which one it will be.
Two or more transactions spending the same input are commonly referred 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 Once the transaction is included in a block, double spends are
impossible without modifying block chain history to replace the impossible without modifying block chain history to replace the
transaction, which is quite difficult. Using this system, transaction, which is quite difficult. Using this system,
the Bitcoin protocol can give each of your transactions an updating confidence 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 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 modifying blocks is quite difficult, higher confirmation scores indicate
greater protection. greater protection.
**0 confirmations**: The transaction has been broadcast but is still not **0 confirmations**: The transaction has been broadcast but is still not
included in any block. Zero confirmation transactions ([unconfirmed included in any block. Zero confirmation transactions (unconfirmed
transactions][]{:#term-unconfirmed-transactions}{:.term}) should generally not be transactions) should generally not be
trusted without risk analysis. Although miners usually confirm the first trusted without risk analysis. Although miners usually confirm the first
transaction they receive, fraudsters may be able to manipulate the transaction they receive, fraudsters may be able to manipulate the
network into including their version of a transaction. 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 Parts Of A Transaction](/img/dev/en-tx-overview.svg)
The figure above shows the main parts of a Bitcoin transaction. Each 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 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][]{:#term-output}{:.term} then waits as an Unspent 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 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 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. 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 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 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 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 and then lets Bob further spend those satoshis using a simple
cryptographic key pair. 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 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 first transaction. Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA) with
the secp256k1 curve; secp256k1 [private keys][private the secp256k1 curve; secp256k1 [private keys][/en/glossary/private-key]{:#term-private-key}{:.term} are 256 bits of random
key]{:#term-private-key}{:.term} are 256 bits of random
data. A copy of that data is deterministically transformed into an secp256k1 [public 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. public key does not need to be stored.
The public key (pubkey) is then cryptographically hashed. This pubkey hash can 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 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 --> 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 Bob provides the pubkey hash to Alice. Pubkey hashes are almost always
sent encoded as Bitcoin [addresses][]{:#term-address}{:.term}, which are base58-encoded strings 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 containing an address version number, the hash, and an error-detection
checksum to catch typos. The address can be transmitted checksum to catch typos. The address can be transmitted
through any medium, including one-way mediums which prevent the spender 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 can create the first transaction. She creates a standard P2PKH
transaction output containing instructions which allow anyone to spend that transaction output containing instructions which allow anyone to spend that
output if they can prove they control the private key corresponding to output if they can prove they control the private key corresponding to
Bob's hashed public key. These instructions are called the [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. or scriptPubKey.
Alice broadcasts the transaction and it is added to the block chain. 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 input which references the transaction Alice created by its hash, called
a Transaction Identifier (txid), and the specific output she used by its a Transaction Identifier (txid), and the specific output she used by its
index number ([output index][]{:#term-output-index}{:.term}). He must then create a [signature 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 collection of data parameters which satisfy the conditions Alice placed
in the previous output's pubkey script. Signature scripts are also in the previous output's pubkey script. Signature scripts are also
called scriptSigs. called scriptSigs.
@ -130,7 +129,7 @@ pieces of data:
1. His full (unhashed) public key, so the pubkey script can check that it 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. 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. certain transaction data (described below) with Bob's private key.
This lets the pubkey script verify that Bob owns the private key which This lets the pubkey script verify that Bob owns the private key which
created the public key. created the public key.
@ -187,7 +186,7 @@ and full public key (pubkey), creating the following concatenation:
The script language is a The script language is a
[Forth-like](https://en.wikipedia.org/wiki/Forth_%28programming_language%29) [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 Turing complete. Statelessness ensures that once a transaction is added
to the block chain, there is no condition which renders it permanently to the block chain, there is no condition which renders it permanently
unspendable. Turing-incompleteness (specifically, a lack of loops or unspendable. Turing-incompleteness (specifically, a lack of loops or
@ -264,10 +263,10 @@ pubkey scripts are less convenient than short Bitcoin addresses and more
difficult to secure than P2PKH pubkey hashes. difficult to secure than P2PKH pubkey hashes.
To solve these problems, pay-to-script-hash To solve these problems, pay-to-script-hash
([P2SH][]{:#term-p2sh}{:.term}) transactions were created in 2012 to let ([P2SH][/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 a spender create a pubkey script containing a hash of a second
script][script hash]{:#term-script-hash}{:.term}, the script, the
[redeem script][]{:#term-redeem-script}{:.term}. [redeem script][/en/glossary/redeem-script]{:#term-redeem-script}{:.term}.
The basic P2SH workflow, illustrated below, looks almost identical to The basic P2SH workflow, illustrated below, looks almost identical to
the P2PKH workflow. Bob creates a redeem script with whatever script he the P2PKH workflow. Bob creates a redeem script with whatever script he
@ -410,7 +409,7 @@ Signature script: OP_0 <A sig> <C sig> <redeemScript>
{% autocrossref %} {% 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 but they aren’t as
secure as P2PKH, so they generally secure as P2PKH, so they generally
aren’t used in new transactions anymore. aren’t used in new transactions anymore.
@ -428,7 +427,7 @@ Signature script: <sig>
{% autocrossref %} {% 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. 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 (Null data is a standard pubkey script type only because some people were adding data
to the block chain in more harmful ways.) to the block chain in more harmful ways.)
@ -509,36 +508,36 @@ from modification, this lets signers selectively choose to let other
people modify their transactions. people modify their transactions.
The various options for what to sign are 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: 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. 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 allowing anyone to change where the satoshis are going unless other
signatures using other signature hash flags protect the outputs. 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 output (the output with the same output index number as the input), ensuring
nobody can change your part of the transaction but allowing other nobody can change your part of the transaction but allowing other
signers to change their part of the transaction. The corresponding signers to change their part of the transaction. The corresponding
output must exist or the value "1" will be signed, breaking the security output must exist or the value "1" will be signed, breaking the security
scheme. 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: 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 this one input, and it also allows anyone to add or remove other
inputs, so anyone can contribute additional satoshis but they cannot inputs, so anyone can contribute additional satoshis but they cannot
change how many satoshis are sent nor where they go. 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 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. 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 one corresponding output, but it also allows anyone to add or remove
other inputs. other inputs.
@ -565,7 +564,7 @@ hash types sign, including the procedure for inserting the subscript -->
{% autocrossref %} {% 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.) (Called nLockTime in the Bitcoin Core source code.)
The locktime indicates the earliest time a transaction can be added to The locktime indicates the earliest time a transaction can be added to
the block chain. the block chain.
@ -592,7 +591,7 @@ Previous versions of Bitcoin Core provided a feature which prevented
transaction signers from using the method described above to cancel a transaction signers from using the method described above to cancel a
time-locked transaction, but a necessary part of this feature was 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 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 multiple signers to agree to update a transaction; when they finished
updating the transaction, they could agree to set every input's updating the transaction, they could agree to set every input's
sequence number to the four-byte unsigned maximum (0xffffffff), sequence number to the four-byte unsigned maximum (0xffffffff),
@ -626,20 +625,20 @@ enable locktime.
Transactions typically pay transaction fees based on the total byte size Transactions typically pay transaction fees based on the total byte size
of the signed transaction. The transaction fee is given to the 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 ultimately up to each miner to choose the minimum transaction fee they
will accept. will accept.
<!-- TODO: check: 50 KB or 50 KiB? Not that transactors care... --> <!-- TODO: check: 50 KB or 50 KiB? Not that transactors care... -->
By default, miners reserve 50 KB of each block for [high-priority 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 time. The remaining space in each block is typically allocated to transactions
based on their fee per byte, with higher-paying transactions being added based on their fee per byte, with higher-paying transactions being added
in sequence until all of the available space is filled. 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 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 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 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] in a block to include it. Please see the [verifying payment section][section verifying payment]
@ -651,7 +650,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, people will have UTXOs that exactly match the amount they want to pay,
so most transactions include a change output. 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 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 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 described in the [next subsection](#avoiding-key-reuse), it is highly recommended that change
@ -720,7 +719,7 @@ fixed URI to which payments should be sent, please see the
None of Bitcoin's signature hash types protect the signature script, leaving None of Bitcoin's signature hash types protect the signature script, leaving
the door open for a limited denial of service attack called [transaction 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 contains the secp256k1 signature, which can't sign itself, allowing attackers to
make non-functional modifications to a transaction without rendering it make non-functional modifications to a transaction without rendering it
invalid. For example, an attacker can add some data to the signature script 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 %} {% 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. 1. Take a private key.
@ -403,7 +403,7 @@ For consistent word ordering:
{% autocrossref %} {% autocrossref %}
The hierarchical deterministic key creation and transfer protocol ([HD 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 backups, eliminates the need for repeated communication between multiple
programs using the same wallet, permits creation of child accounts which programs using the same wallet, permits creation of child accounts which
can operate independently, gives each parent account the ability to can operate independently, gives each parent account the ability to
@ -424,9 +424,8 @@ point (the public key):
{% autocrossref %} {% autocrossref %}
Because of the way `point()` functions, it's possible to create a [child Because of the way `point()` functions, it's possible to create a [child
public key][]{:#term-child-public-key}{:.term} by combining an public key][/en/glossary/child-key]{:#term-child-public-key}{:.term} by combining an
existing [(parent) public key][parent public existing [(parent) public key][/en/glossary/parent-key]{:#term-parent-public-key}{:.term} with another public key created from any
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 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 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 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 %} {% autocrossref %}
This means that two or more independent programs which agree on a 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 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][]{:#term-parent-key}{:.term} pair without any further communication. 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 Moreover, the program which distributes new public keys for receiving
payment can do so without any access to the private keys, allowing the 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 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 child, grandchild, and other descended keys with unlinkable
deterministically-generated integer values. Each child key also gets deterministically-generated integer values. Each child key also gets
a deterministically-generated seed from its parent, called a [chain 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 code doesn't necessary compromise the integer sequence for the whole
hierarchy, allowing the [master chain 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 even if, for example, a web-based public key distribution program
gets hacked. gets hacked.
@ -480,10 +479,10 @@ gets hacked.
As illustrated above, HD key derivation takes four inputs<!--noref-->: 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. *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. bits of seemingly-random data.
* The [index][key index]{:#term-key-index}{:.term} number is a 32-bit integer specified by the program. * 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 Because creating child keys requires both a key and a chain code, the
key and chain code together are called the [extended key and chain code together are called the [extended
key][]{:#term-extended-key}{:.term}. An [extended private key][/en/glossary/extended-key]{:#term-extended-key}{:.term}. An [extended private
key][]{:#term-extended-private-key}{:.term} and its corresponding key][/en/glossary/extended-key]{:#term-extended-private-key}{:.term} and its corresponding
[extended public key][]{:#term-extended-public-key}{:.term} have the [extended public key][/en/glossary/extended-key]{:#term-extended-public-key}{:.term} have the
same chain code. The (top-level parent) [master private 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, code are derived from random data,
as illustrated below. as illustrated below.
![Creating A Root Extended Key Pair](/img/dev/en-hd-root-keys.svg) ![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 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 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 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. keys can't create hardened child public keys.
Because of that, a [hardened extended private 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, useful than a normal extended private key---however,
hardened extended private keys create a firewall through which hardened extended private keys create a firewall through which
multi-level key derivation compromises cannot happen. Because hardened multi-level key derivation compromises cannot happen. Because hardened

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

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

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

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

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

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

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

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

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

@ -48,7 +48,7 @@ The `getchaintips` RPC {{summary_getChainTips}}
- n: "→ →<br>`status`" - n: "→ →<br>`status`"
t: "string" t: "string"
p: "Required<br>(exactly 1)" 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 %} {% 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 | 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 | [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. | 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 | 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. | 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 %} {% 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 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 this block, but first the TXIDs are placed in order as required by the
consensus rules: 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. below are counted towards the serialized size.
| Bytes | Name | Data Type | Description | 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* | 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. | *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 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. 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 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.) once every four years. As of November 2014, it's 25 bitcoins.)
Together, the transaction fees and block subsidy are called the [block 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 invalid if it tries to spend more value than is available from the
block reward. 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 This section describes the Bitcoin P2P network protocol (but it is [not a
specification][]). It does not describe the discontinued direct [IP-to-IP 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 [GetBlockTemplate mining protocol][section getblocktemplate], or any
network protocol never implemented in an official version of Bitcoin Core. 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 The following constants and defaults are taken from Bitcoin Core's
[chainparams.cpp][core chainparams.cpp] source code file. [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 | Mainnet | 8333 | 0xf9beb4d9 | 0x1d00ffff
| Testnet | 18333 | 0x0b110907 | 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) ![Overview Of P2P Protocol Data Request And Reply Messages](/img/dev/en-p2p-data-messages.svg)
Many of the data messages use 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 for transactions and blocks. Inventories have a simple 36-byte
structure: structure:
@ -147,7 +147,7 @@ one of these unknown types.
{% autocrossref %} {% autocrossref %}
The `block` message transmits a single serialized block in the format 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 See that section for an example hexdump. It can be sent for two
different reasons: different reasons:
@ -272,7 +272,7 @@ previously requested certain headers with a `getheaders` message.
| Bytes | Name | Data Type | Description | 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* | 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 The following annotated hexdump shows a `headers` message. (The message
header has been omitted.) header has been omitted.)
@ -375,7 +375,7 @@ be complete:
being processed by the filter. being processed by the filter.
There is no payload in a `mempool` message. See the [message header 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 %} {% endautocrossref %}
@ -401,7 +401,7 @@ proof of work.
| Bytes | Name | Data Type | Description | 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). | 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* | 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. | *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. transactions it originates.
For an example hexdump of the raw transaction format, see the [raw For an example hexdump of the raw transaction format, see the [raw
transaction section][raw format]. transaction section][raw transaction format].
{% endautocrossref %} {% endautocrossref %}
@ -845,7 +845,7 @@ replacement filter is loaded with `filterload`. It also doesn't require
a `filterload` message before a `filterclear` message. a `filterload` message before a `filterclear` message.
There is no payload in a `filterclear` message. See the [message header 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 %} {% endautocrossref %}
@ -1100,7 +1100,7 @@ database of available nodes rather than waiting for unsolicited `addr`
messages to arrive over time. messages to arrive over time.
There is no payload in a `getaddr` message. See the [message header 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 %} {% endautocrossref %}
@ -1218,7 +1218,7 @@ The `verack` message acknowledges a previously-received `version`
message, informing the connecting node that it can begin to send message, informing the connecting node that it can begin to send
other messages. The `verack` message has no payload; for an example other messages. The `verack` message has no payload; for an example
of a message with no payload, see the [message headers of a message with no payload, see the [message headers
section][message header]. section][section message header].
{% endautocrossref %} {% 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 4. Append the checksum to the version and hash, and encode it as a base58
string: <!--[-->`BASE58(version . hash . checksum)`<!--]--> 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 Nolan provided the following example encoding algorithm to the Bitcoin
Wiki [Base58Check Wiki [Base58Check
encoding](https://en.bitcoin.it/wiki/Base58Check_encoding) page under 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 %} {% autocrossref %}
Bitcoin transactions are broadcast between peers 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 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 the TXID and, ultimately, the merkle root of a block containing the
transaction---making the transaction format part of the consensus rules. 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 A transaction may have multiple inputs and outputs, so the txIn and
txOut structures may recur within a transaction. CompactSize unsigned txOut structures may recur within a transaction. CompactSize unsigned
integers are a form of variable-length integers; they are described in 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 %} {% 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. | 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* | 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][]. | *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 %} {% 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. | 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. | 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* | 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* (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][]{:#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. | *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; see [sequence number][]. | 4 | sequence | uint32_t | Sequence number.
Most (but not all) blocks prior to block height 227,836 used block 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 version 1 which did not require the height parameter to be prefixed to