3 minute read
PRESS RELEASE: July 27, 2019 — Profit Hunters Coin
An in-depth look into the “consensus” source code found in the most recent version of Bitcoin reveals limited dynamic consensus among peers.
As previously discussed this in the article: The Difference Between General And Specific Consensus In Bitcoin In summary, nodes lack secondary checks to verify their current chain validity without the use of Dynamic Checkpoints and Chain Buddy classes with assistance from Block Shield in cooperation with Chain Shield.
Dynamic Checkpoints have been implemented into PHC as a foundation for the new peer to peer consensus upgrade. Static checkpoints used in the past are only effective after a scheduled hard fork to ensure network integrity.
During attack attempts or normal chain splits (shallow chain re-organizations), nodes sometimes get stuck on the wrong chain. This simple, yet required validation source code was never developed into Bitcoin in the past.
Nodes running version PHC 188.8.131.52 on the Test-net will automatically send their nBestHeight and nBestChainHash to all active & connected peers in one minute intervals. This soft-fork upgrade is also scheduled at a undefined future time on the Main-net.
These most recently received checkpoint from nodes automatically gets recorded into the altered CNode class and can be queried with CNodeStateStats class within the source code.
Nodes stats are collected on an interval of every 5 blocks in a ConsensusCheckpointMap containing Node IP, Timestamp, Hash, Height information in a sequential list, with a maximum amount of entries of 50.
The ConsensusCheckpointMap is evaluated using the ChainBuddy::FindConsensus() function and queried using ChainBuddy::WalletHasConsensus() function to return a TRUE or FALSE value.
Further protection can be used in conjunction with Chain Shield to halt local block creation until the network nodes have reached a majority consensus.
ChainShield::Protect() is called to evaluate network consensus compared to the local wallet block-chain state. If any discrepancies are found while Chain Buddy halts any further chain splitting; The local wallet will “roll back” their block-chain 5 blocks and re-sync to the network to receive the most valid chain split/fork from the majority of peers connected.
This can also be useful during a double-spend attack, as live-monitoring can detect non-consensus among the peers automatically and rejoin the proper chain without massive disruption or loss of funds.
Dynamic Coin Distribution
DynamicCoinDistribution::ASIC_Choker() function uses the external Block Shield function to prevent time-warp mining, block time-spans with massive discrepancies from the expected target time, or malicious timestamp attacks.
All new blocks accepted from nodes are collected within a new class called PeerBlockIndexMap with essential information about the node and new block (Height, Timestamp, Node IP Address, PoW/PoS).
This is later evaluated every 10 new accepted blocks, using DynamicCoinDistribution::Adjust(int nHeight) function that will ensure all accepted blocks follow new strict decentralized coin distribution rules.
Regardless, if a small or large amount of mining nodes are on the network; They automatically adjust Min_DistributionPercent, Max_DistributionPercent, Min_StakePercent, and Max_StakePercent. These are dynamic similar to the difficulty function to ensure the same amount of Proof of Work vs. Proof of Stake blocks in 100 blocks are a limited, and balanced with a limited percentage of blocks validated from individual nodes.
This will ensure CPU mining stays profitable on the PHC network, during the entire block-chain's lifetime. The old security model of: The chain with the most hash power wins is obsolete! The most valid, peer to peer consensus chain wins, or at least should…
Take a look at the source code here: