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

Update Block Chain reference (Headers)

Browse source 
- Update version details
 - Update block reward info
This commit is contained in:
thephez 2017-09-13 12:56:50 -04:00
parent 466169438b
commit c0e4fcca8c
2 changed files with 28 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

47
_includes/devdoc/ref_block_chain.md
View file

@ -15,7 +15,7 @@ The following subsections briefly document core block details.
{% autocrossref %}
Block headers are serialized in the 80-byte format described below and then
hashed as part of Bitcoin's proof-of-work algorithm, making the
hashed as part of the proof-of-work algorithm, making the
serialized header format part of the consensus rules.
| Bytes | Name | Data Type | Description
@ -66,8 +66,6 @@ fe9f0864 ........................... Nonce
height in coinbase at block height 224,412 (March 2013) and began to
reject new version 1 blocks three weeks later at block height 227,930.
-->
<!-- source for heights: my (@harding) own headers dump and counting
script -->
* **Version 3** blocks were introduced in Dash Core 0.11.2 (March 2015) as a
soft fork (Block 244,834 was the first version 3 block).
@ -87,7 +85,6 @@ fe9f0864 ........................... Nonce
* **Version 536870912** blocks were introduced in Dash Core 0.??? ( 2017).
-->
The mechanism used for the version 2, 3, and 4 upgrades is commonly
called IsSuperMajority() after the function added to Dash Core to
manage those soft forking changes. See BIP34 for a full description of
@ -171,10 +168,10 @@ you might parse a decimal number in base-10 scientific notation:
![Quickly Converting nBits](/img/dev/en-nbits-quick-parse.svg)
<!-- Source for paragraph below: Bitcoin Core src/tests/bignum_tests.cpp:
num.SetCompact(0x04923456);
BOOST_CHECK_EQUAL(num.GetHex(), "-12345600");
BOOST_CHECK_EQUAL(num.GetCompact(), 0x04923456U);
<!-- Source for paragraph below: Dash Core src/tests/arith_uint256_tests.cpp:
num.SetCompact(0x04923456, &fNegative, &fOverflow);
BOOST_CHECK_EQUAL(num.GetHex(), "0000000000000000000000000000000000000000000000000000000012345600");
BOOST_CHECK_EQUAL(num.GetCompact(true), 0x04923456U);
-->
Although the target threshold should be an unsigned integer, the
@ -182,20 +179,20 @@ original nBits implementation inherits properties from a signed data
class, allowing the target threshold to be negative if the high bit of
the significand is set. This is useless---the header hash is
treated as an unsigned number, so it can never be equal to or lower than a
negative target threshold. Bitcoin Core deals with this in two ways:
negative target threshold. Dash Core deals with this in two ways:
<!-- source for "Bitcoin Core converts..." src/main.h GetBlockWork() -->
<!-- source for "Dash Core converts..." src/pow.cpp GetBlockProof() -->
* When parsing nBits, Bitcoin Core converts a negative target
* When parsing nBits, Dash Core converts a negative target
threshold into a target of zero, which the header hash can equal (in
theory, at least).
* When creating a value for nBits, Bitcoin Core checks to see if it will
* When creating a value for nBits, Dash Core checks to see if it will
produce an nBits which will be interpreted as negative; if so, it
divides the significand by 256 and increases the exponent by 1 to
produce the same number with a different encoding.
Some examples taken from the Bitcoin Core test cases:
Some examples taken from the Dash Core test cases:
| nBits | Target | Notes
|------------|------------------|----------------
@ -207,7 +204,7 @@ Some examples taken from the Bitcoin Core test cases:
| 0x04123456 | &nbsp;0x12345600 | Inverse of above; no high bit.
Difficulty 1, the minimum allowed difficulty, is represented on mainnet
and the current testnet by the nBits value 0x1d00ffff. Regtest mode uses
and the current testnet by the nBits value 0x1e0ffff0. Regtest mode uses
a different difficulty 1 value---0x207fffff, the highest possible value
below uint32_max which can be encoded; this allows near-instant building
of blocks in regtest mode.
@ -233,16 +230,26 @@ The first transaction in a block must be a [coinbase
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
receive a block subsidy of newly created bitcoin value, which also
should be spent in the coinbase transaction. (The block subsidy started
at 50 bitcoins and is being halved every 210,000 blocks---approximately
once every four years. As of November 2014, it's 25 bitcoins.)
Until the coin limit (~18 million Dash) is hit, all blocks are entitled to
receive a block subsidy of newly created Dash value. The newly created value
should be spent in the coinbase transaction.
The block subsidy declines by ~7.1% per year until all Dash is mined.
Subsidy calculations are performed by the Dash Core [GetBlockSubsidy()][block subsidy]
function.
Together, the transaction fees and block subsidy are called the [block
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.
{% endautocrossref %}
The block reward is divided into three parts: Miners, Masternodes, and
Superblocks.
| Payee | Subsidy | Description |
| ----- | -------- | ----------- |
| Miner | 45% | Payment for mining
| Masternode | 45% | Payment for masternode services (PrivateSend, InstantSend, Governance, etc.)
| Superblock | 10% | Payment for maintenance/expansion of the ecosystem (Core development, marketing, integration, etc.)
{% endautocrossref %}