Add Proof-of-Giving

Let us discuss the viability of POG, as the future mining algorithm for BiblePay.

POG is an extension of POBH(Our version of POW), and promotes mass adoption.

Note that I personally love what we have achieved with PODC, but it appears PODC has caused some attrition in our community overall.  It's hard to say specifically, but some feedback is telling us that we are too hard to set up and maintain in our mining environment.  New users don't have the stake for the UTXO, and some average home users feel they do not want to learn (nor care) about all the acryonyms we throw around with PODC.  The average user does not want to learn about RAC, or run multiple programs, unfortunately. 

The goal is to create a friendly environment where the average user may download biblepay and launch it in a plug n play environment and start mining without a learning curve.  Then they can tell their friends about us.  Also, for us to fairly reward everyone rich and poor with a mining reward.  POG appears to do this, in the sense that it rewards those who tithe into tranches.  It gives us an internal pool, so the user does not need to rely on an external pool for rewards (meaning that every POG miner is rewarded for mining without learning about pools).

If we can create an environment with a positive growth rate of a few new miners per day, we will potentially be on our way to creating a successful long term future for our orphans and our community.

Please read:

https://wiki.biblepay.org/Proof-of-Giving

This system removes the necessity of pools, meaning that no one misses out on solo mining. This simplifies the biblepay infrastructure.

This is excellent, I love the idea of having an automatic pool of sorts, so everyone is solo mining, but at the same time they are pool mining automatically. Very unique, haven't seen something quite like this in other coins. And I hope it means it'll be simple for users to get into.

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

I think this is the most important part for the adoption and a must-have on day 1. That's why I think it's best to work on this wallet feature in parallel to the PoG code, so it can be ready at the same time. It would not be amazing if it'd be very complicated to setup PoG manually, and the in-wallet automatic tithing feature were months away.

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.

I like the idea of the reward system, but maybe the community can agree on exact numbers or make some other changes? Because if I understood the math correctly, we can have the following example (intentionally extreme):

Miner 1: hashpower 1 MH/s, tithed 1 BBP
Miner 2: hashpower 1 H/s, tithed 1M BBP

So basically 100% of the blocks will be found by miner 1. But they will be rewarded like this:

Miner 1: 0.01 BBP + 2000 BBP = 2000.01 BBP
Miner 2: 7999.99 BBP

Effectively "Miner" 2 doesn't spend money or energy for hashpower and gets 80% of all rewards. In a real scenario, there could be hundreds of miners with medium hashpower and medium tithe, and just dozens of whales with low hashpower and high tithe, and they could make something like 50% of the total weight.

This is excellent, I love the idea of having an automatic pool of sorts, so everyone is solo mining, but at the same time they are pool mining automatically. Very unique, haven't seen something quite like this in other coins. And I hope it means it'll be simple for users to get into.

I think this is the most important part for the adoption and a must-have on day 1. That's why I think it's best to work on this wallet feature in parallel to the PoG code, so it can be ready at the same time. It would not be amazing if it'd be very complicated to setup PoG manually, and the in-wallet automatic tithing feature were months away.

I like the idea of the reward system, but maybe the community can agree on exact numbers or make some other changes? Because if I understood the math correctly, we can have the following example (intentionally extreme):

Miner 1: hashpower 1 MH/s, tithed 1 BBP
Miner 2: hashpower 1 H/s, tithed 1M BBP

So basically 100% of the blocks will be found by miner 1. But they will be rewarded like this:

Miner 1: 0.01 BBP + 2000 BBP = 2000.01 BBP
Miner 2: 7999.99 BBP

Effectively "Miner" 2 doesn't spend money or energy for hashpower and gets 80% of all rewards. In a real scenario, there could be hundreds of miners with medium hashpower and medium tithe, and just dozens of whales with low hashpower and high tithe, and they could make something like 50% of the total weight.

Thank you Inblue for your comments and praise.  These are very good points.

On the auto-tithe, we can do that, I think we can release version 1.0 in testnet, and during that week of testing write the auto-tithe feature.

Yes, I love the in-wallet pool idea - not only for simplifying our infrastructure, but we may be able to say "first crypto with an integrated pool".  (We have to check into that).

Moving on to your examples of these two miners:
Miner 1: hashpower 1 MH/s, tithed 1 BBP
Miner 2: hashpower 1 H/s, tithed 1M BBP


First of all Miner 1 would be in trache 0 (because he only tithed 1 bbp).  Meaning these two hashpowers would not be competing.  Miner 1 can only "mine" in blocks with an interval of 0, (for example, block 80000) while miner 2 can only mine in block 80015 (interval 15).  Miner 2 would certainly be competing in Tranche 15 because of the high tithe.

Next, lets change this up to this scenario:
Miner 1: hashpower 1 MH/s, tithed 1M BBP
Miner 2: hashpower 1 H/s, tithed 1M BBP

In this case both miners would be in tranche 15 competing against one another.  Miner 1 would find the block but would be forced to pay the pool 80% of the winnings (deterministically enforced btw, by the wallet checkblock code).  The only advantage Miner 1 would be getting for all that hashpower is the 20% bonus for finding the block.

Note that in this algorithm, miners who aren't in a tranche sleep during those blocks and wake up automatically when:  Their tranche is called, the block is late, or our difficulty rises more than 100% over the historical reference point.

Rob, you are a very creative and talented developer. Yet I have to say the more you propose the more I fear for the future

I evaluate every proposal here around 3 pillars: science, crypto profits and orphans (not in order of importance). This proposed change will definitely strike off the science part. I am a bit confused about the crypto profits part, could not really figure out how much I would get with regards to what I put in (sounded rather probabilistic to me) - whereas, in today's case, I can calculate returns vs investment and electrcity bill quite accurately.

The previous proposal (Proof-of-Orphan-Mining), on the other hand, does not eliminate the science part and creates cash influx to the ecosystem. In my opinion, that one would reduce the pressure on exchange prices.

While we are discussing these ideas, I am very curious about the impact of team blacklist removal (voting ends tomorrow). Byteball team has made their move against whales, which might start looking around for revenue maximisation, in addition to Gridcoiners interested in double-dipping.

Is this a variation of proof of burn : https://en.bitcoin.it/wiki/Proof_of_burn

The probability part seemed like we were gambling like roulette... I could be wrong but that was my initial impression.

Is this a variation of proof of burn : https://en.bitcoin.it/wiki/Proof_of_burn

The probability part seemed like we were gambling like roulette... I could be wrong but that was my initial impression.

Its actually not related to proof-of-burn.  Not related to gambling since everything is deterministic.
(Mining is more related to gambling as you have to get lucky to solo mine a block), but in this integrated pool you surely get a payment if you tithe.

I'm sure people will create reports on web pages to show the amount of profit left per tranche.  The only probability of payment left for a miner to mine a tranche that is over-full of tithes is to gain the 20% hashing reward.

First of all Miner 1 would be in trache 0 (because he only tithed 1 bbp).  Meaning these two hashpowers would not be competing.  Miner 1 can only "mine" in blocks with an interval of 0, (for example, block 80000) while miner 2 can only mine in block 80015 (interval 15).  Miner 2 would certainly be competing in Tranche 15 because of the high tithe.

Next, lets change this up to this scenario:
Miner 1: hashpower 1 MH/s, tithed 1M BBP
Miner 2: hashpower 1 H/s, tithed 1M BBP

In this case both miners would be in tranche 15 competing against one another.  Miner 1 would find the block but would be forced to pay the pool 80% of the winnings (deterministically enforced btw, by the wallet checkblock code).  The only advantage Miner 1 would be getting for all that hashpower is the 20% bonus for finding the block.

Note that in this algorithm, miners who aren't in a tranche sleep during those blocks and wake up automatically when:  Their tranche is called, the block is late, or our difficulty rises more than 100% over the historical reference point.

1. Ah, I got a little confused with tranches, I forgot that the miners in my example would be in different tranches. So if the miners sleep 15/16ths of the time, does that mean the CPU will be roughly at 0 for 94% of the time? That is certainly interesting and as the wiki says - green, but I wonder if there would be any economic or technical complexity because of that. By economic complexity I mean people who rent servers would have to pay for the entire server resource and use it for only 1.5 hours out of 24 hours in a day. By technical complexity I mean that the server providers could potentially automatically flag these spikes as something not normal and limit the server. But on the plus side, that will further improve the resilience and friendliness of the algorithm by making it harder to mine for "hashpower whales" and easier for home users, because the algo would be very friendly to their home CPU and their power bill. Now that I think of it, this seems to be a good feature, although very unique and untested so far, but I hope for the best.

2. In your example where they both tithe the same (or similar) amount and are therefore in the same tranche, if my math is correct, they would receive this many BBP per block:

Miner 1: hashpower 1 MH/s, tithed 1M BBP - 4000 + 2000 = 6000 BBP
Miner 2: hashpower    1 H/s, tithed 1M BBP - 4000 BBP

Hashpower is clearly not valued nearly as much as tithe, which I know was the goal. And yes, in a real scenario, there would be for example 100 users in a tranche, so each user would get 80 BBP when their block comes, and the block founder will get 2080, which is much more compared to others in the tranche (unlike the example above), BUT the chance is much lower, and it's not predictable how much you can earn due to the luck factor, whereas the 0 hash big tithers would have a much better predictability - the competition in a tranche would increase relatively steadily, like in sanctuaries. Also, you would only have 13 chances per day (205/16) to win the lottery of finding a block, so the luck factor is 16 times more unstable than when you have 205 chances per day.

Another thing it crossed my mind is that maybe a solution to the 0 hash big tithers would be something like having a requirement of producing a certain hashpower over the previous 24h to be able to tithe at all, and the higher amounts of tithe would be unlockable with larger hashpower.

3. If tranche levels are determined by arbitrary numbers, then I think the middle tranche levels would be the most empty. I want to explain this by the following example: let's say there is a poll named "How much do you earn per year?" and there are 5 possible answers:
a) 85k or less   b) 85-90k   c) 90-95k   d) 95-100k   e) 100k or more

The results would be something like this:
a) 87%   b) 1%   c) 1%   d) 1%   e) 10%

I put them close intentionally, but the point is that it's impossible to assess all people's salaries and evenly distribute the offered answers, or tranches. You would have to categorically know the statistical wealth of BiblePay users. Therefore I think the middle tranches would always be the most empty, even emptier than the highest one, because simply there are no further levels than 15, so all whales, big and small, would flock in that one tranche. Correspondingly, the first tranche or two will be a test bed for newcomers to try and mine, so those first few levels will always be busy. That means it will be more profitable to tithe less than level 15, to not be in the top tranche, and rather find another nearly empty tranche. So it could happen that the ones who tithe more would be rewarded less and vice versa. That doesn't seem intended. So maybe solve this by having incremental rewards per each tranche? So if we have 128k BBP for all 16 tranches (8k * 16), it could be distributed so that tranche 0 doesn't get 1/16th of 128k, but say 1/100, and tranche 15 gets like 1/5. But that also doesn't look fair somehow.

4. Could it happen that the earned BBP for a 24-hour period is less than tithed BBP? If so, that could put off many users, especially if it's very unpredictable what will happen. Or if the return could be roughly the same as the tithe. How can we ensure this doesn't happen? It looks like it would happen when the number of users increases, while the tranche levels and reward amounts stay the same.

1. So if the miners sleep 15/16ths of the time, does that mean the CPU will be roughly at 0 for 94% of the time?

 I mean people who rent servers would have to pay for the entire server resource and use it for only 1.5 hours out of 24 hours in a day.

 but I hope for the best.

2. In your example where they both tithe the same (or similar) amount and are therefore in the same tranche, if my math is correct, they would receive this many BBP per block:

Miner 1: hashpower 1 MH/s, tithed 1M BBP - 4000 + 2000 = 6000 BBP
Miner 2: hashpower    1 H/s, tithed 1M BBP - 4000 BBP

 Also, you would only have 13 chances per day (205/16) to win the lottery of finding a block, so the luck factor is 16 times more unstable than when you have 205 chances per day.

Another thing it crossed my mind is that maybe a solution to the 0 hash big tithers would be something like having a requirement of producing a certain hashpower over the previous 24h to be able to tithe at all, and the higher amounts of tithe would be unlockable with larger hashpower.

3. If tranche levels are determined by arbitrary numbers, then I think the middle tranche levels would be the most empty. I want to explain this by the following example: let's say there is a poll named "How much do you earn per year?" and there are 5 possible answers:
a) 85k or less   b) 85-90k   c) 90-95k   d) 95-100k   e) 100k or more

4. Could it happen that the earned BBP for a 24-hour period is less than tithed BBP? If so, that could put off many users, especially if it's very unpredictable what will happen. Or if the return could be roughly the same as the tithe. How can we ensure this doesn't happen? It looks like it would happen when the number of users increases, while the tranche levels and reward amounts stay the same.

On #1, I was envisioning thousands of 'single home pc/single laptop' miners - with less being spent on electricity to rent servers and more being spent on tithes.  But yes, from a CPU graph perspective we would certainly only spring to life during that 6% timeslice.  (However I am looking at this now, and it might be beneficial to allow any miner to solve any tranche - IE leave the miners running - but tithe_weight still gives an advantage to the tithers.  Im thinking of dead days where 10 tithers tithe and unplug the machines.  I dont want any possibility of leaving the miners off until the block is late then they all wake up.  So let me look into leaving them all running, but the tithe_weight itself is what keeps total hashpower competition down).

On #2, Yes, correct on the payment amounts, and yes - only 13 chances per day to solve a block per registered tither.  On the 'solution for 0 hash big tithers' Im not sure we would want to fix that - if they tithe then they are helping orphans and can be deserving to get a pool payment (as you could have a situation where someone tithes once a day and the machine only hashes 1 hash per minute but they are in the pool with tithe_weight).


On #3, you are definitely correct in that the first couple hours of a day, middle tranches will be gutted like the wild west- but the info will be public on some type of in-wallet leaderboard, and also I believe TheSnat will make a web presence, so basically the empty tranches will be glaring at everyone ripe for the picking, therefore tithes will be sent out manually to fill those voids.  So they would quickly be filled up - I think every day, with random manual tithers.  (Through arbitrage).    Note that the highest giver will actually change all the tranche breaks.  If we go an hour with 100 BBP being the highest tithe, the 16 breaks are based on 6.25 bbp break levels.  If one whale tithes 100K at 10AM, the breaks table changes to 6250bbp and opens up the possibility of tithing from tranches 1 - 14.  So its a dynamic changing environment every day.  (The breaks are dynamic and deterministic but not arbitrary). 

Regarding the possibility of someone tithing too much by accident in a tranche, I think we should let them.  Its everyones responsibility to know what they are doing.  I cant offer a true solution anyway, because the tranche breaks are dynamic and the act of giving a higher amount re-generates the breaks means its not necessarily true that a new giving amount is unprofitable, except where the amount exceeds the maximum payout per 24 hour coinbase reward (~130,000 bbp) - we could say 'are you sure you want to donate more than the maximum 24 hour mining reward?'

How would this affect the superblock payments?

Since the ongoing daily tithe's to the foundation would help cover orphan expenses does that potentially reduce the impact needed?  (In the current market,  I would say long-term we would want to use the money for growth purposes).

Short-term if this is the case, and say we exceed 10% via mining-tithes.   We could dedicate more towards PR or something else?

How would this affect the superblock payments?

Since the ongoing daily tithe's to the foundation would help cover orphan expenses does that potentially reduce the impact needed?  (In the current market,  I would say long-term we would want to use the money for growth purposes).

Short-term if this is the case, and say we exceed 10% via mining-tithes.   We could dedicate more towards PR or something else?

Well on a side note  - superblocks vout[payments] vector would come right after the pool payments, and Ive done some testing on this in the past and they still work (IE pool payments dont break the superblocks, as long as sum of pool recipients payments are less than coinbase reward and we will check that, and check the pool recipient list to ensure it matches as well).

Anyway, yes, theoretically with the chance of receiving up to 130,000 bbp per day per tranche, I would assume we would see tithe levels jump up to ~90,000+ per tranche so that these guys can get a little profit on their tithes from the pool, meaning that out of our daily 2.08M emission, we would see tithes of 1.44M to the foundation.  Thats massive.  Thats 43 million bbp per month, which is about 7* our current orphan sponsorship level.  Although we have a lower price now, that would possibly equate to 700 monthly orphans (fulfilling roughly the same as POOM, except we don't have the decentralized individual orphans) - but we have to start somewhere.  I know one thing, making an orphan collage of 500+ orphans is a MOVING experience for almost any of our partners.  If we did succeed at that alone, I feel like it would open other doors for us (IE bigger exchanges and other projects), although I cant say that with certainty, but I know our 329 orphan collage moved Cryptopia's heart to lower the fee by 80% for BiblePay, right before we crashed.

Yes, I agree wholeheartedly that we could utilize the existing budget for other things, or remove it.  Its up to the community.

"It is more blessed to give than to receive" - Acts 20:35   (This would be a very good line for our PR/website) for POG.

Can you explain tranche in more detail. I'm not clear on how often you are eligible to mine a block depending on your tranche. Is this based on the lasts two digits of the block height? How many tranches are you creating? I'm concerned since I have questions, how is a newbie going to be explained the concept of PoG? If its too complicated, then it'll be hard to market and explain.

Couple of thoughts and questions:

The "can only win every 8 blocks" or whatever the number is, still remains?
The "anyone can mine after 15 minutes" remains?

If both the above are true, then would it not make sense to allow a user to mine in every Tranche equal to or lower than their number?  And should the 15 minutes be reduced to 7 minutes?

If the T levels are public, won't that make the system suspect to people gaming it?

If there is the possibility of adding even 20M a month to the foundation, that is BBP that will be sold on the markets and that would be 50% of our monthly volume over the last 30 days.  The impact of this on the overall price seems it would be negative.  Additionally, the average users will only tithe less than they can reasonably earn, so they will not require additional BBP on the open market.

I really like the concept and the potential mechanics from a computer science perspective, but I don't see it adding dramatically to the user base in the short to moderate term nor having a positive impact on the price.

Can you explain tranche in more detail. I'm not clear on how often you are eligible to mine a block depending on your tranche. Is this based on the lasts two digits of the block height? How many tranches are you creating? I'm concerned since I have questions, how is a newbie going to be explained the concept of PoG? If its too complicated, then it'll be hard to market and explain.

I can promise you, we can explain this to new users, once we make a succinct explanation and tithe page.  Its just a foreign concept now because I am intermingling all the techie stuff in to capture the proposal details and the part for the requirements for the integrated pool.

So Ive been doing some R&D for security reasons and I think this proposal would be modified to allow absolutely anyone heat mining to mine - all the time (forget the sleep for now) but for reasons explained later (financial reasons) it still is green.  So from a mining standpoint, you mine it and can solve any block (for the 20% block reward).  From a tithing perspective you tithe to enter the pool.  Every block reward is related to a tranche, and it first pays the miner the 20% who solved the block - then pays the tranche recipients only on that level for the pool rewards (with the remaining 80% based on share_weight).

A tranche is just one of 16 tiers available that correspond to block numbers.  Basically block 80,000 is tranche 0.  In that tier we have the lowest givers.  In tier 15 we have the highest givers.  When block #15 rolls around, the highest givers get rewarded.  Every gift is converted to tithe_weight for the tranche (which is the same as share_percentage).  Share_percentage drives the payout ratios for that tranche block reward.

Couple of thoughts and questions:

The "can only win every 8 blocks" or whatever the number is, still remains?
The "anyone can mine after 15 minutes" remains?

If both the above are true, then would it not make sense to allow a user to mine in every Tranche equal to or lower than their number?  And should the 15 minutes be reduced to 7 minutes?

If the T levels are public, won't that make the system suspect to people gaming it?

If there is the possibility of adding even 20M a month to the foundation, that is BBP that will be sold on the markets and that would be 50% of our monthly volume over the last 30 days.  The impact of this on the overall price seems it would be negative.  Additionally, the average users will only tithe less than they can reasonably earn, so they will not require additional BBP on the open market.

I really like the concept and the potential mechanics from a computer science perspective, but I don't see it adding dramatically to the user base in the short to moderate term nor having a positive impact on the price.

1.  On the 8blocks/15 mins, let me explain this a different way. 
We all wake up at 8am, and look at biblepay the first day - all tranches are empty (tranche 0-15 = 0 giving).
Slovakia decides to send in .001 bbp first as the early bird.  He gets .001% share weight in Tranche 0.
Rob sends in 1000 bbp and what this does is it expands and establishes the tranches (from the initial default of 100bbp for tranche 15).  Now we have Tranche 15 with a "940-1000" label, containing 1000 in tithes.
West sends in 930 bbp and yours goes into tranche 14 (because its "880-939") and now it contains 930 bbp.

So let me explain a couple things about the timing.  Lets say we are operating on block 80,000 at 8 am.
It will take 6 blocks (6 confirms) for the tithes to "enter" the tranches.  When you type 'exec poolreport' or whatever the command is to get off the ground, this report will always be 7 blocks behind historically (IE it will say "pool report - block range [79790 - 79994]'.  This allows the wallet to deterministically display every single value from history as "current" for the state of the pool, for block solving, etc.

Other than continually being  7 blocks back, everything moves forward in real time.  You are just seeing the state from 7 blocks ago when you view the leaderboards, the tranches, etc.


2.  As far as gaming it.  Its really the "opposite" of gaming.  Gaming has the connotation that you are cheating to obtain something you dont deserve.  This is actually wide open and fair game in the morning, and once it is 'filled up with recipients' it is no longer profitable to tithe anymore into it.  It is arbitrage, but it is actually requiring the energy of one to take a look each day and say "is there any opportunity on any tranche to tithe into biblepay and make a profit"?  If its no, we walk away til tomorrow.  If yes, you send a tithe into that tranche.  (Note that in reality since every block has a 205 block lookback period - there is really no reset at 8am on day #2 - there is just a view of the last 24 hours of activity).


3.  On the 'big dump' per month if we go with this:  I agree that this whole ecosystem would start out with a very slow growth potential and in the early months, we would have this huge buildup of foundation funds to sell, but I think what we have learned about our little PODC UTXO expiriment is that in the long run, miners must pay for electricity and they do unlock those funds, some people have to now pay for sanc VM bills (like me) and do have to unlock a sanc to pay the VM bill for example (in a roundabout way), etc, so no matter how you analyze it you have the potential of dumping the BBP on the market.  Im really looking at this as a longer term effort, lets take a look at this from another perspective.  Lets say that we attract 2,000 single PCs who follow the forum and leave BBP running, and 10% of those get hooked on crypto and become longer term investors because of our 'deflationary' environment.  That is when the tide starts to turn and the monthly dump ends up being a drop in the bucket (IE a 5% move instead of a 100% move).  Also, if we ever achieve bittrex or poloniex, the normal volume there would absorb the monthly dump.