Difference between revisions of "Proof-of-Giving"

From BiblePay Wiki
Jump to: navigation, search
m (added PoG category)
(11 intermediate revisions by one other user not shown)
Line 1: Line 1:
** DOCUMENT INCOMPLETE - DO NOT SHARE **
 
  
  
Line 10: Line 9:
 
Proof-of-Giving is a flavor of Proof-of-Work geared for a high adoption rate.
 
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 in tranches.
+
It rewards miners who are small, medium, or large by tithe_weight from an internal pool.
  
The idea is to increase the chance of solving based on those who have tithed the greatest in the block-tranche to the orphan foundation.
+
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.
 
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 weight reward level the miner will receive for block solving for a given tranche-interval-phase block.
+
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 and give the miner an even higher chance of solving a block in their tranche.
+
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, miners tithes will '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 chance of a reward (in contrast to sending tithes from separate wallets).  As the sum of the amount tithed will place the miner in a higher tranche paying a higher reward.
+
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 also prevents botnets from forming, because rewards are based on individual miner controller wallets and tithe amounts, not based on ramping up POW competition.
+
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.
+
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 statistics for the "round" will be available in the wallet and on the overview, for a nice new UI feature.
  
Example with one tithe of 100 bbp and one tithe of 225,000 bbp:
+
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,000
+
Current Round Tithes:  225,100
Tranche 0: 0-14062 BBP
+
<br>
Tranche 1: 14063-29,100 BBP
+
Miner 1 tithe_weight: .0004%
...
+
Miner 2 tithe_weight: 99.96%
Tranche 15: 205,930-225,000 BBP
 
...
 
  
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 10 bbp.  They boot the wallet, use the defaults, and tithe .50 bbp to the foundation.  They are now mining in tranche 0.
+
The block solver receives 20% of the reward, with the remaining 80% split by Miner 1 & Miner 2.
 +
<br>
 +
 
 +
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).
 +
<br>
  
 
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.
 
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.
 +
<br>
  
How does this system reward a very high giver?  If one gives 50,000 BBP and this lands in tranche 15, this miner will have a very high advantage every 15th block.
+
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).
 +
<br>
  
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 chances of mining a block by the SUM of the individual wallet contribution (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 - as the higher tranches pay a higher reward.
+
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.
 +
<br>
  
 
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.
 
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.
 +
<br>
  
Pool mining is replaced with the action of tithing.  Once you have a tithe in a tranche, you are guaranteed to receive a reward once a tranche block is solved.
+
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.
 +
<br>
  
 
PODC is removed, so as to give the entire reward to the POG miners, and to promote 'easy adoption' by new users.
 
PODC is removed, so as to give the entire reward to the POG miners, and to promote 'easy adoption' by new users.
 +
<br>
  
 
100% of the foundation tithes are used for orphan sponsorships.
 
100% of the foundation tithes are used for orphan sponsorships.
  
 +
<br>
 +
 +
'''GREENNESS'''
 +
 +
<br>
 +
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.
 +
<br>
  
 +
'''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:  REWARD'''
 +
Let us assume 500 miners tithed:
  
'''EXAMPLE 1:  TRANCHE 0 REWARD'''
+
<br>
  
In this example, Tranche 0 (this is equal to block interval 0, occurring once every 16 blocks), in this tranche we have the lowest amount givers.
+
<table frame=box>
Let us assume 5 miners tithed, with 3 tithes from miner 1:
+
<tr><th>Inbound Tithes</tr>
 +
<tr><td>Miner 1-100: <td>Tithed 10
 +
<tr><td>Miner 101-199: <td>Tithed 20
 +
<tr><td>Miner 200-299: <td>Tithed 30
 +
<tr><td>Miner 300-400: <td>Tithed 40
 +
<tr><td>Miner 401-500: <td>Tithed 50
 +
<td><td>Total Tithes (500 givers): 15,000 <td>
 +
</table>
  
Miner 1: Tithed 20+100+100 = 120 TOTAL
+
Let us assume Miner 2 found the block:
Miner 2: Tithed 20
+
<table frame=box>
Miner 3: Tithed 30
+
<tr><th>REWARD:
Miner 4: Tithed 40
+
<tr><td>Miner weight from 1-100: <td>.0007%
Miner 5: Tithed 50
+
<tr><td>Miner weight from 101-199: <td>.0013%
 +
<tr><td>Miner weight from 200-299: <td>.002%
 +
<tr><td>Miner weight from 300-400: <td>.0027%
 +
<tr><td>Miner weight from 401-500: <td>.0033%
 +
</table>
  
Let us assume Miner 2 found the block (even though miner 1 had the greatest tithe-hash-power).
+
<ul>Block distribution:
REWARD:
+
<br>
The tranche is broken into weights:
+
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).
Sum of Tithes to foundation : 260 bbp
+
<br>
Miner 1 weight: 46%
 
Miner 2 weight: 8%
 
Miner 3 weight: 12%
 
Miner 4 weight: 15%
 
Miner 5 weight: 19%
 
  
Block distribution:
 
There will be 5 recipients in this block.  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.
 
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.
 +
<li>Miner 150 Reward: 1928
 +
<li>Miner 450 Reward: 6068
 +
<li>Miner 2 Reward: 2000 
 +
</ul>
 +
 +
Total: 10000 BBP
  
Miner 1 Reward:  3680
 
Miner 2 Reward: 640 + 2000
 
Miner 3 Reward: 960
 
Miner 4 Reward: 1200
 
Miner 5 Reward: 1520
 
  
Total: 10000 BBP
+
 
 +
<br>
 +
 
 +
 
 +
'''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.
 +
 
 +
<br>
 +
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. 
 +
 
 +
<br>
 +
In this way, it will take an average of two days of giving regularly (@205 blocks per day) to be paid one reward on *some* of 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.
 +
 
 +
<br>
 +
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.
 +
 
 +
[[Category:Proof of Giving]]

Revision as of 17:15, 5 February 2019


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

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 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: .002%
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 *some* of 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.