About CNBTC build
We recommend building the binary files of Chinese Bitcoin on any modern Linux x64 distribution. Instructions:
apt install git build-essential libtool autotools-dev automake pkg-config bsdmainutils python3
git clone https://github.com/nationalbitcoin/africanbitcoin/
cd depends && make && cd ..
./autogen.sh
CONFIG_SITE=$PWD/depends/x86_64-/share/config.site ./configure --prefix=/
Make
Instead of "platform name" replace it with the name of your platform.
The block reward calculation algorithm
The main part of the block reward is calculated according to the formula 12.5 >> (n / 100000), where n is the number of blocks in the chain, >> denotes bit shift, and / denotes integer division. To generate a proof-of-stake block, miners must find a transaction output in their wallet that satisfies the following condition:
hash(nStakeModifier + blockFrom.nTime + txPrev.vout.hash + txPrev.vout.n + nTime) < bnTarget * nWeight
The plus sign (+) denotes concatenation of values serialized as a byte vector.
Hashable parameters:
nStakeModifier is a modifier calculated using accumulated entropy. It is designed to eliminate the possibility of calculating hashes for outputs that have not yet received enough confirmations.
The modifier is calculated using hashes of previous block headers.
blockFrom.nTime - the time of creation of the block in which the input was confirmed. txPrev.vout.hash - the hash of the transaction in which the output was created.
txPrev.vout.n is the index of the output in the transaction referenced by txPrev.vout.hash.
The nTime is the current Unix timestamp.
These parameters are used precisely because the source of their origin is transparent and available for verification to anyone interested. For example, it is not possible to use the hash of the block or the hash of the transaction being created, as this would lead to a degeneration of the system into a proof-of-work scenario.
So, the right part of the inequality is the product of the current target (which can be calculated as the maximum target divided by the current difficulty) and the output weight. The weight is determined as the product of the output value in satoshis and its age in seconds.
Additional requirements:
The transaction must have at least 25 confirmations before it can be used for finding solutions. The output can contain P2PK, P2PKH or P2CS scripts. Any other outputs are not suitable and are ignored by the client when searching for solutions. If the miner is looking for solutions himself, the reward is divided proportionally between him and 10 randomly selected consensus participants. This is done for a more fair distribution of rewards and additional incentives to participate. Rewards found using P2CS outputs are not shared with anyone and belong entirely to the finder of the block.
In addition to proof-of-stake, a proof-of-authority mechanism is provided as a backup option.
PoA blocks are created centrally and have a fixed weight of one. The proof-of-authority mechanism is necessary in the early stages of network deployment when there are not enough users with wallets containing inputs that meet the proof-of-stake criteria. In the future, it will be possible to get rid of it. To protect network participants from abuses, in case of competition between PoA and PoS, the PoS block always wins. This happens because for PoS blocks, their staking contribution is added to the total chain work, while for PoA, a constant equal to one is added. For this reason, any PoS block can beat a chain consisting of millions of PoA blocks.
In other words, PoA is not a security provider in itself, and this role belongs entirely to the owners of coins participating in the proof-of-stake consensus.v
