By: Rob Andrews
Proof-of-Giving is a flavor of Proof-of-Work geared for a high adoption rate.
It rewards miners who are small, medium, or large by tithe_weight from an internal pool.
The idea is to create an internal pool, assessing miners who tithed to the foundation with tithe_weight, and ultimately rewarding 80% of the block rewards to the pool tithers (called sowers), and 20% to the miner who solved the block (called reapers).
First, the sum of tithes to the orphan foundation wallet is summed over the last 24 hours of blocks.
This miner-public-key-sum is the tithe_weight of each miner.
Miners who are not tithing may still solo mine and attempt to solve any block. If a non-tither solves a block they will receive 20% of the block reward, with 80% going to the pool recipients.
Orphan foundation tithes will be modified to contain the miners signature, so that the sum of orphan tithes over 24 hours for that miner will accumulate giving the miner more accumulated tithe_weight.
To remove the necessity of having a pool, the activity of tithing will automatically 'register' the miners public receiving address and signature for 24 hours. It will be of greater benefit for a miner to send incremental tithes (over the 24 hour period) from the same registered wallet, for a greater tithe_weight (in contrast to sending tithes from separate wallets). As the sum of the amount tithed will result in a greater total miner reward (an approximate 5% tithe_weight bonus is applied linearly to the higher tithe_weights promoting consolidated single wallets).
This algorithm prevents botnets from forming, because rewards are based on individual miner controller wallets and tithe amounts, not based on ramping up hashpower.
The system will constantly use a 205 block lookback, so it will constantly be updated with the most recent 24 hour information (with a 7 block delay).
The statistics for the "round" will be available in the wallet and on the overview, for a nice new UI feature.
The block reaper receives 20% of the reward, with the remaining 80% split with the registered sowers in the pool (by tithe_weight).
How does this system promote easy adoption? A brand new user is able to mine in a plug-n-play environment, with as little as 1 bbp. They boot the wallet, use the defaults, and tithe 1 bbp to the foundation. They are now mining (the controller wallet will be hashing POBH on one thread by default, and the tithe will enter the miner in the pool).
What happens on a day where no one tithes? All tranches will be zero in the breaks table. Therefore anyone can mine on that day.
How does this system reward a very high giver? One may not tithe more than the current block difficulty allows, but the higher the sum of tithes over the last 205 blocks per miner means this miner will have a higher tithe_weight, and when the pool pays the miner, the 80% block reward will be split by tithe_weight and this miner will receive a much higher share (as long as the other miners had given much less).
How does this system root out botnets? The very first requirement to running a botnet is to be rewarded on 1-nth of the machines for POW work (otherwise it would be a useless endeavor). For example, if BiblePay was pure POW, it would be advantageous to run 10 POW machines and collect a random reward on 1 machine. However, since POG is set up to increase your pool rewards based on the SUM of the tithes contributed (IE: three tithes from one wallet create an advantage, as the sum of the tithes is used), this is an advantage over three distinct tithes from 3 wallets.
The miner who reaped the block is given 20% of the block reward and the remaining 80% of the reward is split equally to everyone in the tranche, weighted by the tithe amount. Therefore no pool is required.
Pool mining is replaced with the action of tithing.
PODC is removed, so as to give the entire reward to the POG miners, and to promote 'easy adoption' by new users.
100% of the foundation tithes are used for orphan sponsorships.
The POG algorithm is very green, because miners are rewarded via pool rewards, meaning they do not need to increase hashpower to eventually solve a block.
51% attack resistance Since all mining public keys will be registered in Tithes, it will not be possible to create a standard outsider 51% attack, but instead the attacker will first need to give to the orphan foundation to increase tithe_weight. Then they will need to deal with the normal POW competition, and finally we still have DGW which will increase dramatically if blocks are solved too fast.
EXAMPLE 1: Inbound Tithes Let us assume 5 sowers tithed:
|Sower 1:||Tithed 10|
|Sower 2:||Tithed 20|
|Sower 3:||Tithed 30|
|Sower 4:||Tithed 40|
|Sower 5:||Tithed 50||Total Tithes (6 sowers): 150|
|Sower 1 weight:||07%|
|Sower 2 weight:||13%|
|Sower 3 weight:||20%|
|Sower 4 weight:||27%|
|Sower 5 weight:||33%|
Let us assume Miner 2 reaped the block: (2,000 BBP bonus is reserved for miner 2 (since s/he found the block - this promotes controller wallets to be ON). 8,000 bbp remains for the group.)
|Block Distribution - Reward:|
|Sower 1 reward:||560 bbp|
|Reaper 2 reward:||1040 bbp + 2000 BBP (finding the block)|
|Sower 3 reward:||1600 bbp|
|Sower 4 reward:||2160 bbp|
|Sower 5 reward:||2640 bbp|
|Total: 10000 BBP|
Unlike Proof-of-stake, where the rich get richer, with POG, the ones participating in the tithing round get richer.
Also, this system levels the playing field between powerful machines and small miners by weighting the miner by tithe amount. This is accomplished by giving a higher magnitude of weight by tithe weight (not by hashpower). This system removes the necessity of pools, meaning that no one misses out on solo mining. This simplifies the biblepay infrastructure.
We will also make it so the wallet will have an option to automatically tithe in the future with selectable amount and frequency.
To prevent tithe attacks (IE someone abusing the system for easy entrance to the pool), POG requires a tithed coin to be older than the current round difficulty minimum_coin_age, a coin to be above minimum_coin_amount, and a tithe amount to be less than maximum_tithe_amount.
This makes it impossible to script a tithe attack. This also regulates the maximum monthly tithes accepted by the foundation to be capped at a hard limit preventing dilution. (See POG Difficulty technical details, the maximum accepted tithe amount will be half of the monthly charity budget and will deflate with deflation - this is currently approx 3.2 million BBP monthly).
In this way the foundation will not be selling a massive amount of coins per month but instead the monthly liquidation will be in-line with half of the current charity budget.
It reduces the necessity of a massive infrastructure by removing the heat mining pool, PODC support sites, PODC pools, external programs and external accounts. This theoretically allows us to support an unlimited number of new users (based on a self-learning paradigm from our getting started guide).
POG-Difficulty-Algorithm Technical Details
The purpose of the POG difficulty algorithm is to prevent tithe attacks or exploiting the pool reward system. If it is "too easy" to simply tithe, one gains entry into the pool and receives a certain reward, making it unfair for other BiblePay sowers. With the difficulty system, we only allow one to tithe if the user possesses a coin with an age greater than the difficulty level, and must tithe less than the maximum allowed tithe amount. This way we regulate the maximum accepted monthly tithes and make it fair for anyone with coin-age to tithe (in contrast to POS, where the richest always stake the most blocks with greater rewards per block). We do this by requiring a single aged coin to be used for the actual tithe (in contrast to a minimum coin_amount*age).
The pool will sum the global amount tithed over the last 205 blocks. The pool will also recognize the target maximum. Let us assume the target daily tithe maximum is 100,000 bbp.
The difficulty is calculated by : (Sum_of_tithes / Maximum_daily_tithes) * 65535 This yields a number between .0001 and 65535, with 65535 being a higher difficulty level, and .0001 being the lowest difficulty level.
- The following parameters are adjusted depending on difficulty level: minimum_coin_age, minimum_coin_amount, maximum_tithe_amount
- min_coin_age : 0 - 60 (days)
- min_coin_amount : 1 - 25000
- max_tithe_amount: 300 - 1 (descending)