Proof Of Loyalty

From BiblePay Wiki
Jump to: navigation, search

BiblePay Proof-Of-Loyalty Consensus Algorithm - White Paper

January 19th, 2018

Robert A. (

A crypto-currency consensus algorithm


Biblepay currently uses the Proof-Of-Biblehash algorithm, a proof-of-work algorithm based on the KJV bible to maintain consensus.

Over time, the core client has been installed on a diverse array of machines around the world, possibly in a botnet, leading to certain downsides for the development team. First, the entity has no motivation to upgrade the software and run the latest version, unless forced to do so, meaning that the core community is actually becoming a minority. The next being that the core community is no longer compensated for each block at the level expected. And finally the motivation for deployment of the botnet seems to be based in greed only, meaning that someone is doing this for income and not for long term asset growth.

We propose to enhance the proof-of-biblehash algorithm with an extension called proof-of-loyalty (POL). The POL extension makes PoBh a hybrid algorith, partially Proof-of-Work (POW) and partially Proof-Of-Stake (POS).

Part of the motivation of POL is the ability for the end user to mine on mobile devices (as POL will eventually solo mine a block with enough Coin-Age present). Another is that it is greener than POW, in that the mining advantage is awarded to those with more coin-age, therefore less work needs to be done on a loyal coin owners machine than on a non-loyal (IE low coin age brute forced botnet). And finally, POL rewards loyal investors who supported our charity network with more rewards.

Technical Parameters of Proof-Of-Loyalty

CoinAge: This calculation is fundamental to understanding POL. It is a users UTXO (Unspent coin Amount) Multiplied By the UTXO age (Unspent Coins Age) In days. For example, if a user received 50,000 BBP 60 days ago, and did not spend it, the CoinAge for that unspent coin = 50000 * 60 = 3,000,000 CoinAge.

NetworkWeight: This parameter is the total money supply that has been minted up to the current height. As of Jan 19th, 2018, for BBP this is 359,000,000.

POLStakingTargetAmount: So for example, if you have a balance in your wallet of 1,000,000 unspent and unlocked BBP (remember, Sanctuary funds are locked, they do not count), and you decide you want to stake 10% of that, your POLStakingTargetAmount is 100,000.

UserPOLWeight: This is the total CoinAge that will be staked in your next mined block.

POLTargetModifierPercentage: This percentage is the amount of influence your client has on the next block. It is a whole number between 0-90%. It is calculated by dividing the UserPOLWeight by NetworkWeight (see algorithms).



This algorithm is designed to allow a user who controls 1% of the money supply to stake once per day, on average, with very little hashing. This is the key algorithm that will be tested and adjusted in testnet.

	dTotalMoneySupply = GetMoneySupplyEstimate(nHeight) / COIN
	dStakeTargetModifierPercent = (nWeight / dSupply) * 100;


This algorithm is designed to calculate the total CoinAge chosen by the user (in stake). It is done by iterating through the unspent outputs of the coins in stake, and multiplying the age of the coin (in days) by the amount of the coin. Then the sum of the CoinAge is returned as the StakeWeight for the user, for that block.

Coin age Must be greater than 24 hours to count as an unspent output.

	nAmount = tx.vout[n].nValue;
        nAge = (nChainTipTime - nTime)/(86400+.01);
        if (nAge > 365) nAge = 365;           // If the age > 1 YEAR, cap at 1 YEAR
        if (nAge < 1 && fProd) nAge = 0;      // If the age < 1 DAY, set to zero (coins must be more than 1 day old to stake them)
	nTotalAmount += nAmount;
	double dWeight = nAge * (nAmount/COIN);

HashTargetInfluence: The blocks hash target is influenced by the users StakeTargetModifierPercent. If the STMP is 50 for example, the block will be theoretically 50% easier to solve. This is done the following way:

Before POL:

"hashtarget": "000fffff000000000000000000000000ffffffffffffffffffffffffffffffff"

User has an STMP of 50, due to a stakeweight of 160,000,000.
POL calculates a uint256 base hashtarget:

"basehashtarget": "00000000000000000000000000000000ffffffffffffffffffffffffffffffff"

POL Modifies Block Hash Target:

"adjustedhashtarget": "00feeeee000000000000000000000001ffffffffffffffffffffffffffffffff"

Therefore, now that the hash target has been Raised higher by 50%, it is easier for this specific user to mine the current block (with this amount in stake).


To give the system integrity, we must prove the stake age is accurate on foreign nodes doing block checking. During CreateBlock, the user will keep a list of all UTXOs they are placing in stake. They will spend them to themselves in one transaction. This transaction will always be transaction #1 in POL, and it will be designated as a proof-of-loyalty transaction. The staking node will sign the block with one signature per output proving they had authority to spend the coins to themself. When a node performs the integrity check of the POL transaction, it will loop through each spent output of the transaction, pull the destination address, and verify the recipient had authority to spend the coins to itself by searching for a signature in the block (not in the transaction), finding the security message, and verifying the signature. The signature must match on every output in order for the node to calculate TotalStakeWeight on the transaction. If the signature fails on any output, StakeWeight is set to zero (meaning no hash target influence will be awarded on that block). If the signature passes on every output, StakeWeight is calculated by using the above GetStakeWeight calculation on the UTXO inputs.

Replay Attacks

To prevent replay attacks, the POL staker will salt the signature message with random characters so that no signature can be reused in the future in POL, regardless of stakeweight or recipient address.


To use the system, set the key "polpercentage" in the config file with a whole number between 00 and 100. Where 0 means the feature is disabled, and 50 means the POL system will attempt to use 50% of your unspent, unlocked, available balance in staking operations.


Note that if the POL system is unable to allocate funds for the stake due to a locked wallet, it will exit and the miner will revert to POW mining.


Some common attack scenarios and commentary.

Why cant I just buy 50 Million BBP and use it over and over for the biggest advantage over all users? The answer is in understanding coin age. First, you can only stake a coin that is over 24 hours in coin age. So once a coin is staked, it is used up for a minimum of one day. Next, your CoinAge is calculated by multiplying the fractional age in days by the amount. So a person with 50 million that is 1 day old only has a fractional stake weight until they wait for the age to accrue again.

Do I receive an advantage for running 10 PCs with cloned wallets, and staking greedily, IE stake with only 5000 coins per wallet, in contrast to staking on one PC with the full 50,000 balance at once? The stakeweight is proportional to the amount staked, and that drives a proportional amount of hash target influence. So it will be 10* easier to solve a block if you stake the whole balance at once. The free market will influence this algorithm to make it so that there is very little to no advantage of splitting the stake as in reality, diff will be higher and POW rewards per watt will be lower.

Can I fund a sanctuary with the output of a coinstake? No, coinstake can not be used to fund a sanctuary.

Can a botnet share a wallet and get back their advantage by staking from a shared wallet across 1000 PCs? No. When one single PC of the 1000 solves one block, the coins used from the shared wallet that were in-stake are now spent and have zero coin age. All 999 other nodes will now lose the POL advantage immediately. POL levels the playing field by requiring a distinct individual coin to be used for an advantage on one mined block at a time. This should theoretically reduce the effectiveness of a botnet down to the relative level of their total BBP wallet balance as compared to any normal users wallet balance. Meaning that a botnet with 1000PCs and a 100K bbp balance is very close in equality to a single user with ONE PC and a 100K bbp balance. Yes, they have a hash advantage, but because of the POL effect that hits BBP, general difficulty for the POW side will increase while the reward component (IE coins earned per brute-force watt will decrease), meaning that the playing field will be more relative to balances in stake.

Pool Effects

The open source pool (one being, currently allows POW miners to concentrate POW hashpower into the pool, and the pool distributed the mining rewards over the pool accounts (by fractional shares solved).

Since it would be detrimental (from a botnet security perspective) to program the core to hold back POL stakes from the pool, primarily because that raises the difficulty of the pool participants and helps the botnet achieve hashpower parity with the pool, it is strongly advised to reward the users when they include POL stakes in their pool mined block templates (IE they enable POL during pool mining). This way, as a group, the pools total difficulty will be lower, and the botnet (IE ones in outer darkness) their difficulty will be much higher.

In light of this, the pool will need to be modified to pay a BONUS to the miner who finds the block with the BONUS being proportionate to the amount staked in the block. In this way, miners who stake very little to nothing in the block will receive little or no bonus, but those helping the pool as a group will receive very high bonuses (BONUS TBD, with its amount being relative to how much they helped the pool solve the block).