mirror of
https://github.com/seigler/dash-docs
synced 2025-07-27 09:46:12 +00:00
Fix links for new glossary entries
This commit is contained in:
David A. Harding
parent
494dfaced7
commit
801ea9f4ad
16 changed files with 112 additions and 117 deletions
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
|||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
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}.
|
||||
|
||||
|
||||
|
||||
|
|
@ -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}.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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 %}
|
||||
|
||||
|
|
|
|||
|
|
@ -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 %}
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -33,8 +33,8 @@ about coinbase transactions in the block chain section of this guide.
|
|||
|
||||
|
||||
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
|
||||
|
|
@ -264,10 +263,10 @@ pubkey scripts are less convenient than short Bitcoin addresses and more
|
|||
difficult to secure than P2PKH pubkey hashes.
|
||||
|
||||
To solve these problems, pay-to-script-hash
|
||||
([P2SH][]{:#term-p2sh}{:.term}) transactions were created in 2012 to let
|
||||
a spender create 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
|
||||
|
|
@ -410,7 +409,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.
|
||||
|
|
@ -428,7 +427,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.)
|
||||
|
|
@ -509,36 +508,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.
|
||||
|
||||
|
|
@ -565,7 +564,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.
|
||||
|
|
@ -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
|
||||
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),
|
||||
|
|
@ -626,20 +625,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]
|
||||
|
|
@ -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,
|
||||
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
|
||||
|
|
@ -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
|
||||
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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -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 %}
|
||||
|
|
|
|||
|
|
@ -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 %}
|
||||
|
|
|
|||
|
|
@ -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 %}
|
||||
|
|
|
|||
|
|
@ -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 %}
|
||||
|
|
|
|||
|
|
@ -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 %}
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
|||
|
||||
|
||||
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 %}
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue