Proof of Giving (PoG) - Suggest max coin age to 1 day

[sunk818]

Proof of Giving payout is less predictable because some users are using coin age older than 1 day. They are intentionally saving up multiple days to earn a bigger reward. The payout for other participants is less predictable.

I would like to suggest a max coin age of 1 day regardless of the coin age submitted.

[biblepay]

I think its important to allow small users to be able to save up coin age in order to stake in competition with the big dogs.

Capping coin age at one day is in effect removing age from the equation - thereby making the equation more of a lottery on who has the most balance on a given day. This would decimate the small holders (they would receive zero in contrast to someone with a large balance) - which I think is unfair.

Coin Age rewards those who are saving the biblepay and holding it - thats a valuable attribute.

Yes, people are saving up intentionally, and that is their right (to not tithe on a particular day).

I disagree that its "less predictable" - than what, mining? I think its much more predictable - than most algorithms I can think of that order a list of users by reward per week.

[sunk818]

I disagree that its "less predictable" - than what, mining?

The way it is currently designed, it is less predictable than setting a cap of coin age of 1 day because individuals save up and tithe at unknown intervals.

[biblepay]

Saying that miners can receive constant and consistent rewards by setting a cap, is equivalent to saying stock market intervention by the government (IE if Trump were to create a team to limit all stock sales to no more than $1000 per day per participant would decrease market volatility), yes that would be a true statement. (But it doesn't make it the correct solution - because it destroys the algorithm to be a worthless one - one based on user balance).

The question remains, are little fish being rewarded appropriately? Im all for rewarding little fish appropriately.

With coin age they do receive their equal reward, when its staked. We need a clearer definition of the problem if such problem exists.

[sunk818]

I haven't thought of all the scenarios, so I'm open to the idea that this may not be the "correct" solution. How would you reward the "little fish appropriately"?

because it destroys the algorithm to be a worthless one - one based on user balance

If you PoG tithe twice a day, it ends up being mostly based on a user's balance. I don't agree that makes the algorithm worthless -- it just places less emphasis and doesn't allow people to game PoG like they are now.

One user said: Yes,the whale pog donation 20k and resive 200k next day,and i gave 3000 k and get 30 bbp back, ... ,so i quit big donation,couse i belive we small one pog to the whales not to the poor

Whether the sentiment is correct, that's how at least one user feels. This BBP member likely doesn't fully understand how coin inputs and coin age works. These are difficult concepts to non-technical people, so it is not surprising...

Anyway, I think you can grow PoG participants if there is a way:

1. if you have predictable payouts, then this is easier to market. exec roi helps predict payout, but if someone saves up BBP for 7 days and tithes 27k out of 11M BBP, the exec roi ends up not reflecting what happens on the next payout. A smoother trend up or down will encourage participation. For example, with PoDC RAC took 14 days to build up so new RAC joining did not affect the daily payouts dramatically.

2. an incentive for friends to tell other friends about BBP (e.g. "little fish" encouraging other "little fish" to join). I think it is better to have lots of different people talking up BiblePay than a few whales. This is also why I suggested setting a max prominence (Proof of Giving (PoG) - Suggest max prominence at 10% #9). Could you ban people gaming with multiple CPKs?

[biblepay]

Sun, please don't enter tickets to ask for consultation from the team, instead contact us directly and ask us for advice.

The ticket system is for feature requests and bugs.

The question should be rephrased as "I don't know how to solve this problem, but MIP or Rob, do you believe we have a problem in this area, and if so how would you recommend we solve it?"

Looking at the original post, I explained how removing age from coinage ruins our algorithm and that I believe coinage rewards the small fish as fairly as the large fish.

[sunk818]

The ticket system is for feature requests

I made a feature request to cap the coin age to 1 day. It would be nice, but I don't expect you to agree.

[biblepay]

I pointed out why the idea is flawed; Again, its a flawed idea that would reduce POG down to a static richlist, decimating small users, and is not as fair as coin*age. Small users can also save up coin_age, and that is what you are not taking into account.

If you think it all the way through and generate a model, and present an idea with substance we can open the case. But a cap is not the answer.

One other thing you have to keep in mind, is we want no part of a system that can be gamed by a hacker. Putting a cap in the code sets us up for people to programatically create multiple CPKs up to the cap, pilfer the funds back to the main wallet, and bypass the "weak security" a cap affords. Thats why Im on edge about that idea, and things similar to that.