Merge pull request #7 from dashpay/UdjinM6-patch-1-1

fix bit1 hex representation/description
This commit is contained in:
UdjinM6 2017-11-15 16:45:54 +03:00 committed by GitHub
commit 9c4c7758c9
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -50,9 +50,8 @@ It removes the need for users to trust in Dashs proposal system.
## Conventions
* `0x20000000` is the bit sequence `00100000000000000000000000000000` and is the current version of dash blocks.
* `0x20000001` is the version used to signal acceptance of a consensus change rule.
* `0x20000002` is the version used to signal acceptance of a consensus change rule.
A miner should use this version to signal acceptance of the miner and the masternode for the block of a consensus rule change.
* We let `bit1` be the last bit of the version number read left to right. We interpret this as an integer which is either 0 or 1.
* We use `%` as it is used in C++. It is the remainder on division. So `7 % 3` is 7 modulo 3 and is equal to 1.
## Prior Work
@ -102,7 +101,7 @@ However, checking if a transaction is in the mempool might take as long as verif
To ensure a coherent network roll-out we employ BIP9 signaling adjusted for Dash.
We reserve the last bit in the version to signal for DIP1 activation.
A DIP0001 enabled miner will broadcast block version `0x20000001` only if the masternode selected for that block is also DIP1 enabled.
A DIP0001 enabled miner will broadcast block version `0x20000002` only if the masternode selected for that block is also DIP1 enabled.
We model the 2016 block difficulty adjustment period in BIP9 with a 4032 block round.
This length of a round should allow for a representative sample of masternodes to be taken.