Bible Pay

Governance => Pre-Proposal Discussion => Topic started by: Rob Andrews on November 19, 2018, 01:12:10 pm

Title: Add Proof-of-Giving
Post by: Rob Andrews on November 19, 2018, 01:12:10 pm
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

Title: Re: Add Proof-of-Giving
Post by: inblue on November 20, 2018, 01:59:41 am
Quote
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.

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

Quote
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.
Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 20, 2018, 09:00:22 am
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.




Title: Re: Add Proof-of-Giving
Post by: talisman on November 20, 2018, 12:00:14 pm
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.
Title: Re: Add Proof-of-Giving
Post by: sunk818 on November 20, 2018, 12:24:37 pm
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.
Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 20, 2018, 04:30:59 pm
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.


Title: Re: Add Proof-of-Giving
Post by: inblue on November 21, 2018, 08:07:57 am
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.
Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 21, 2018, 09:23:52 am
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?'







Title: Re: Add Proof-of-Giving
Post by: thesnat21 on November 21, 2018, 09:40:38 am
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?
Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 21, 2018, 10:16:52 am
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.

Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 21, 2018, 01:06:51 pm
"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.

Title: Re: Add Proof-of-Giving
Post by: sunk818 on November 21, 2018, 04:29:42 pm
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.
Title: Re: Add Proof-of-Giving
Post by: 616westwarmoth on November 21, 2018, 07:39:10 pm
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.
Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 22, 2018, 09:16:53 am
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.

Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 22, 2018, 09:34:07 am
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.


Title: Re: Add Proof-of-Giving
Post by: 616westwarmoth on November 22, 2018, 10:40:06 am
My concern about gaming is two fold.  One, I'm pretty that a tactical player could constantly jump around the T15 value and skew the mid range values to their benefit (running multiple wallets).  But for now, I'll leave that alone and concentrate on the bigger issue I see.  There is a psychological puzzle called, "The Dollar Game".  It revolves around the "sunk cost" fallacy.  In essence, logic will dictate that many Tranches (I'll call them "T's") will end up unprofitable.  And then most users will end up just giving the minimum to have a chance to mine in T0.  And then the other T's will fill up to get a positive gain.

I also don't see where we can get 2000 new users from.  Or put another way, how do we get these new users and why cannot we get them now?  The issue is on the short term the monthly addition of nearly 40M coins (your estimate which I think is fair and reasonable), plus the normal Orphan funding would equal our average monthly volume (in raw coins).  So unless we got these new users quickly, the system would crash as supply would far outstrip historical demand.  And normal PoG users will be self funding and not require an infusion of new coins.  So yes, if we could have a 10 fold increase in users (we have roughly 200 PoDC users now) that should have a positive impact on price.

Don't get me wrong, it's a near genius system from a computer science standpoint!  But I don't see a clear positive impact from it in terms of users (it's still pretty complex for a beginner) nor price (it doesn't really add a use case).
Title: Re: Add Proof-of-Giving
Post by: sunk818 on November 22, 2018, 12:24:42 pm
So the tranche (can we call this bracket or bucket?)  you belong to is the min & max of the last 205 blocks portioned in 1/16 increments? So, the tranche you belong to is a moving target?  If the recurring contribution to the orphan foundation address is automated and predictable, I could see donations made at specific block heights to place yourself in a solo tranche.
Title: Re: Add Proof-of-Giving
Post by: inblue on November 23, 2018, 02:28:33 am
Don't get me wrong, it's a near genius system from a computer science standpoint!  But I don't see a clear positive impact from it in terms of users (it's still pretty complex for a beginner) nor price (it doesn't really add a use case).

But exactly that is what will increase the value of BiblePay in the long term! I also think it's a genius system, not just the giving part or the unique feature of an integrated pool, but the astounding decrease of power consumption by 94%. Imagine if Bitcoin needed 94% less power to be mined... I think it's revolutionary, almost on par with Satoshi's ideas, especially now that Bitcoin uses as much power as a small country. But of course, all of this stands only if the algo is exploit-free. Sunk's post above is a potential exploit, but if the algo is made to be "perfect", then I don't see why to not implement it, even if it doesn't increase users in the short term.

So the tranche (can we call this bracket or bucket?)  you belong to is the min & max of the last 205 blocks portioned in 1/16 increments? So, the tranche you belong to is a moving target?  If the recurring contribution to the orphan foundation address is automated and predictable, I could see donations made at specific block heights to place yourself in a solo tranche.

Hmm, also, what if you tithe to more than one tranche/bracket, to increase your mining potential and to not waste your server's resources? And then the power reduction would also not be 94% if someone mines in 5 tranches.
Title: Re: Add Proof-of-Giving
Post by: 616westwarmoth on November 23, 2018, 08:43:29 am
My primary concerns are:

A shift from PoDC and staking could potentially flood the market with roughly 200M BBP.  Our monthly average volume in coins over the last month was 44M BBP.  Our one year average monthly volume is 65M.  If too much of this went to market it would crash the price and I fear we would not recover.  If most of it went into Sanctuaries that would dramatically decrease our ROI.

It's logical to think that in the moderate term, PoG could account for 40M BBP a month (iRob's estimate of monthly tithes which I see as reasonable).  This is funding that most likely will hit the markets more or less immediately.  Again, even looking long term, this would account for a majority of the traditional average monthly volume.  A near doubling of coins heading to market would likely crash the market and again, I fear if we drop to 1 sat we won't recover.

Finally, I'll revisit my technical concerns. 

I feel the system cannot be made to resist gaming under the current parameters.  Having one daily assignment of brackets (Tranches) would mitigate some of this, as a player could not continue to shift the brackets through the day.  However, this would introduce a new gaming strategy in which a well heeled player could run multiple accounts, make a massive bid on one of them (to ensure T15 status), quite possibly at a loss, then run four to ten other accounts to get solo positioning on the lower T's for a net gain.

I feel the system would to be hard for new users.  Right now, I can say with reasonable accuracy, if you PoDC, stake 100% (which would cost "x" BBP), you'll get about "y" reward a day.  Since the team RAC doesn't typically jump around by 20% or more a day, that becomes one less major variable for a new user.  However with this proposed system, one day a tithe of 400 BBP will earn you 700 BBP, and the next day it might earn you only 250 BBP (a loss).   That's going to be difficult to calculate a return on over time and would likely discourage a new user from beginning.

In conclusion, despite my feeling we gave up on PoDC when we eliminated the Team requirement and competitors blacklist, I still think it's the best system we've got given where we are at. If we were starting a new coin, I'd be more interested to see what PoG could accomplish (which is similar to one of my favorite systems to research, Proof of Burn even though the two are different animals).  But for our current position, a dramatic change of this nature could very well kill the markets and I'm not seeing a clear path to a horde of new users (and if that path exists, I don't see PoG making it more or less possible than PoDC).
Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 23, 2018, 09:42:24 am
I saw the recommendations of Tranche/Tithe on the other forum; I don't mind calling the Tranches "tiers" in the end for better PR.  The Tithe however - I agree with TheSnat, the 10% was more or less a guideline for the Jews in how much crop they gave back, but in general Tithe is giving out of ones personal holdings, and in that we are a religious base, I don't want to change from Tithe to donation so easily. 

EDIT:
For payment efficiency, we can break the payments up into tiers using :  (this interval is based on the last_block_tithed modulus % 16 of each giver) - put in simple terms, at block 80000, we pay pool tier 0, at 80015 we pay pool tier 15.  In this system, the highest givers are not paid on tier 15 - each tier is really a cross section of 1/16th of the pools owed recipients. 


As far as Suns concerns of 5year old, I think that this could be summarized in a very simple way - especially if you consider most miners do not need to know about the actual mechanics of bits/blockhash uints etc.  A lot of this is for this technical discussion only.  Using this in prod is as simple as watching a one page report and deciding to tithe or not, etc. 


EDIT 2: We still need tiers to prevent someone from massively tithing (and hogging) the entire global kitty in the morning.
So let us assume we have 'tithing tiers' and 'payment tiers'.  The tithing tiers exist to prevent one from hogging too much of the pool weight in one given gift tier.  It has the downside that it re-generates the tier breaks multiple times per day, but it has the upside that if a person or group attempts to hog a tier, a tier only can become unprofitable leaving the rest of the tiers open for the rest of us.  (In contrast to a global kitty, that could be ruined by one large giver at 9 AM).



Title: Re: Add Proof-of-Giving
Post by: 616westwarmoth on November 23, 2018, 11:01:01 am
Not sure what you mean about Sun's concerns of 5 years ago,   But a big concern would be the mechanism can be simply stated as "you donate and are rewarded", but the ROI would be wildly variable and we've seen how reasonably savvy users have had trouble understanding the PoDC staking tiers, this seems more complex than that.

This system while technically elegant, would require a myriad of safeguards to prevent gaming in practice, and that would add more complexity.

I think we're far better off improving the PoDC documentation, considering a team membership bonus and trying to improve that then spending time, energy and resources trying to develop something new.
Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 23, 2018, 02:54:10 pm
I've been doing some thinking today - about enhancing POG with a rule that would keep it fair for everyone (IE make it unexploitable by strategic givers).

I believe we need to add an element of uncertainty to the pool - to make the act of giving and being rewarded uncertain.  What this does is forces the giver to give based on expecting nothing in return, but having the ability to be in the pool and mine.

Basically what we would do is make each tiers payments have an unpredictable recipient list - where each recipient included in the share weight has approximately 1/410'th chance of being in the payment structure.  (Although it sounds random, we would have a deterministic algorithm based on the best blockhash of the payment that determines if a recipient is included in the output).  So what this means is based on 205 blocks per day, a tither has only a 1 in 410 chance of actually being paid that day (per block), meaning that although one is in the pool, and one has tithe_weight, one is not necessarily going to get paid - except when they get lucky.  However, the pool weight would be adjusted to those chosen few in that round (another words, we still honor the tithe_weight, but those in the payment split the 80% fully) and those not in the payment lose out on that block.

This makes it a different animal in deciding when you go to tithe, you don't necessarily get a reward.  Unless you persistently tithe for a few days straight.  Then you are more likely to get a reward at least once.  Also note however when a person does get paid, the payment will be that much higher - so people aren't really losing money here- they just have no certainty to receive anything back when chosen.  (This system does not reward more frequently if one tries to hack it and send in multiple gifts, as some would be lost others would be not lost - so I believe from the standpoint of 10 tithes of low amounts from 10 hacked wallets OR 10 tithes of high amounts from hacked wallets, it would not matter, as there is always a new 1/410th event per block payout deciding whether the individual tithe counts or not- so in that sense it is not exploitable either).

This should fully remove any chance of gaming the system as it is a complete unknown if the pool will pay you back on a given day.

Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 23, 2018, 04:37:18 pm
So now the pros of POG:

* Any single pc or unbanked phone (pending MIP to add a tithe button to mobile wallet) could receive pool rewards
* Approx a 90% electricity reduction diverted to the orphan foundation (since PODC would be diverted to pool payments)
* A 100-700% increase in orphan sponsorships (potentially) as compared to PODC
* Mass adoption is possible, due to one-click setup
* Equivalent security (since the heat miners still exist, and potentially increase)
* Internal Pool
* Simple to support and use and explain

Cons:

* A more basic algorithm, we lose the "cancer mining" mantra


So we really have to consider the facets.  I know people have a "stake" in PODC, and they are rightfully going to be resistant to change.  I'm even highly supportive of the PODC infrastructure.  For me it boils down to the tradeoff of more potential orphans (that electric is not being Wasted per se, but this is the first time I considered trading it off for orphan sponsorpships in a new way).  That influenced me.  The mass adoption potential influenced me also.  And lastly I always have the 'third party' issue hanging over us, where we have to fight to prove these RAC credits have always been accurate by the project admins.


(Possible side terms:  tithers = sowers, miners = reapers)
Title: Re: Add Proof-of-Giving
Post by: 616westwarmoth on November 23, 2018, 09:16:51 pm
Again, its a technically beautiful system.

Where is this sudden influx of users?  How are we to get them and why can we not get then now?

So far, the system has been hard to explain to us dedicated users.  I haven't seen a clear cut simple explanation nor summary of how this would work.

Finally, don't think I'm stuck on PoDC because I'm in it, it would be great to have a system that cost less to operate because the big operators could stand to save a bunch on electricity.  I think it's a great marketing tool (cancer research), great for humanity, but the biggest thing I see is the release of stake which I think would crush the markets.
Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 24, 2018, 10:13:35 am
Again, its a technically beautiful system.

Where is this sudden influx of users?  How are we to get them and why can we not get then now?

So far, the system has been hard to explain to us dedicated users.  I haven't seen a clear cut simple explanation nor summary of how this would work.

Finally, don't think I'm stuck on PoDC because I'm in it, it would be great to have a system that cost less to operate because the big operators could stand to save a bunch on electricity.  I think it's a great marketing tool (cancer research), great for humanity, but the biggest thing I see is the release of stake which I think would crush the markets.

I agree, removing the PODC stake might crush the market for a short period (depends on how many whales buy up 5 satoshi coins and how quickly).  Its uncertain how much of that would be converted to sancs however (probably 75% of those coins wouldnt enter the market because the user would rather create a sanc and wait - than "give" them away cheap).

I think the difference between PODC and POG - as far as the influx of users is something like this:  In PODC, Mary & Joe take a look at cancer mining, and maybe one of the two figures it out and sticks with it, and has trouble explaining it to 5 friends - one of whom is really a technical geek and gives it a try- this leads to a dead end relatively quickly (unless, our price starts to rise - then people are convinced of biblepay for the profit reason).  I think this is where we are now.  This is all speculative on POG, but I believe the difference is this:  Mary and Joe install BiblePay at home, on each pc, they both understand it, and both of Mary & Joe's external network hears about BiblePay at lunch, and if we have a success rate of more than even 20%, via simple word of mouth - then we end up with grass-roots growth, basically looking at more than 3 users per day entering our ecosystem and staying would explain a possible source of the 2000.  I suppose to even say more succintly, what ecosystem can be engineered that causes positive sustainable growth with a quantifiable measure of new users.  You might this is all speculative, but if I show a new user a good reason And its easy, this picture might change.  The picture of PODC is :  Im doing something good for the world, Im spending electricity, Im maintaining a highly technical environment.  The picture of POG is :  Im mining BiblePay with very little electricity in the background, Im giving to the orphan foundation, and Im getting back biblepay rewards, and its easy, why dont you run it in the background also?  (There is a difference in hobbyists who spend a lot on server expenses - and have a lot of servers, as compared to a lot of users who each spend very little on the server and electricity) - but the question is will we reap long term investors from both or from the latter?

Anyway, let me work on simplifying POG down to a new explanation, knowing what we know now, as I added the uncertainty principle to it yesterday.

Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 24, 2018, 12:26:52 pm
I edited this one to make it technically correct:
https://wiki.biblepay.org/Proof-of-Giving

I added this simplified version for a new user to grasp:
https://wiki.biblepay.org/Proof-of-Giving-for-Beginners

In summary, we no longer have tiers for giving or payments (but the pool does emit a giving report by tier for informational purposes only), instead we have a global kitty now with tithe_weight by user.  But we also now only pay pool recipients whose tithe is chosen (with a 1/410 chance of each tithe being weighted and therefore rewarded per block). 
Title: Re: Add Proof-of-Giving
Post by: thesnat21 on November 24, 2018, 06:18:49 pm
Couple of questions:
How would this handle multiple-client/machine miners (one large wallet, but copied to multiple machines for mining purposes)? 

What happens if we get over 1k miners,  the reward and/or chance would drop drastically, 

Would there be logic to prevent someone from missing too many payments (or getting paid too many times, while others "Starve")

It's an ambitious proposal.. .

Title: Re: Add Proof-of-Giving
Post by: 616westwarmoth on November 24, 2018, 07:50:30 pm
This is given as fuel to improve.  Not criticism.

Is the 1/410 random or deterministic? 

If it's deterministic, then it is far easier to game and I would say it should not be done.

If it's random, then if each block there is a 1/410 chance I will be selected (as a tither) then there is a 2.87% chance a tither could go a week without a reward.  That is going to put people off (meanwhile the same 2.87% chance a person will receive a reward seven day straight days).

Are only tithers going to be given the exclusive 15 minute mining window?  If not, then 20% of our coins could be again swamped by botnets.  I would think some exclusive period would be granted based on the tithe_weight.  That is, in your simplified example, Miners 401-500 would get the first 60 seconds exclusive, then 301-500 would get the next 60 seconds, until finally, 1-501 would all have exclusive rights in the fifth minute before opening it up to the non-tither's on minute six?  Those numbers could be modified but without an exclusive period (or if all miners get the same window regardless of tithe), then I see the botnet head rearing up again if the price improves.
Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 24, 2018, 09:34:40 pm
This is given as fuel to improve.  Not criticism.

Is the 1/410 random or deterministic? 

If it's deterministic, then it is far easier to game and I would say it should not be done.

If it's random, then if each block there is a 1/410 chance I will be selected (as a tither) then there is a 2.87% chance a tither could go a week without a reward.  That is going to put people off (meanwhile the same 2.87% chance a person will receive a reward seven day straight days).

Are only tithers going to be given the exclusive 15 minute mining window?  If not, then 20% of our coins could be again swamped by botnets.  I would think some exclusive period would be granted based on the tithe_weight.  That is, in your simplified example, Miners 401-500 would get the first 60 seconds exclusive, then 301-500 would get the next 60 seconds, until finally, 1-501 would all have exclusive rights in the fifth minute before opening it up to the non-tither's on minute six?  Those numbers could be modified but without an exclusive period (or if all miners get the same window regardless of tithe), then I see the botnet head rearing up again if the price improves.

The 1/410th formula is in the wiki, and I just want to point out - deterministic in crypto does not mean it is determinable by humans *beforehand*.  You can't have random in crypto (or the chain would fork).  The element of randomness when solving a block is that a deterministic blockhash is less than the deterministic hash target (note that both were deterministic) but solving the block is still essentially random.  Anyway this particular choosing method is also deterministic (in the sense that we wont fork by using it) but you cannot determine if a winner won until the payout event - so that it cant be gamed.  Yes, correct, I would never have suggested a "win/loss" event algorithm that could be gamed, otherwise it would be useless the first week in prod.  Just check out the algo in the wiki at the end of the doc.

I realize the outlier would mean some couldnt solve a block for 7 days straight, that is a given.  Its better than solo mining.  All one has to do is continue to tithe daily as long as the pool report shows "profitable" to do so.  Eventually they get paid.  Thats a beauty, I think, compared to jumping on bitcoin and never being paid in 100 years, and not needing a pool.  Note that this system scales as well, we could handle 1 million miners with this system (although I admit, they wouldnt all tithe because once the kitty is exceeded people will scale back tithes.  But price improvements would change that).  Impo, I would just tithe in the morning and at night until a payment comes through (as long as our pool is profitable) - the tithes would be cumulative, so each new tithe would increase the total in the pool for the single unpaid miner.

Could you please explain the 15 minute mining window question in more detail?  All entry tithes mature in the pool in just 6 blocks.  Everyones tithe is equal (as far as chance of being entered, timewise).  The payout event happens at the instant a new block is mined.

Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 24, 2018, 09:53:11 pm
Couple of questions:
How would this handle multiple-client/machine miners (one large wallet, but copied to multiple machines for mining purposes)? 

What happens if we get over 1k miners,  the reward and/or chance would drop drastically, 

Would there be logic to prevent someone from missing too many payments (or getting paid too many times, while others "Starve")

It's an ambitious proposal.. .

So on the multiple machine question - lets first take copying the wallet to 10 machines:
If you have one wallet copied into 10 machines, each tithing 100 bbp, each tithing event would be cumulative (meaning the pool would regard it as ONE tithe - the latest blocks - but with the SUM of the tithes over 24 hour period).  If you have 10 machines with different wallets, these would be Separate tithe events and pool entries.  However I want to make one big declaration - the pool adds an exponential tithe_weight on of ^1.25 so that bigger givers get up to 5% more weight - this promotes consolidated wallets.  So a miner would be reluctant to split up to 10 wallets (as they lose tithe_weight).  So I cant think of any advantage of doing that splitting up in this type of pool.  Since every tithe is a new event, every single tithe has a brand new 1/410 chance of being counted - so that is strong enough for us to keep someone from executing some type of horizontal attack on the pool (as  that would possibly result in a net loss for them- if one tries to hog the pool horizontally, they have individual delayed chances of winning or losing, and they would fill the pool up with tithes - which helps the foundation, so yes people might play games but in the long run the house always wins, so I think it would settle down to be a binary decision - has biblepay collected more than the critical threshhold or not for the day - we of course would have a nice rpc report for that right off the bat).

We could handle 1 million miners in this system.  Since we only pay out 1/410th of the recipients per block, scaling is not an issue.  But the real question is technically : what happens after the pool receives > 2,000,000 in tithes in a 24 hour period (regardless of quantity of tithes, but regarding the sum).  The expected payout per day is 2,050,000 roughly (based on a 10K block after the sanc is paid).  If a miner chooses to tithe 100,000 bbp and so on after the pool already collected 2 MIL, what they are doing is either hoping to get lucky (by establishing some share weight) or not caring if they break even or lose a little.  It gets relatively redicules if we collect 4MIL on a day and the pool is only paying out 2 MIL.  The answer is the RPC report showing the total tithes (in the last 205 blocks) will empower the decision.

There would be no logic to take care of starvers or excessive receivers, but technically, this system would pay so frequently with 205 blocks per day that in a given 2 week period for most intents and purposes, the effect would be very reliable.  The ebbs and flows would work themselves out.  Consider a situation where you can solo mine one block every 3 days (roughly) and this is exactly what we are looking at.  The reason we should lean toward this uncertainty principle is when someone tries to game it, the fate of that person is the same as people who try to game a casino - they end up giving the orphan foundation the excess and that is good for the orphans.

Title: Re: Add Proof-of-Giving
Post by: 616westwarmoth on November 25, 2018, 06:16:48 am
The 15 minute window question:

Currently, but my understanding, for the first 15 minutes, the only miners that can solve a block are ones with Mag (i.e., PoDC miners).  After 15 minutes, that restriction is lifted and anyone can mine.  Additionally, a single miner currently cannot mine more than one out of a certain number of blocks (8 sticks in my mind but I don't have it handy in my notes).

Under this proposal, what if any mining restrictions are proposed.  I would think no restrictions would quickly put us in a similar position.  I one point it was suggested (during the tiers discussion which appears tiers are no longer part of the equation), that only members of a tier could mine without restriction.   Is the plan to retain some form of both restrictions (the class, i.e., PoG members only for some time and the frequency, i.e., a miner is only allowed to mine one of out every "x" blocks")?  That said, I would see value in both.  Additionally, I would see some merit in having the exclusive period being somehow related to the tithe_weight to reduce the impact of someone getting the entire exclusive mining window with a minimum tithe.
Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 25, 2018, 08:02:00 am
The 15 minute window question:

Currently, but my understanding, for the first 15 minutes, the only miners that can solve a block are ones with Mag (i.e., PoDC miners).  After 15 minutes, that restriction is lifted and anyone can mine.  Additionally, a single miner currently cannot mine more than one out of a certain number of blocks (8 sticks in my mind but I don't have it handy in my notes).

Under this proposal, what if any mining restrictions are proposed.  I would think no restrictions would quickly put us in a similar position.  I one point it was suggested (during the tiers discussion which appears tiers are no longer part of the equation), that only members of a tier could mine without restriction.   Is the plan to retain some form of both restrictions (the class, i.e., PoG members only for some time and the frequency, i.e., a miner is only allowed to mine one of out every "x" blocks")?  That said, I would see value in both.  Additionally, I would see some merit in having the exclusive period being somehow related to the tithe_weight to reduce the impact of someone getting the entire exclusive mining window with a minimum tithe.
Oh your talking about the late_block_threshhold (the 15 mins); (I couldn't figure out what you meant before); so for everyone else the late block threshhold is the amount of time that must pass in the current round of POBH heat mining where the block is about to be late, and we lower the difficulty of the block (by 80%) - this allows the block to be solved easier, and then the chain continues.  We have that in prod now.

So as far as tiers, they were removed to simplify this algorithm (they originally existed when 'gaming' was an issue - but with the uncertainty principle in the proposal they were removed for simplicity).

I envision in this latest version, everyone will heat mine all the time - no restrictions.  This is for security; I was thinking, since we would no longer have cpids, we would lose the Last 4 distinct cpid rule, therefore we would have no protection from cpids, hence the reason for beefing up security.

"No restrictions point us in a similar position" (Of having botnets).  Well financially - it would be slown down (in relation to the old POBH algo where the POBH botnet owner made 100% on a solo mined block - ) if one is only paid 20% you would think they would not be funded to create unlimited hashpower nodes;                                                       
     
      We will also use the miners tithe_weight to influence the hashpower - (this was in the original version).
The miners tithe_weight will adjust the ability to solve a heat mined block by influencing the target hash by 1-100% (according to their pool tithe_weight).




Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 27, 2018, 09:03:14 am
Thanks for the positive support.

Although I think we possibly could have improved POG enough for it to work, I really didn't like the out-of-line high-tithe percentage potential it had (IE causing the monthly dump).

In light of the popular view, I'm going to shelve this technology for a while in favor of other endeavors.

I'll also add weight to prioritizing PODC easy adoption technical features.

Thanks for the exercise all, it was a net gain for our arsenal from a wisdom standpoint.
Title: Re: Add Proof-of-Giving
Post by: sunk818 on November 27, 2018, 11:04:32 am
Thanks for the positive support.

Although I think we possibly could have improved POG enough for it to work, I really didn't like the out-of-line high-tithe percentage potential it had (IE causing the monthly dump).

In light of the popular view, I'm going to shelve this technology for a while in favor of other endeavors.

I'll also add weight to prioritizing PODC easy adoption technical features.

Thanks for the exercise all, it was a net gain for our arsenal from a wisdom standpoint.

This dev modified PoW he calls it Hybrid Proof-of-Work. Details of the algorithm are on page 15. He believes an ARMy of Raspberry Pi can secure the blockchain with the various rules in place. My thought is that CPID can be removed and these other rules can be put in as a replacement. Something to mull over...
http://cdn.getlynx.io/2018-06-18_Lynx_Whitepaper.pdf
Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 27, 2018, 02:08:12 pm
This dev modified PoW he calls it Hybrid Proof-of-Work. Details of the algorithm are on page 15. He believes an ARMy of Raspberry Pi can secure the blockchain with the various rules in place. My thought is that CPID can be removed and these other rules can be put in as a replacement. Something to mull over...
http://cdn.getlynx.io/2018-06-18_Lynx_Whitepaper.pdf

Thanks a lot... checking it out.
Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 27, 2018, 02:42:04 pm
Thanks a lot... checking it out.
Man, it's almost like he was signing his own last will and testament when he wrote a couple of those paragraphs, lol.  "Coin has been hacked, in a way where its like taking 10* the money out of the atm", "Exchanges are advised to require 200 confirms", but no on a more serious note, it does offer a couple ingenious ideas, I cant say I would go so far as to claim groundbreaking, as I think we have pondered most of the individual aspects inside this algorithm before.  The POS coin-age provides the source for the distinct miner list (so that unlimited hashpower cant attack during a 51% attack- similar to our use of cpids), the last 2 characters of the blockhash to provide unique solving, the low reward for POW (similar to our 10% POBH reward).  This appears to be a relatively novel way of rewarding POS rewards in a POW (low-energy) environment.  Similar to how we force the energy consumption to be low on our controller wallets but reward the lions share out to the BOINC users. 

I'm thinking we should take some time to really evaluate every potential technology out in the world, including Cardanos whitepapers, and really sit down and design a pie-in-the-sky potential algorithm to back up PODC in case we ever need it.  Off the top of my head, I keep thinking of POSE as one (proof-of-service), where we link a users Proof-of-stake (IE an aged UTXO) to a users dynamic IP- and create an internal list of online miners who are actually full nodes.  That could be one useful way to reward users in a hybrid pose-pow-pos environment.

I'm going to do some deeper research into the latest and lets start thinking in a more groundbreaking way.
At one time, we had an amazon storefront and (for the most part) no one used our crypto to buy anything.  Lets also consider storefront integration (as potentially linked to mining).  Or decentralized slices of fiat payments linked to mining.

Title: Re: Add Proof-of-Giving
Post by: sunk818 on November 27, 2018, 11:26:24 pm
(so that unlimited hashpower cant attack during a 51% attack- similar to our use of cpids)

What's nice about the Hybrid PoW approach is that it is self contained within the blockchain and biblepay code. Eliminates the need for CPID.

Title: Re: Add Proof-of-Giving
Post by: sunk818 on November 27, 2018, 11:32:40 pm
If you want help with storefront integration (I ran an eBay & web shop for 10+ years), so I can be a subject matter expert. I've been wanting to submit a proposal for BiblePay t-shirt fundraiser accepting BiblePay and donate profits to Compassion.com in the form of sponsorships
Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 28, 2018, 01:09:13 pm
If you want help with storefront integration (I ran an eBay & web shop for 10+ years), so I can be a subject matter expert. I've been wanting to submit a proposal for BiblePay t-shirt fundraiser accepting BiblePay and donate profits to Compassion.com in the form of sponsorships

Ok, sounds good, let's try to think about a two pronged approach.  I think we still need someone to study all altcoin deals with existing merchants- they can be found in bitcointalk threads about adding successful storefront checkouts.

If someone can find us one that sells a Christian product we could contact them and try to integrate as well.

The other prong is something id like to discuss soon about us creating an API.

Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 28, 2018, 01:32:20 pm
What's nice about the Hybrid PoW approach is that it is self contained within the blockchain and biblepay code. Eliminates the need for CPID.

I partially agree, but there are a couple things that can also be gamed in hybrid POW systems.  In classic POS, where coin-age is rewarded, people can split stakes deliberately and keep an old coin to stake more often.  This can be mitigated in systems that require coin_value*age (to this day I think only the interest bearing coins do this, as the coin_value*age = interest rate reward).  The problem I see in Lynx is someone could still split the wallet and have twice the chance of solving a block (given enough capital - in their case they wont financially - because you only get 1 lynx - but that means its useless to be a distinct pointer to a user, which is what we wanted for more advanced use cases).  So we would need to be careful if we ever go with a hybrid solution to financially reward with an incentive to people who tend to re-stake the same coins (IE something that promotes consolidated wallets).  If that ID could be used as an identity, say for instance a pointer to a reputation score that could also be used for voting weight in a Christian content economy (IE voting on Christian videos or content).  (In the case of lynx the ID is just a pointer to a coin > 1000 of a certain age, but there is no guarantee one does not have 10 wallets). 


Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 29, 2018, 08:23:29 am
For future investigation - a potential end-to-end solution for POG:

1.  POG Difficulty algorithm dynamically gyrates from .01 - 65535
2.  Difficulty dictates minimum_coin_age, minimum_coin_amount, and maximum_tithe_amount accepted inside POG stake
3.  The coin staked must be greater in value than the tithe amount (IE the staked coin is used to pay the tithe) and the tithe must be staked by one coin only
4.  POG Difficulty regulates the maximum tithes per month to be accepted (approx 4 million max tithes per month decreasing at the current deflation rate)
5.  Remove uncertainty principle, make pool rewards certain again
6.  Add a tithe helper dialog that shows  the individual max tithe amount based on all owned coins (or a label)

Pros:

1.  Can not be scripted to be exploited based on time of profitability
2.  Pool will not collect more than the max tithe amount per month (preventing dilution)
3.  Does not directly make the rich richer (as the individual coin is a random cross section of BiblePay) - in contrast to POS (where the highest coin_amount*age stakes the most coins and money)

All credit to Yeshua.

Title: Re: Add Proof-of-Giving
Post by: thesnat21 on November 29, 2018, 10:50:23 am
For future investigation - a potential end-to-end solution for POG:

1.  POG Difficulty algorithm dynamically gyrates from .01 - 65535
2.  Difficulty dictates minimum_coin_age, minimum_coin_amount, and maximum_tithe_amount accepted inside POG stake
3.  The coin staked must be greater in value than the tithe amount (IE the staked coin is used to pay the tithe) and the tithe must be staked by one coin only
4.  POG Difficulty regulates the maximum tithes per month to be accepted (approx 4 million max tithes per month decreasing at the current deflation rate)
5.  Remove uncertainty principle, make pool rewards certain again
6.  Add a tithe helper dialog that shows  the individual max tithe amount based on all owned coins (or a label)

Pros:

1.  Can not be scripted to be exploited based on time of profitability
2.  Pool will not collect more than the max tithe amount per month (preventing dilution)
3.  Does not directly make the rich richer (as the individual coin is a random cross section of BiblePay) - in contrast to POS (where the highest coin_amount*age stakes the most coins and money)

All credit to Yeshua.

Interesting, this would alleviate some of the "too much to dump" issues,  I suppose the monthly budget could be used to "fill the gap" between the tithe and the required orphan funds.

#3: The coin staked must be greater in value than the tithe amount (IE the staked coin is used to pay the tithe) and the tithe must be staked by one coin only

I'm not understanding the "tithe must be staked by one coin only" part, could you elaborate?


I'd need more info on the pool rewards,  (how they are calculated / split,  will it be like now where POW(POBH) is somewhat "random", and would get harder as difficulty increases)
Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 29, 2018, 11:35:32 am
Interesting, this would alleviate some of the "too much to dump" issues,  I suppose the monthly budget could be used to "fill the gap" between the tithe and the required orphan funds.

#3: The coin staked must be greater in value than the tithe amount (IE the staked coin is used to pay the tithe) and the tithe must be staked by one coin only

I'm not understanding the "tithe must be staked by one coin only" part, could you elaborate?


I'd need more info on the pool rewards,  (how they are calculated / split,  will it be like now where POW(POBH) is somewhat "random", and would get harder as difficulty increases)
Yes, I think one step further is to use the current deflating getgovernanceinfo_charity_budget at 50% as a tithe_cap_max (Ill add this to the POG 2 wiki)  this is about 3.2 mil currently.

So on the coin staked must be greater in value, what Im thinking here is - this is a way to ensure all both rich and poor can participate (not seeking coin*age, but seeking single coins that may be spent on tithing, keeping this algo fair for every newbie or small sower), anyway here is an example: If you go into coin control, and take a look at your current coin values and ages, you will probably see a few 4,000~ values (if you have a sanc) and ages around 7-30 days old (maybe).

So the goal is if POG_DIFFICULTY = 1000,  the minimum_coin_age would be 7 days, and the minimum_coin_amount would be 100, so in order to tithe you need to spend the coin from your wallet that is older than 7 days old, and lets say that coin is 4000 bbp, then you could tithe Up to the maximum_tithe_amount (200bbp for that diff level).  In this case you could tithe.

The part about tithe must be staked by one coin means you cannot tithe based on 5-10 coins, you must tithe from that one coin.  So if you want to send in 200 bbp, that one coin must be > 200 bbp by itself.  This prevents the script kiddies from exploiting.

So we end up spending single coins for tithing (if we have them).

Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on November 29, 2018, 04:48:15 pm
Rough draft of POG2:

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

Beginners guide II:
https://wiki.biblepay.org/Proof-of-Giving-for-Beginners



Title: Re: Add Proof-of-Giving
Post by: way2 on November 30, 2018, 08:18:16 pm
I didn't see anyone else ask this, so I apologize if this is redundant, but what about doing a fork and running with the current system and POG?
Title: Re: Add Proof-of-Giving
Post by: thesnat21 on December 01, 2018, 05:25:42 pm
I didn't see anyone else ask this, so I apologize if this is redundant, but what about doing a fork and running with the current system and POG?

hard fork, or branching fork?

I don't see people wanting to run 2 chains,  and any other change would require a hard fork
Title: Re: Add Proof-of-Giving
Post by: way2 on December 02, 2018, 04:11:46 pm
My thought was running two coins.  Since the new concept is so different from what is currently working, launching it from scratch made the most sense to me.  That would give two options -- one for the more advanced users and the other that is so easy to use, anyone, can set it up.  I don't see any way to have such a significant fundamental shift without massive devaluation. 

Most of us probably mine multiple coins already, so if doing the other system on my cell was easy, I would do it.  If you focus the marketing nearly exclusively on mobile devices, it shouldn’t be a direct competitor for the current BBP system. 
Title: Re: Add Proof-of-Giving
Post by: thesnat21 on December 02, 2018, 07:26:33 pm
My thought was running two coins.  Since the new concept is so different from what is currently working, launching it from scratch made the most sense to me.  That would give two options -- one for the more advanced users and the other that is so easy to use, anyone, can set it up.  I don't see any way to have such a significant fundamental shift without massive devaluation. 

Most of us probably mine multiple coins already, so if doing the other system on my cell was easy, I would do it.  If you focus the marketing nearly exclusively on mobile devices, it shouldn’t be a direct competitor for the current BBP system.

Without more people to pick it up,  a fork like that would split already limited resources..  Plus would be difficult to get on to any exchanges at this point.

Not a bad idea overall,  but I don't see it workable in the short-term.
Title: Re: Add Proof-of-Giving
Post by: way2 on December 03, 2018, 09:08:59 pm
I guess I am trying to walk a fine line.  The idea does have merit, and I certainly don't want to be disparaging.  However if the new idea is unable to stand on its own, it may be best to wait until the audience is better developed, there is a strong foundation of success to build from and there are corporate partnerships in place.  The current BBP does have bugs to work out, so improving the current product offering by making it more new user friendly seems like a better approach than a fundamental change. 

Here is an example concept for PR: Giving to charity is a good thing and the current donation recipients are certainly good candidates.  But there may be a way to add some strategic donations that can help with some of the lingering issues.  For example, if BBP set up a $500 -- 1,000 scholarship for essay writing with Regent, Southeastern, Liberty, etc. you would get targeted students looking at the program closely.  Some of those essays may be decent candidates to be published in school publications which could get the author an additional scholarship.  Something like this would expose you to people that could potentially help solidify the support needed to keep the system viable or better, help it really thrive.

Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on December 05, 2018, 10:35:21 am
I guess I am trying to walk a fine line.  The idea does have merit, and I certainly don't want to be disparaging.  However if the new idea is unable to stand on its own, it may be best to wait until the audience is better developed, there is a strong foundation of success to build from and there are corporate partnerships in place.  The current BBP does have bugs to work out, so improving the current product offering by making it more new user friendly seems like a better approach than a fundamental change. 

Here is an example concept for PR: Giving to charity is a good thing and the current donation recipients are certainly good candidates.  But there may be a way to add some strategic donations that can help with some of the lingering issues.  For example, if BBP set up a $500 -- 1,000 scholarship for essay writing with Regent, Southeastern, Liberty, etc. you would get targeted students looking at the program closely.  Some of those essays may be decent candidates to be published in school publications which could get the author an additional scholarship.  Something like this would expose you to people that could potentially help solidify the support needed to keep the system viable or better, help it really thrive.

I think thesnat makes the best point; we have limited resources and in a fork scenario you need two strong groups with a heart for each branch.  If we forked two versions of biblepay you would have Me supporting the one that appears to be good for easy adoption and the other one wouldnt get any support or upgrades and would endanger it.  You would need two competing devs I think.  (Also, it costs $50,000 to be listed on an exchange and Fork #2 would not be tradeable LOL).

But anyway, I think we will still have a microcosm of what you want over the next 90 days.

Im writing POG2 in testnet in a way (primarily based on SunK's first idea to replace POBH with POG), but with the expectation that POBH will be extended to be POG - with the existing POBH rewards for the pool - with PODC still running.  So then if it works, we can just go live with it in prod and we will have POG for heat mining in prod with PODC.  (IE 480~ bbp reward for POG per block - as POBH is now).   

    Then as a further step after we feel good about it we vote to promote it to replace PODC (as a sanc poll) then during that future cutover block it replaces PODC (if the poll passes). 



Title: Re: Add Proof-of-Giving
Post by: way2 on December 05, 2018, 04:36:17 pm
Thanks Rob!
Title: Re: Add Proof-of-Giving
Post by: AndrewScribner on December 06, 2018, 12:21:53 am
Thanks, Rob, I understand it better after reading your post and the comments posted. I really didn't get it before when you emailed. It does sound like a good idea and will make the crypto more simple and usable for people. I also like the reward system, but as inblue said it needs to be agreed upon by the community.
I do love Biblepay and how there seems to be a good innovation. I don't know of any other coin that works on the proposal system to give to charities.
Title: Re: Add Proof-of-Giving
Post by: AndrewScribner on December 06, 2018, 12:25:09 am
Rob, you had previously mentioned the proof of orphan mining to me, not POG. my mistake.
Title: Re: Add Proof-of-Giving
Post by: Rob Andrews on December 06, 2018, 08:44:53 am
Rob, you had previously mentioned the proof of orphan mining to me, not POG. my mistake.

Thanks Andy,

Yes, the POOM (proof of orphan mining) doesn't seem to be going over very well due to the closed API issue and people are reluctant to let a 3rd party scan their info (which makes sense). 

We can test POG in testnet and see what kind of reception we get - then baby step 1 is to use it as extension to our existing heat mining.
If we can allow people to heat mine without cpids and with POG, that should give us an indication if we have easy adoption.