dash-docs/_includes/ref_block_chain.md
David A. Harding 6afc6835bf
Use Terms "Pubkey Script" And "Signature Script"
This modifies commits provided by @petertodd to use the terms "pubkey
script" and "signature script" instead of other terms.

* Rename "scriptPubKey" and "output script" to "pubkey script"
  (suggested by @luke-jr). We leave a token "scriptPubKey" at the point
  where we define pubkey script so that searchers can find it.

* Rename "scriptSig" to "signature script" (suggested by @luke-jr). We
  also leave a token "scriptSig" at this definition point.

* Rename "redeemScript" to "redeem script"

* Defined ECDSA on secp256k1 curve as the crypto used in the Transaction
  section and added references to secp256k1 private/public keys and
  signatures.

* Removed "The Parts Of A Transaction" illustration by commenting it out
  in the HTML. Shoehorning the pubkey/signature script terms into this
  image was becoming difficult, and I'm not very fond of that
  illustration anyway. I'll see if I can think of a nicer replacement
  illustration for some point in the future.

* Add a short paraphrased version @petertodd's description of scripts as
  generalized crypto.

* Updated all the illustrations which referred to either pubkey scripts
  or signature scripts to use these terms.
2014-09-20 15:07:42 -04:00

95 lines
4.4 KiB
Markdown

## Block Chain
The following subsections briefly document core block details.
### Block Contents
{% autocrossref %}
This section describes [version 2 blocks][v2 block]{:#term-v2-block}{:.term}, which are any blocks with a
block height greater than 227,835. (Version 1 and version 2 blocks were
intermingled for some time before that point.) Future block versions may
break compatibility with the information in this section. You can determine
the version of any block by checking its `version` field using
bitcoind RPC calls.
As of version 2 blocks, each block consists of four root elements:
1. A [magic number][block header magic]{:#term-block-header-magic}{:.term} (0xd9b4bef9).
2. A 4-byte unsigned integer indicating how many bytes follow until the
end of the block. Although this field would suggest maximum block
sizes of 4 GiB, max block size is currently capped at 1 MiB and the
default max block size (used by most miners) is 350 KiB (although
this will likely increase over time).
3. An 80-byte block header described in the section below.
4. One or more transactions.
The first transaction in a block must be a [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
receive a [block reward][]{:#term-block-reward}{:.term} of newly created bitcoin value, which also
should be spent in the coinbase transaction. (The block reward started
at 50 bitcoins and is being halved every 210,000 blocks---approximately once every four years. As of
June 2014, it's 25 bitcoins.) A coinbase transaction is invalid if it
tries to spend more value than is available from the transaction
fees and block reward.
The coinbase transaction has the same basic format as any other
transaction, but it references a single non-existent UTXO and a special
[coinbase field][]{:#term-coinbase-field}{:.term} replaces the field that would normally hold a signature script and
secp256k1 signature. In version 2 blocks, the coinbase parameter must begin with
the current block's block height and may contain additional arbitrary
data or a script up to a maximum total of 100 bytes.
{% endautocrossref %}
### Block Header
{% autocrossref %}
The 80-byte block header contains the following six fields:
| Field | Bytes | Format |
|-------------------|--------|--------------------------------|
| 1. Version | 4 | Unsigned Int |
| 2. hashPrevBlock | 32 | Unsigned Int (SHA256 Hash) |
| 3. hashMerkleRoot | 32 | Unsigned Int (SHA256 Hash) |
| 4. Time | 4 | Unsigned Int (Epoch Time) |
| 5. Bits | 4 | Internal Bitcoin Target Format |
| 6. Nonce | 4 | (Arbitrary Data) |
1. The *[block version][]{:#term-block-version}{:.term}* number indicates which set of block validation rules
to follow so Bitcoin Core developers can add features or
fix bugs. As of block height 227,836, all blocks use version number
2.
2. The *hash of the previous block header* puts this block on the
block chain and ensures no previous block can be changed without also
changing this block's header.
3. The *Merkle root* is a hash derived from hashes of all the
transactions included in this block. It ensures no transactions can
be modified in this block without changing the block header hash.
4. The *[block time][]{:#term-block-time}{:.term}* is the approximate time when this block was created in
Unix Epoch time format (number of seconds elapsed since
1970-01-01T00:00 UTC). The time value must be greater than the
median time of the previous 11 blocks. No peer will accept a block with a
time currently more than two hours in the future according to the
peer's clock.
5. *Bits* translates into the target threshold value---the maximum allowed
value for this block's hash. The bits value must match the network
difficulty at the time the block was mined.
6. The *[header nonce][]{:#term-header-nonce}{:.term}* is an arbitrary input that miners can change to test different
hash values for the header until they find a hash value less than or
equal to the target threshold. If all values within the nonce's four
bytes are tested, the time can be updated or the
coinbase transaction can be changed and the Merkle
root updated.
{% endautocrossref %}