Proof-of-Giving

From BiblePay Wiki
Revision as of 06:49, 6 March 2019 by Sunk818 (talk | contribs) (formatting)
Jump to: navigation, search

By: Rob Andrews

Date: 11-19-2018

Abstract:

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 hash power.

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.

Example of one miner with a tithe of 100 BBP and a different miner with a tithe of 225,000 bbp:Current Round Tithes: 225,100


Miner 1 tithe_weight: .0004%


Miner 2 tithe_weight: 99.96%


The block solver receives 20% of the reward, with the remaining 80% split by Miner 1 & Miner 2.

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 .5 bbp. They boot the wallet, use the defaults, and tithe .50 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? If one gives 50,000 BBP, 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 found 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. Once you have a tithe in, you have a 1/410 chance of receiving a reward every block during the next 24 hour period.

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.

'


GREENNESS


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 Dark Gravity Wave (DGW) which will increase dramatically if blocks are solved too fast.


EXAMPLE 1: REWARD


Let us assume 500 miners tithed:


Inbound Tithes
Miner 1-100: Tithed 10
Miner 101-199: Tithed 20
Miner 200-299: Tithed 30
Miner 300-400: Tithed 40
Miner 401-500: Tithed 50   Total Tithes (500 givers): 15,000  


Let us assume Miner 2 found the block:

REWARD:
Miner weight from 1-100: .0007%
Miner weight from 101-199: .0013%
Miner weight from 200-299: .0020%
Miner weight from 300-400: .0027%
Miner weight from 401-500: .0033%


Block distribution:Since the pool only pays 1/410th of the recipients deterministically, we have only two winners: Miner 150 and miner 450. Therefore there will be 3 recipients in this block (the solver plus two pool recipients). Block subsidy is 10,000 BBP (without PODC, after Sanc was paid).

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.


Total tithes from 150 and 450 = 20+50 = 70, with linear reward: 42.2 + 132.9 = 174 . Tithe_weights for rewards: .241, .7586.

  • Miner 150 Reward: 1928
  • Miner 450 Reward: 6068
  • Miner 2 Reward: 2000

Total: 10000 BBP


Rich-get-Richer


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.


Automatic-Tithing


We will also make it so the wallet will have an option to automatically tithe in the future with selectable amount and frequency.


Gaming the System


To prevent givers from gaming the system, POG makes it impossible to know with certainty that you will be rewarded for giving. The mantra is to give first expecting nothing in return.


Pool rewards are chosen using a deterministic algorithm that gives each recipient a 1 in 410 chance of a tithe being chosen (per block) of being included in the payment structure for that block. Therefore, only the chosen tithes will be included for that block payment and therefore assigned tithe_weight.


In this way, it will take an average of two days of giving regularly (@ 205 blocks per day) to be paid one reward on someof the tithes, with no certainty on which tithes contained tithe_weight. However, each block payment will be based on the chosen tithes only, therefore the payments will be higher. Meaning that givers will not necessarily lose money net while tithing (if the global tithe sum is less than daily block emission), but instead they will not be directly rewarded on a 1:1 tithe->reward relationship.


To prevent the system from being gamed, we will use a strong unpredictable algorithm for tithe assessment by block: Each tithes Address, Amount, Origination Block will be combined with the Payment Block Hash and then hashed, resulting in a non-deterministic 410 modulus. When this value is zero, the original tithe is included in the payment. In this way it is impossible to predict if a tithe will be included in the pool payment vector until the block occurs, therefore givers cannot game the system.