PROOF OF BIBLE HASH (POBH)
Proof of Work has been replaced with Proof Of Bible Hash (POBH) – a cpu-only algorithm that allows the program to run on common commodity PCs and compensates full nodes participation. This means BiblePay subsidizes full nodes that stay online. At the same time, it requires full blockchain transaction referencing in the hashing function, along with chained bible verses that make it resistant to porting to GPU video cards and ASICs.
In addition to the low energy requirements and high efficiency of POBH, the reward per block is set to be relative to the length of time the block took to solve. This means that abusive hash attacks result in subsidy decreases.
The wallet uses the X11 blockhash to maintain the reference pointers for the blockindex map. However, it uses the Bible Hash to regulate difficulty and prove that a full node generated the Bible Hash (by requiring a txindex lookup, a block hash, or a receiving address to be present in the suffix of the hash). In greater detail, see the below points on POBH:
- The BibleHash function is fed an input X11 hash of the current block template at a point in time. This starts as a uint256. It is also fed the reference to the last block index (and previous height and previous block time).
- The BibleHash function encrypts the x11 hash uint256 using AES512 into a ciphertext vector. This ciphertext vector is then converted to base64. (These functions were chosen to raise the bar to reduce the likelihood of porting the hasher to a GPU as AES512 requires the OpenSSL library).
- The resulting base64 is then md5 hashed.
- The md5 hash is 32 bytes long. The BibleHash function breaks the md5 hash into 8 octets of 4 bytes each. For each 4-byte octet, the hex is multiplied * the IVerseFactor (.4745708). This IVerse factor points to the corresponding KJV Bible verse between 031101. This resulting verse is chained to the output and this process repeats for octets #2-8, while appending the verses to the chained verse output.
- When the BibleHash function reaches verse #8, it breaks up the source four byte octet into four elements: a Hex 2 byte source resulting in a lookback block offset from 0-255, a hex one byte source resulting in a transaction offset of 0-15, a hex one byte source resulting in a transaction output offset of 0-15, and a one byte source resulting in a datatype pointer of 1-3 (by multiplying 0-15*.1875) (used to determine if this bible verse will need to reference a blockhash, transaction ID or a receiving address). Then the BibleHash calls out to the full node for the resulting DataType from the chain by reading the disk, retrieving the result, and appending the result to the final chained bible verse (verse #8).
- Then the resulting chained verses text contents are MD5 hashed to provide a concise input to the X11 hasher.
- The MD5 hash is X11 hashed.
- The X11 hash is sent through a business logic filter requiring the full node business logic of the latest Mandatory version of BiblePay (IE some business logic from the wallet adjusts the resulting hash depending on block number).
- Next, if the block is older than the late block threshold, the X11 hash is modified to be easier to solve.
- If the block is a TITHE_MODULUS block, the block is easier to solve.
- The resulting X11 hash is sent out of the function as the hash result.
PROOF OF DISTRIBUTED COMPUTING (PODC)
Biblepay aims to be environmentally conscious: we would like to keep the energy consumed by Bitcoin-like ‘heat mining’ (like our cpu-only PoBH) to a minimum (withouth compromising the network-security of course). So instead of using the majority of our computers clock cycles to solve intrinsically meaningless hashes, we use them to solve difficult computing models involving proteins, helping researchers cure some of the diseases that plague our current world.
The cpu-only PODC-system gives a lot back to the world. We support two projects through BOINC, the Berkley Open Infrastructure for Network Computing. BOINC seeks to use idle computer time to do scientific research. The two projects we support are Rosetta@home which studies proteins and protein folding in the quest to produce cures for major diseases such as cancer, as well as World Community Grid which currently has eight sub-projects. World Community Grid’s sub-projects range from Ebola and Zika virus research to cancer research. Both of these projects began over a decade ago.
To show how far we’ve come, Team BiblePay was founded February 7, 2018 for Rosetta@home and March 29, 2018 for World Community Grid. We have been the number one team in terms of RAC (Recent Average Credit, a measure of recent work performed) since March 23, which means in 44 days, many of which we were only in testing, we became the biggest daily contributor at a project that was over a decade old. We account for nearly 20% of the work done there.
Most coins that attempt this type of consensus end up with some systemic problems that hamper their growth. It is BiblePays desire to address all of these and overcome them, and use proof-of-distributed-computing as our primary consensus algorithm so that we may perform a useful function in exchange for the dormant clock cycles on our users machines.
PODC works by aligning the BiblePay miners to one or more distributed computing projects that are aligned to BiblePay’s mission. After creating a Cross-Project-Identifier (CPID), miners add the CPID to their controller wallet, and then associate to one or more devices running the BOINC software package.
Becoming linked to the BiblePay team in each approved project allows for the BOINC Recent-Average-Credit (RAC) to be utilized as the basis for a staking requirement. When the miner puts up a sufficient stake balance of BBP to cover the requirement for the BOINC RAC, they are added to the daily superblock that distributes payment to each successfully staked miner according to their magnitude, or their individual share of the team total. RAC is calculated as a running average over 14 days, so users will also be compensated for historical work once they stop computing, as long as they maintain an accurate stake balance.
In order to have the greatest integrity possible in the PODC consensus system, PODC update transactions are executed periodically based on task completion (and can also be manually triggered, especially when no current distributed computing tasks are running) These update transactions ensure that the stake balance is available and that the data log is complete and accurate, by validating the task start time reported by the controller wallet against the time in the distributed computing source system (e.g. Rosetta@Home or World Community Grid), blocking any SQL credit tampering and ensuring that the signature of the task owner matches the CPID/wallet combination of the reporter, preventing any takeover attacks. Miners who have not completed a task within the configured network time (currently 24 hours) are considered to have a magnitude of 0 and to be ineligible for superblock rewards.
Some projects can have individual project weights adjusted to reflect alternative difficulty/credit calculations – this is applied universally to every member of the BiblePay team in each project. Also, staking requirements, which can be adjusted over time, are not all-or-nothing – partial staking allows for even new users to receive a partial reward from the daily superblock. Users are encouraged to balance their own computing power contributions to their available stake balance to ensure accurate rewards.
In cases of abnormal network activity, a hierarchical approach to disaster recovery has been implemented, ensuring that miner rewards from the superblock are accurately calculated and distributed with the best information possible.
For more information, please see the following wiki’s: