Bible Pay

Governance => Pre-Proposal Discussion => Topic started by: Rob Andrews on November 29, 2018, 06:02:22 pm

Title: Mass Adoption for BiblePay II
Post by: Rob Andrews on November 29, 2018, 06:02:22 pm
When voting please consider a non-technical investor who wants to mine- remember to consider a person that has a busy lifestyle that does not want to follow more than 1-2 steps before losing patience, and has no interest in learning any new acronyms.

With PODC - we would need to pull in developer resources to shield the user from acryonyms, and find a way to concentrate new user mining power to a boinc project with fair payment without exposing the user to technical terms and requiring them to monitor RAC on disparate sites.  We also have quite a bit of infrastructure to support PODC: supporter pools, diagnostic tools, help desk answers, forum posts, etc.  Consider the total barrier of entry and ongoing maintenance per user and for the codebase.  Also consider the risks if BOINC changes the code, the interface, breaks or gets hacked.



With POG II - we would move back to our Proof-of-bible-hash style mining, on generally one machine per user (IE tither).  People would be rewarded with mining rewards in a "pool" depending on how much they tithe to the orphan foundation per day.  This solution would be more of a one-click setup, with the only decision needed by the end user to either manually tithe or set up an automatic tithe.  The maintenance should technically be lower for both user questions and the IT codebase.  There is not a chance of third party site being hacked or an oracle requirement.  The 51% risk appears to be low (the same as PODC or lower, as long as sleep capability is well designed).  One potentially large side benefit:  Being possibly the first crypto with an integrated pool - and not requiring third party pools.
(Rob recently added a proof-of-giving difficulty algorithm to address the top 2 POG problems:  Monthly tithe cap to prevent a massive monthly dump, and preventing a hacker from using a tithe script attack).  With these two improvements, voting is being re-evaluated.
Please read this wiki:
https://wiki.biblepay.org/Proof-of-Giving-II
And this wiki:
https://wiki.biblepay.org/Proof-of-Giving-for-Beginners



With POOM - we decentralize our orphan sponsorships out to the individual miners.  The miners are rewarded with an amount of biblepay that is carved out of the heat mining budget in relationship to their monthly private commitment amount.  The downside to POOM is this requires a centralized API at orphanstats.com, and biblepay has the ability to log in and audit individual user compassion accounts.  The plus is its very green, and diverts electric costs over to orphan sponsorships.




With IPFS - we require each user to make firewall rule changes, run a flavor of an IPFS server, allocate a portion of the hard drive, and we have the sanctuaries grade each miner on file hosting quality.  The downside to this is:  IPFS is still volatile, sometimes crashing on the pool server, the interface may change, the setup for a miner would be complicated, and we have no documentation for this complete yet, and we haven't finished the proof of concept.  The positive side is its futuristic.
Title: Re: Mass Adoption for BiblePay II
Post by: sunk818 on November 29, 2018, 08:50:43 pm
If you had an embedded BOINC manager in BiblePay QT, then new users could register and start crunching with fewer steps. All the stuff with CPID registration can be automated. PoDC Updates can be used to send pending registrants the 1 BBP they need to register their CPID. If there are 20 pending registrants, then the next round of PoDC updates sends a cumulative 20 BBP amongst all submitting PoDC updates. Or make CPID registration cost 0.001 BBP so it costs even less BBP during PoDC updates.
Title: Re: Mass Adoption for BiblePay II
Post by: sunk818 on November 30, 2018, 12:50:44 am
After having some time handholding someone on Discord on PoDC, staking requirements, etc, I do acknowledge PoDC configuration is difficult for some people to grasp. I think PoG has potential, but if you decide to implement, it has to be done conservatively. This is why I'm pushing for PoG replacing PoBH first. PoDC could eventually be replaced too, but there's a lot of vested individuals. If you're going to alienate PoDC miners, you need at as much automated donations coming in through PoG to offset the PoDC attrition and the staked BBP that leaves with it. If you're going to set a ceiling on the monthly donation amount, perhaps PoG replacing PoBH can work.
Title: Re: Mass Adoption for BiblePay II
Post by: BBP537 on November 30, 2018, 06:02:55 am
I support a POG approach. Not only can PODC be difficult to understand, but it is not accessible to everyone either because of the high RAC requirements. I'm a new user who has been crunching numbers on BOINC for weeks with a low-end machine running Linux and I still have yet to earn the least little bit of BBP because my RAC never got higher than 97 due to a couple of power failures and such.

I would be more than happy to participate in a system that rewards you based on your giving rather than being based on who can crunch the most numbers because they have the best computer. Tithing is a small price to pay in order to be able to participate in the rewards of mining along with everyone else and by tithing I still get to help people the same way I would by crunching numbers for cancer except that the help is now and not some future maybe that might happen if I crunch numbers long enough.

Besides all this, I've noticed that the general consensus seems to be that if we let go of PODC then we will lose the "we fight cancer" mantra. So what? We aren't the only ones with that mantra. It's not that unique. Gridcoin, Curecoin, MedicCoin and FoldingCoin all have the same mantra and so there a number of currencies for people to choose from. POG, however, IS unique and it is what will make BBP stand out from the rest. And, you know what? We still get to keep the basic underlying mantra that we HELP PEOPLE through tithing.

Also, I've seen the argument be advanced somewhere that they don't think POG will gain us a significant amount of followers enough to make the change worth it, but simply staying the way things are won't make a significant impact either. So, it's well worth the risk to try something new and innovative, especially when I've just proven that even if you make things easier with PODC, you will still be excluding an entire portion of potential followers who can't participate because they are too poor to afford a decent PC. Isn't the whole point of BBP to help the poor, or is it only to cater to investors, and those who have a vested interest in maintaining the status quo? I will leave that for voters to decide for themselves in good conscience. Thanks for allowing me to comment.
Title: Re: Mass Adoption for BiblePay II
Post by: way2 on November 30, 2018, 05:37:12 pm
How would this proposal impact sell side pressure?  If it results in a significant increase of sell side pressure, you should see a reduction in BBP value per coin.  This would mean the dollar value per month going to charity would remain the same because it is based on the amount of coins purchased in the marketplace.  However, the value of each person's holding would be reduced because of the spot price reduction.  This would hurt people that currently have large holdings. 

Title: Re: Mass Adoption for BiblePay II
Post by: talisman on December 01, 2018, 04:54:02 pm
I support a POG approach. Not only can PODC be difficult to understand, but it is not accessible to everyone either because of the high RAC requirements. I'm a new user who has been crunching numbers on BOINC for weeks with a low-end machine running Linux and I still have yet to earn the least little bit of BBP because my RAC never got higher than 97 due to a couple of power failures and such.

I would be more than happy to participate in a system that rewards you based on your giving rather than being based on who can crunch the most numbers because they have the best computer. Tithing is a small price to pay in order to be able to participate in the rewards of mining along with everyone else and by tithing I still get to help people the same way I would by crunching numbers for cancer except that the help is now and not some future maybe that might happen if I crunch numbers long enough.

Besides all this, I've noticed that the general consensus seems to be that if we let go of PODC then we will lose the "we fight cancer" mantra. So what? We aren't the only ones with that mantra. It's not that unique. Gridcoin, Curecoin, MedicCoin and FoldingCoin all have the same mantra and so there a number of currencies for people to choose from. POG, however, IS unique and it is what will make BBP stand out from the rest. And, you know what? We still get to keep the basic underlying mantra that we HELP PEOPLE through tithing.

Also, I've seen the argument be advanced somewhere that they don't think POG will gain us a significant amount of followers enough to make the change worth it, but simply staying the way things are won't make a significant impact either. So, it's well worth the risk to try something new and innovative, especially when I've just proven that even if you make things easier with PODC, you will still be excluding an entire portion of potential followers who can't participate because they are too poor to afford a decent PC. Isn't the whole point of BBP to help the poor, or is it only to cater to investors, and those who have a vested interest in maintaining the status quo? I will leave that for voters to decide for themselves in good conscience. Thanks for allowing me to comment.

First of all, welcome to the community !

Getting started with PODC may be a bit complex and painful, but there are people eager to help out starters (or experimenters) on our discord. I myself owe them a lot. I see you are upset with what your machine crunches out; please know there are many ways to kickstart BOINCing, including free cloud instances from Amazon and such. If you fail to succeed in them, I will be more than happy to assign a couple of my cpu cores to your account for a while so that you start seeing BBP coming your way. All you have to do is share with me your weak account key - don't worry, I cannot make any changes to your account with that key, apart from adding machines  ;)

We all want to have more and happy members in this team. And I respect everyone here, even Slovakia - who is known to have a devilish temper :)

All I would hope for in return is similar respect; not to me but to the entire ecosystem with its stake holders. I am a stake holder, with thousands of USD invested into BBP. Any proposal that would destroy the market price, including removal of the staking requirement, is a proposal I cannot support. I want to help the orphans, contribute to science, and make money if possible. But lose money? God forbid.
Title: Re: Mass Adoption for BiblePay II
Post by: BBP537 on December 02, 2018, 02:36:37 pm
First of all, welcome to the community !

Getting started with PODC may be a bit complex and painful, but there are people eager to help out starters (or experimenters) on our discord. I myself owe them a lot. I see you are upset with what your machine crunches out; please know there are many ways to kickstart BOINCing, including free cloud instances from Amazon and such. If you fail to succeed in them, I will be more than happy to assign a couple of my cpu cores to your account for a while so that you start seeing BBP coming your way. All you have to do is share with me your weak account key - don't worry, I cannot make any changes to your account with that key, apart from adding machines  ;)

We all want to have more and happy members in this team. And I respect everyone here, even Slovakia - who is known to have a devilish temper :)

All I would hope for in return is similar respect; not to me but to the entire ecosystem with its stake holders. I am a stake holder, with thousands of USD invested into BBP. Any proposal that would destroy the market price, including removal of the staking requirement, is a proposal I cannot support. I want to help the orphans, contribute to science, and make money if possible. But lose money? God forbid.

Thanks for the welcome and support! You have some valid concerns as a stake holder with money on the line. However, aren't they speculative concerns? What makes you so certain the market price would crash? And, what makes you so certain that even if it did have a short term correction due to the change that it would not then perform strongly as a result of the change after that?
Title: Re: Mass Adoption for BiblePay II
Post by: talisman on December 02, 2018, 03:53:13 pm
Thanks for the welcome and support! You have some valid concerns as a stake holder with money on the line. However, aren't they speculative concerns? What makes you so certain the market price would crash? And, what makes you so certain that even if it did have a short term correction due to the change that it would not then perform strongly as a result of the change after that?

I do not speculate, I calculate :)

The amount of BBP staked today due to PODC is well over 100M.

If PODC is gone, stake requirement will also be gone. It is only logical to assume some of the holders will sell off their BBP then. (Yes, some will bury it into masternodes, but we cannot assume all will do that.)

Any sales with today's weak buy board will push the price down (3 satoshis or less).

It is hoped that POG-2 will bring in cash (via new users), but as said, that is hope. There is not even an estimate on how many new users will bring in how much cash.

I understand and agree with the notion of a drop in the short term which would bring in growth for the long term; but we need to clarify what is short term and what is long term. This is the crypto world, and most people in this world would say one year is long term. That is a definition I tend to agree with. If we are on the same page about the term, then fine - I can hold on to my coins for a year for a rise back to 30+ satoshis (That was where I jumped on the boat)  ;)

Having said that, POG-2 may be tuned to promote staking  further, such that longer-term hodlers of coins get a bigger return when they tithe. This would reduce the sell pressure created by PODC staking gone. This however, would be real life repeating itself here: "rich gets richer". Well, I guess we cannot really escape basic principles of life even in the crypto world :)
Title: Re: Mass Adoption for BiblePay II
Post by: Rob Andrews on December 02, 2018, 04:49:28 pm
I do not speculate, I calculate :)

The amount of BBP staked today due to PODC is well over 100M.

If PODC is gone, stake requirement will also be gone. It is only logical to assume some of the holders will sell off their BBP then. (Yes, some will bury it into masternodes, but we cannot assume all will do that.)

Any sales with today's weak buy board will push the price down (3 satoshis or less).

It is hoped that POG-2 will bring in cash (via new users), but as said, that is hope. There is not even an estimate on how many new users will bring in how much cash.

I understand and agree with the notion of a drop in the short term which would bring in growth for the long term; but we need to clarify what is short term and what is long term. This is the crypto world, and most people in this world would say one year is long term. That is a definition I tend to agree with. If we are on the same page about the term, then fine - I can hold on to my coins for a year for a rise back to 30+ satoshis (That was where I jumped on the boat)  ;)

Having said that, POG-2 may be tuned to promote staking  further, such that longer-term hodlers of coins get a bigger return when they tithe. This would reduce the sell pressure created by PODC staking gone. This however, would be real life repeating itself here: "rich gets richer". Well, I guess we cannot really escape basic principles of life even in the crypto world :)

I just wanted to quickly jump in and add a distinction to the conversation regarding "rich get richer" vs POG2:

First differences between algos:

Proof-of-stake:  Entire free balance in stake * interest_component = interest_earnings (Rich definitely get richer based on total balance)
Proof-of-stake BiblePay:  62% of our money supply is tied up in Sancs, so 38% of money supply is available to "stake" a reward
Proof-of-Giving2:  Instead of basing the pool weight on the sowers amount_in_stake (this would be considered the unlocked coin_amount*age) , we base the pool weight on :  Tithe amount given with a required Spent coin > than difficulty level.

Notice the difference here:  In Scenario A, we reward a user entirely by the proven unlocked stake balance.
In Scenario B, we base the tithe_weight on the TITHED AMOUNT, and this amount must be spent out of a coin meeting the Difficulty requirements of the round.

Yes, I admit that richer users will have more free coins to tithe with, but note that the Actual act of tithing, the actual amount tithed drives your tithe_weight (not your available stake weight).  And note that in POG2, you must stake a coin and spend your coin age (so this cannot be repeated over and over until the coin ages again).  Also note that since the coin value must be greater than the tithe amount, one who spends a large coin will give up all of its age for quite a long period giving others in our ecosystem a long chance to tithe.

I don't have a scientific study of this effect, but if I were to guess I would "assume" forcing the spending of a single required coin will cause a whale to lose at least 50% of the benefit of (having whale resources available, this is because with POS you can use as many coins necessary to achieve
 total coin*age, where in POG you need one specific aged coin > min_amount for the round - and once its spent it is out for a while).  Remember the whales only have 38% of the money supply since they have the sancs tying up their capital....  EDIT:  More of a refined thought; to demonstrate this in contrast to POS:  With an average difficulty level of 650 in POG2,  you need to spend a 6 day old coin of value > 2500 but you can only tithe up to 270 from that coin.  So coins don't go as far as POS - and ultimately weight is based on what you tithed.




Title: Re: Mass Adoption for BiblePay II
Post by: 616westwarmoth on December 03, 2018, 11:38:25 am
PoG if it were to be selected (which I really feel is the wish of the Dev) one issue I see is it would require a long test period as it's a very novel solution.  The issue is we don't have very many users, and very very few participate in the test net.  So my fear is there will be loopholes and bugs that we won't catch but someone will exploit.  And my real fear is there will be many such bugs (as it's a novel system and having eight or ten people test it won't expose nearly enough issues), which could mean a series of exploits (and disproportionate gains for the exploiters) followed by hot-fixes and unplanned mandatory releases which could put our markets off line.

In short, even if PoG is the next billion dollar idea, the BBP community lacks the resources to adequately test it.
Title: Re: Mass Adoption for BiblePay II
Post by: talisman on December 03, 2018, 04:59:12 pm
PoG if it were to be selected (which I really feel is the wish of the Dev) one issue I see is it would require a long test period as it's a very novel solution.  The issue is we don't have very many users, and very very few participate in the test net.  So my fear is there will be loopholes and bugs that we won't catch but someone will exploit.  And my real fear is there will be many such bugs (as it's a novel system and having eight or ten people test it won't expose nearly enough issues), which could mean a series of exploits (and disproportionate gains for the exploiters) followed by hot-fixes and unplanned mandatory releases which could put our markets off line.

In short, even if PoG is the next billion dollar idea, the BBP community lacks the resources to adequately test it.

+1, right on the money again   ;)
Title: Re: Mass Adoption for BiblePay II
Post by: way2 on December 03, 2018, 08:11:36 pm
+2  Well said!
Title: Re: Mass Adoption for BiblePay II
Post by: Rob Andrews on December 04, 2018, 10:51:53 am
PoG if it were to be selected (which I really feel is the wish of the Dev) one issue I see is it would require a long test period as it's a very novel solution.  The issue is we don't have very many users, and very very few participate in the test net.  So my fear is there will be loopholes and bugs that we won't catch but someone will exploit.  And my real fear is there will be many such bugs (as it's a novel system and having eight or ten people test it won't expose nearly enough issues), which could mean a series of exploits (and disproportionate gains for the exploiters) followed by hot-fixes and unplanned mandatory releases which could put our markets off line.

In short, even if PoG is the next billion dollar idea, the BBP community lacks the resources to adequately test it.


Well in general this is good as the need for testing is critical, however we don't "lack the resources to adequately test it".

We need to put it in testnet, invite more than 8 testers (like 25), we need to cover every test case - and add every possible exploit.

To address the resource issue, it is possible to test it as what database programmers do (in the case of data management companies) is they write a stress test program and theoretically stress the system to exploit what conditions we think are missing - say for example we only have 10 testers, then we need to write a program to simulate the real life transactional activity of 250 users - then we would feel a lot better about it.

I think in addition to that we can phase this in two phases.  We go live with POG in POBH only then stay with it for a quarter and fix any critical issues before we attempt to transition from PODC to POG (during the second mandatory).
Title: Re: Mass Adoption for BiblePay II
Post by: talisman on December 04, 2018, 01:48:33 pm
I think in addition to that we can phase this in two phases.  We go live with POG in POBH only then stay with it for a quarter and fix any critical issues before we attempt to transition from PODC to POG (during the second mandatory).

That would be a good approach; I believe Sunk also supports this idea. We have nothing to lose when replacing POBH with POG. If this is successful, I will also support a change to the budget proportions of the algos (i.e., a reduction of PODC share and an increase of POG share).
Title: Re: Mass Adoption for BiblePay II
Post by: thesnat21 on December 04, 2018, 02:24:59 pm
My only concern with using it on the POBH side is it directly competes with PODC..

PODC combines coins into one for the updates, so only folks not working on PODC could participate in POG, this would need to be addressed somehow.
Title: Re: Mass Adoption for BiblePay II
Post by: talisman on December 04, 2018, 02:36:57 pm
My only concern with using it on the POBH side is it directly competes with PODC..

PODC combines coins into one for the updates, so only folks not working on PODC could participate in POG, this would need to be addressed somehow.

Well if they (we) are beyond full stake, and the podcupdates are sending a fixed amount, then we could do POG with the rest, is that correct?
Title: Re: Mass Adoption for BiblePay II
Post by: thesnat21 on December 04, 2018, 03:11:08 pm
Well if they (we) are beyond full stake, and the podcupdates are sending a fixed amount, then we could do POG with the rest, is that correct?

Yes in theory,   currently my wallet is at 109% of full stake and is  still consolidating for podc updates.  Just raising it as an issue so we can have a solution early on :)
Title: Re: Mass Adoption for BiblePay II
Post by: talisman on December 04, 2018, 03:47:33 pm
Yes in theory,   currently my wallet is at 109% of full stake and is  still consolidating for podc updates.  Just raising it as an issue so we can have a solution early on :)

Hmm, we might need a second wallet for that then (unless a fix cannot be made).

By the way, being able to do POG on mobile wallets would be perfect :)
Title: Re: Mass Adoption for BiblePay II
Post by: MIP on December 05, 2018, 03:18:06 am
Hmm, we might need a second wallet for that then (unless a fix cannot be made).

By the way, being able to do POG on mobile wallets would be perfect :)

Mobile wallets don't keep a full copy of the blockchain, only headers and your own wallet's tx and utxo. This makes any PoS-like schema very hard to implement. PoG is different in concept but I'm afraid it shares this limiting factor with PoS.

There is a nice article here:
https://blog.ethereum.org/2015/01/10/light-clients-proof-stake/

Title: Re: Mass Adoption for BiblePay II
Post by: Rob Andrews on December 05, 2018, 09:20:56 am
My only concern with using it on the POBH side is it directly competes with PODC..

PODC combines coins into one for the updates, so only folks not working on PODC could participate in POG, this would need to be addressed somehow.

Yes, and just to clarify, I was thinking something like this could go down:

We release our testnet version in a week (or whatever), with the following:
POBH is extended to be POG(utilizing POBH), and the small miner reward (of 600~) is actually the source of what is distributed in the pool (IE 20% of 600 is 120 that goes to the reaper, the remaining 80% goes in the pool).  PODC is left in an "ON" state. 

We test for a couple months and fit this particular environment into our mandatory release.

So in Prod, POG is basically utilizing heat mining budgets.

Then when we feel safe, we do a hard cutover.  (That is Disabling PODC and diverting its entire budget back into POG).  I havent studied the possibility of doing a slow cutover.  (I think the testing results + prod POG results would dictate a potential "cutover block" to remove PODC that could be fit into one single mandatory, if lucky - but this is definitely not something that I would rush).

I plan on putting extra metrics in testnet so we can reconcile every hash and bbp in the pool; this should make it easy to ensure the whole thing is square.






Title: Re: Mass Adoption for BiblePay II
Post by: thesnat21 on December 05, 2018, 09:46:26 am
Yes, and just to clarify, I was thinking something like this could go down:

We release our testnet version in a week (or whatever), with the following:
POBH is extended to be POG(utilizing POBH), and the small miner reward (of 600~) is actually the source of what is distributed in the pool (IE 20% of 600 is 120 that goes to the reaper, the remaining 80% goes in the pool).  PODC is left in an "ON" state. 

We test for a couple months and fit this particular environment into our mandatory release.

So in Prod, POG is basically utilizing heat mining budgets.

Then when we feel safe, we do a hard cutover.  (That is Disabling PODC and diverting its entire budget back into POG).  I havent studied the possibility of doing a slow cutover.  (I think the testing results + prod POG results would dictate a potential "cutover block" to remove PODC that could be fit into one single mandatory, if lucky - but this is definitely not something that I would rush).

I plan on putting extra metrics in testnet so we can reconcile every hash and bbp in the pool; this should make it easy to ensure the whole thing is square.

Fair enough,

I will say in practice the POBH rewards have been 420-480 average per block (I could give you more specific data if needed)
So it is a small piece of the pie.

Also, would it be possible to enable/disable PODC with a spork?  (leave the code in, do cutover after a certain block but have the ability to "back out" if we need/want to in the future).


Title: Re: Mass Adoption for BiblePay II
Post by: Rob Andrews on December 05, 2018, 10:01:53 am
Fair enough,

I will say in practice the POBH rewards have been 420-480 average per block (I could give you more specific data if needed)
So it is a small piece of the pie.

Also, would it be possible to enable/disable PODC with a spork?  (leave the code in, do cutover after a certain block but have the ability to "back out" if we need/want to in the future).

Thats OK, dont need it, because the heat mining reward (POBH) can just be used for the reward in testnet.  No problem.

On #2, I know that sounds good and I also thought of maybe, but I dont think we can do that.  I think we need a hard cutover when we go from PODC to no PODC (with a height) that will disable that particular feature, superblocks for it, and change the price. 

This is because the chain needs to stay synced and after about 5000 blocks in the future we cant rely on old masternode data to be around for prior blocklevel rewards.  (Thats why all the business logic if then else still exists every time we have a reward change - ie we break from block feature F11000 to 12000 to 13000 etc).

Title: Re: Mass Adoption for BiblePay II
Post by: Rob Andrews on December 05, 2018, 10:43:56 am
Mobile wallets don't keep a full copy of the blockchain, only headers and your own wallet's tx and utxo. This makes any PoS-like schema very hard to implement. PoG is different in concept but I'm afraid it shares this limiting factor with PoS.

There is a nice article here:
https://blog.ethereum.org/2015/01/10/light-clients-proof-stake/

No actually POG could work on mobile though, they just cant be a reaper- they can only be a sower/tither.  We can make the 'Tithe to Mine' button in the mobile wallet send an aged tithe, and that would get them in the pool for a reward.  They would receive part of the 80% pool weight.

As long as you can figure out the HD-wallets coin-age, coin-value, tithe-amount, and receive-address (which I know you can!) we can do it.

This would be pretty cool to have mobile wallets in a tithe pool.

The wallet would have to ensure it respects the current difficulty level of the round in order to successfully tithe though.

Title: Re: Mass Adoption for BiblePay II
Post by: Rob Andrews on December 05, 2018, 10:47:01 am
Hmm, we might need a second wallet for that then (unless a fix cannot be made).

By the way, being able to do POG on mobile wallets would be perfect :)

I'll think about this technically.  If we have a push to release a testnet version and its not addressed, please mention it in the testnet thread and Ill try to engineer something while we start testing v1.0.

Title: Re: Mass Adoption for BiblePay II
Post by: BBP537 on December 05, 2018, 02:54:37 pm
All I have to say is that if POG really IS the next "billion dollar idea", then a billion bucks could buy a lotta resources!  :D
Title: Re: Mass Adoption for BiblePay II
Post by: Rob Andrews on December 05, 2018, 04:16:58 pm
All I have to say is that if POG really IS the next "billion dollar idea", then a billion bucks could buy a lotta resources!  :D

I hope in the end we are the 'deflationary regauged smaller brother of Dash' that anyone can use or mine, and we have a technical feature that makes us stand out to be unique and through all this we end up being a utility (with real world uses - other than buying 1 bbp worth for a video upload tip).

Title: Re: Mass Adoption for BiblePay II
Post by: way2 on December 05, 2018, 04:33:30 pm
As someone who is considering investing money into the BIblepay system, I am looking for some help with lingering concerns.  Here are my questions for the developers and significant stakeholders (anyone with more than one master node):
1.    Which is more important to you: protecting investor value or protecting contributions to charities?
2.   Do you consider moving money into the Biblepay system to be an investment or a donation to a charity?
3.   Biblepay has already seen significant fundamental changes and is again considering more significant changes.  Can you provide any assurances that these changes will stop, or is frequent radical changes something that will continue to be typical for BIblepay?
Thank you in advance for your help!
Title: Re: Mass Adoption for BiblePay II
Post by: Rob Andrews on December 05, 2018, 10:38:03 pm
As someone who is considering investing money into the BIblepay system, I am looking for some help with lingering concerns.  Here are my questions for the developers and significant stakeholders (anyone with more than one master node):
1.    Which is more important to you: protecting investor value or protecting contributions to charities?
2.   Do you consider moving money into the Biblepay system to be an investment or a donation to a charity?
3.   Biblepay has already seen significant fundamental changes and is again considering more significant changes.  Can you provide any assurances that these changes will stop, or is frequent radical changes something that will continue to be typical for BIblepay?
Thank you in advance for your help!

Thanks, these are great questions.

#1.  They are both important, protecting investor value is a 10 (on a 1-10) and protecting charities is a 7.  Its not that the charities are less important its that we are dealing primarily with sponsorships with insurance.  But I clarify, imo protecting a "UTXO lockup rule" is not protecting investor value over the long term.  (Just as no one knows where our price will be in 6 months).  In my case I'm looking further out to what gives us a unique place in the market as a strong service with net daily newcomers and growth.

#2.  EDIT: From an SEC standpoint we are a utility (not an investment or a charitable donation).  We achieve this by renting business object space and striving to have a purchase api.  From a non sec standpoint if an existing holder were to give an opinion of one or the other -  that is a personal distinction you make yourself.

#3.  I think you will see changes that include:  following the Dash commit pattern for each new platform (IE a rebase for example after Evolution, and into the future) as long as we are c++ based.  You will see major features merged in, like an IPFS based Christian economy platform - however this is more like a bolt-in feature.  You will see us settle on and keep our mining algorithm without changes as soon as we are happy with a positive net daily growth pattern.  I feel that change now is less risky than a stagnant user base.  We will keep all working modules in the background, so for example, when things don't work we can revert back to what did work if we make a mistake.  I think POBH->PODC->POG is quite an unusual circumstance, but I think the chips will fall in the right places and we will stabilize and stay with our new base - as soon as net quantitative growth starts.  However, it is possible you might see something to do with proof-of-service, c# contracts and IPFS get merged into POBH/POG in the future in a way that compensates users for participating in a Christian content economy.  Some people view change as bad, but I am of the camp that change is good until we have our niche in the market - then stability is good.  We are finding our place currently.  Then we can cement ourselves as a Christian utility and work PR around it.

Title: Re: Mass Adoption for BiblePay II
Post by: 616westwarmoth on December 06, 2018, 11:36:19 am

Well in general this is good as the need for testing is critical, however we don't "lack the resources to adequately test it".

We need to put it in testnet, invite more than 8 testers (like 25), we need to cover every test case - and add every possible exploit.

To address the resource issue, it is possible to test it as what database programmers do (in the case of data management companies) is they write a stress test program and theoretically stress the system to exploit what conditions we think are missing - say for example we only have 10 testers, then we need to write a program to simulate the real life transactional activity of 250 users - then we would feel a lot better about it.

I think in addition to that we can phase this in two phases.  We go live with POG in POBH only then stay with it for a quarter and fix any critical issues before we attempt to transition from PODC to POG (during the second mandatory).

My issue is, and don't take as personal criticism, you've had multiple revisions on the system already.  And i feel that's been mostly been because of the loopholes I've found.  I still feel the current parameters are massively exploitable and will require a tremendous amount of work to circumvent that (and quite frankly, I think it's possible the only real solution to the exploits might require more centralization which many are not in favor of).

No matter how great a programmer you are (and you are a great programmer!) you won't be able to test situations you don't perceive.  So running a stress test will only show if the system could support 10,000 users behaving how you expect them to behave.  It won't be able to adequately test non-expected behaviors.  And I'm not even saying the ones TRYING to game the system, but if you have a lot of new users, they're going to do strange things due to ignorance.  And then you have an entirely different breed of non-expected behaviors from those playing within the rules and exploiting the system.  And finally, you have the edge case users, who actively exploit code to circumvent the system.  Something as novel as a new mechanism, not one we're plugging in from another coin, needs far more testing than we can give it at this time.
Title: Re: Mass Adoption for BiblePay II
Post by: Rob Andrews on December 06, 2018, 12:51:37 pm
My issue is, and don't take as personal criticism, you've had multiple revisions on the system already.  And i feel that's been mostly been because of the loopholes I've found.  I still feel the current parameters are massively exploitable and will require a tremendous amount of work to circumvent that (and quite frankly, I think it's possible the only real solution to the exploits might require more centralization which many are not in favor of).

No matter how great a programmer you are (and you are a great programmer!) you won't be able to test situations you don't perceive.  So running a stress test will only show if the system could support 10,000 users behaving how you expect them to behave.  It won't be able to adequately test non-expected behaviors.  And I'm not even saying the ones TRYING to game the system, but if you have a lot of new users, they're going to do strange things due to ignorance.  And then you have an entirely different breed of non-expected behaviors from those playing within the rules and exploiting the system.  And finally, you have the edge case users, who actively exploit code to circumvent the system.  Something as novel as a new mechanism, not one we're plugging in from another coin, needs far more testing than we can give it at this time.


Thanks, well actually I don't remember you finding any specific loopholes - I remember you asking about 10 different parts of POG that were not loopholes and me replying about those - then waking up the next morning and realizing we needed a tithe_cap and we needed to stop scripting attacks.    And then I gave credit to Jesus.  And those two are the last changes - and thats normal.  You know, this is not about you finding personal grandeur or becoming a hero for your personal achievements - this mission is about us finding our niche through innovation.

I think one core difference in our beleifs is you think BiblePay should be some perfect clone of an existing coin and that we are not capable of becoming our own crypto - while I starkly disagree and believe our place will be through innovation.

Next, I've already programmed in 99% of the test scenarios that we will need.  I disagree with your assessment 100%, and therefore I guess we will see what we see in testnet.

Title: Re: Mass Adoption for BiblePay II
Post by: way2 on December 06, 2018, 04:12:41 pm
Thank you for your answers to my questions Rob, that was extremely helpful!  I know they weren't easily answered and I appreciate your thoughtfulness and candor. 
Title: Re: Mass Adoption for BiblePay II
Post by: 616westwarmoth on December 06, 2018, 04:21:32 pm
I'm not asking for credit, I don't brag about my contributions to the coin.  I'm not trying to goad you into an argument.   I acknowledge your skills and have consistently done so.  I have never asked to be a clone of any existing coin, if you misread that, then here is what I was saying.  It's far easier to bring an existing system into a coin than it is to code it from scratch and  vet all the possible scenarios that exist in the logic.

The questions I asked were in my view at times exposing short falls in the system.  I still see several loopholes (and have stated a few of them) and don't agree with your assessment that we will be able to sufficiently test a brand new system as I feel we'd need a ten or more fold increase in testers which would mean nearly half our active users would need to test.   The issue is you seem to believe we will see a sudden influx of both testers and users.  If you have knowledge of a contingency waiting to come, the community would benefit from that knowledge.  However, I don't see the path to such increases.  Finally, I stand by my position that even the best programmer won't be able to test for conditions they've not thought of.
Title: Re: Mass Adoption for BiblePay II
Post by: Rob Andrews on December 07, 2018, 10:59:17 am
I'm not asking for credit, I don't brag about my contributions to the coin.  I'm not trying to goad you into an argument.   I acknowledge your skills and have consistently done so.  I have never asked to be a clone of any existing coin, if you misread that, then here is what I was saying.  It's far easier to bring an existing system into a coin than it is to code it from scratch and  vet all the possible scenarios that exist in the logic.

The questions I asked were in my view at times exposing short falls in the system.  I still see several loopholes (and have stated a few of them) and don't agree with your assessment that we will be able to sufficiently test a brand new system as I feel we'd need a ten or more fold increase in testers which would mean nearly half our active users would need to test.   The issue is you seem to believe we will see a sudden influx of both testers and users.  If you have knowledge of a contingency waiting to come, the community would benefit from that knowledge.  However, I don't see the path to such increases.  Finally, I stand by my position that even the best programmer won't be able to test for conditions they've not thought of.

Thank you West for this and I want to say that I want to work with you closely on  identifying and mitigating any potential issues you might see in POG, for the greater good. 

I'm glad to know that you agree that this is not about either me or you being the smartest or first analyst to discover a flaw, its about us making a solid product for BiblePay, and even if it means that we discover the product not ready, so be it, I wont have my feelings hurt.

I think I have quite a different perspective of the POG vulnerabilities from the code standpoint and I think it will be very valuable for us to try to see each others perspective over in testnet.

So lets meet over there and try to come up with any attack vectors.

Currently from my standpoint I view POG as solid- I only know of one type of attack vector (the ability for a whale to cash out a sanc, create a bankroll of 300 5000' bills manually) and use that as a POG tithe edge over others, however this particular attack is going to be mitigated - the user will have a new command available (exec bankroll), empowering them to do the same thing as a feature - and diff will rise above the min_coin_amount during this whale attack making it useless until diff drops (another words by empowering the user with the same feature - no one has an edge). 

  After this - from my standpoint I cannot see any potential attack, from any scenario covering 1 wallet to multiwallets, or whales to small fish, and thats what we need to cover in testnet.

The code is not ready yet but should be ready by the evening - Ill make a post on the main forum then lets all meet there.

 
Title: Re: Mass Adoption for BiblePay II
Post by: sunk818 on December 07, 2018, 03:38:22 pm
https://wiki.biblepay.org/Proof-of-Giving-II

What is min_coin_amount ? I understand max_tithe_amount but is min_coin_amount the change address needs to be in order to send the max_tithe_amount?

also, you mention default proclimit = 1 . Does this mean, this can be increased?

What happens if someone has a beefy computer with 128 threads. Can they use all 128 threads to mine? How does this affect the outcome? Won't they be the likely person to win the 20% and get a piece of the 80%?

Trying to understand how this is more green than PoDC?
Title: Re: Mass Adoption for BiblePay II
Post by: sunk818 on December 07, 2018, 03:41:36 pm
Also, what happens to the rest of the month, if someone donates the entire monthly ceiling on the first day via PoG? Or say they donate 90% in the first day, how does difficulty play out? Does this kick the coin_age requirement up so newcomers can not participate?

What happens if you donate to the foundation (using the wallet address not PoG) for the entire ceiling?
Title: Re: Mass Adoption for BiblePay II
Post by: Rob Andrews on December 07, 2018, 03:51:55 pm
https://wiki.biblepay.org/Proof-of-Giving-II

What is min_coin_amount ? I understand max_tithe_amount but is min_coin_amount the change address needs to be in order to send the max_tithe_amount?

also, you mention default proclimit = 1 . Does this mean, this can be increased?

What happens if someone has a beefy computer with 128 threads. Can they use all 128 threads to mine? How does this affect the outcome? Won't they be the likely person to win the 20% and get a piece of the 80%?

Trying to understand how this is more green than PoDC?

min_coin_amount is the minimum coin value that can be used for a tithe out of your coins.  If you go to coin control and take a look at your coins, pick one of higher value than min_coin_amount.

Change amount or change address doesnt come into play.

On genproclimit its set to 1 by default (as is now for POBH), but it can be increased if you want to be a reaper.  This is basically a solo miner with more threads.  Remember the reaper only gets 20% of the block however. 

On 128 threads, yes, except they will probably be competing against more pcs and laptops in this game (IE more exposure to the world), and also remember that its self defating to go higher in threads than 95% of your processor power (IE 20 threads probably gives you that utiliz. level).

Its more green than PODC like this:  With PODC,  We have 1 controller doing POBH per PODC user, and the equiv of 2000 (not exadurating) PCs out there doing PODC (I did the math on rac in POOM).  With POG, we have just 1 controller doing 1 thread per POG *user*, so its less energy per person, and in addition, we have some POG users only as sowers (not running as reapers).  I could have made it much greener with tier sleep levels, but I decided I wanted to error on the safe side (for anti 51% attacks) and let us go with beefier POW security so all POG users using the default genproclimit 1 actually mine right now.

Title: Re: Mass Adoption for BiblePay II
Post by: Rob Andrews on December 07, 2018, 03:57:09 pm
Also, what happens to the rest of the month, if someone donates the entire monthly ceiling on the first day via PoG? Or say they donate 90% in the first day, how does difficulty play out? Does this kick the coin_age requirement up so newcomers can not participate?

What happens if you donate to the foundation (using the wallet address not PoG) for the entire ceiling?

Great questions!

So first on donating the entire monthly ceiling on the first day, what would actually happen in the market microstructure, is as the original "pig" is trying to over-tithe, since we have a tithe_max of about 300 initially per tithe, after they donate about 5K lets say, the difficulty would skyrocket to something like 32000, and that would stop them (or slow them down) because now the max_tithe is only 30, so this person would not get very far.

As far as diff dropping, in the latter half of the day the diff would drop again.

You can get around the controls and donate directly to the foundation but if the tithe is not legal, the network wallet rules will not "induct" those tithes.  IE if someone tithes 10,000 by doing a sendmoney transaction it wont even be put in the pool.

You can type exec pogpool to see the exact mechanics as we go.

EDIT: Testnet is ready.


Title: Re: Mass Adoption for BiblePay II
Post by: 616westwarmoth on December 08, 2018, 03:01:15 pm
What is the formula for determining the three variables, Min_coin_age, Min_coin_amount and Max_tithe_amount?  I would like to better compute a few scenarios and exact-ish formula would be needed to do that.

Can an individual can tithe (can we please rename this to donate for our foreign users?) multiple times per day from the same wallet?  If so, does this tithe accumulate for the day, and for silly numbers, if they donated 10x 300 for 3000 and the rest of the users donated a cumulative total of 3000, would they then get half the reward?   How often is the difficulty calculated and is the monthly cap a rolling month or a 30 day fixed month?
Title: Re: Mass Adoption for BiblePay II
Post by: Rob Andrews on December 08, 2018, 03:30:44 pm
What is the formula for determining the three variables, Min_coin_age, Min_coin_amount and Max_tithe_amount?  I would like to better compute a few scenarios and exact-ish formula would be needed to do that.

Can an individual can tithe (can we please rename this to donate for our foreign users?) multiple times per day from the same wallet?  If so, does this tithe accumulate for the day, and for silly numbers, if they donated 10x 300 for 3000 and the rest of the users donated a cumulative total of 3000, would they then get half the reward?   How often is the difficulty calculated and is the monthly cap a rolling month or a 30 day fixed month?


On #1 :

// Tithe Parameter Ranges:

// min_coin_age  : 0 - 60 (days)
// min_coin_amount : 1 - 25000
// max_tithe_amount: 300 - 1 (descending)

The exact formula for min_coin_age:

Given the Tithe_Cap (410987 per month in testnet), take the total 24 hour donations divided by tithe_cap:  donations / tithe_cap, arrive at a Percent_Donated.  Multiply that percent * ceiling(0,60) (in this case the 60) and add that to the floor (0).  So another words, 50% donations mean min_coin_age 30.

For the min_coin_amount do exactly the same thing as above (compute a donation % for the current time) and then multiply * 25000, giving you for example 12,500 if we had 50% donations.

For max_tithe_amount descending, do exactly the same thing as above (compute a donation %), except now subtract it from 300 as this one is descending.


Let me answer the other question in the next post.



Title: Re: Mass Adoption for BiblePay II
Post by: Rob Andrews on December 08, 2018, 03:34:16 pm
What is the formula for determining the three variables, Min_coin_age, Min_coin_amount and Max_tithe_amount?  I would like to better compute a few scenarios and exact-ish formula would be needed to do that.

Can an individual can tithe (can we please rename this to donate for our foreign users?) multiple times per day from the same wallet?  If so, does this tithe accumulate for the day, and for silly numbers, if they donated 10x 300 for 3000 and the rest of the users donated a cumulative total of 3000, would they then get half the reward?   How often is the difficulty calculated and is the monthly cap a rolling month or a 30 day fixed month?

A user can tithe an accumulating amount per day - yes.  If I donate 100 in hour 1, and 200 in hour 2, the pool will show 300 from Rob for todays span.

The total donated drives the tithe_weight per user.  So I dont know what you mean by half, but if I had 1000 in donations that would be a 10% share weight if you had 100 in donations you have a 1% share weight relative to me. 

The difficulty is calculating once per block, and we have a fixed day span of 205 blocks being regarded in the pool.  We really don't ever reset the pool however since the chain always rolls forward - on block #206, block #1 is forgotten.  So on block #512, biblepay is regarding block 256-512 as the PogPool blocks in the window.

Title: Re: Mass Adoption for BiblePay II
Post by: 616westwarmoth on December 08, 2018, 03:44:19 pm

On #1 :

// Tithe Parameter Ranges:

// min_coin_age  : 0 - 60 (days)
// min_coin_amount : 1 - 25000
// max_tithe_amount: 300 - 1 (descending)

The exact formula for min_coin_age:

Given the Tithe_Cap (410987 per month in testnet), take the total 24 hour donations divided by tithe_cap:  donations / tithe_cap, arrive at a Percent_Donated.  Multiply that percent * ceiling(0,60) (in this case the 60) and add that to the floor (0).  So another words, 50% donations mean min_coin_age 30.

For the min_coin_amount do exactly the same thing as above (compute a donation % for the current time) and then multiply * 25000, giving you for example 12,500 if we had 50% donations.

For max_tithe_amount descending, do exactly the same thing as above (compute a donation %), except now subtract it from 300 as this one is descending.

Thanks for the quick reply!
Title: Re: Mass Adoption for BiblePay II
Post by: jmmc on December 15, 2018, 03:41:18 am
Can we keep both PoBH and POG ? To me, more mining options is better.
Title: Re: Mass Adoption for BiblePay II
Post by: thesnat21 on December 15, 2018, 06:31:54 am
Can we keep both PoBH and POG ? To me, more mining options is better.

We will always have both,  POG will take 80% but the plan was POBH would earn 20% (block miner)
Title: Re: Mass Adoption for BiblePay II
Post by: Rob Andrews on December 15, 2018, 11:53:16 am
We will always have both,  POG will take 80% but the plan was POBH would earn 20% (block miner)

Exactly, this way solo mining pays 20% but the lions share of the pool is in-client. 

Note that I think it would be a really good idea for us to test POG in prod with POBH only (as we all agreed on so far) and write down exactly how many pool miners (in POG) we see per day - for example a pool.biblepay.org report that pulls in the exec pogpool stats in SQL so we can make a graph.  It would be very valuable to see if POG results in a daily increase in biblepay use. 

Of course we can just add pog diff to the current difficulty chart also.

Title: Re: Mass Adoption for BiblePay II
Post by: sunk818 on December 16, 2018, 12:26:20 am
I can appreciate the complexity of pobh podc and pog coexisting. If I read your last post right you want to remove podc altogether? That's a bit much and I think pog podc combo is better. Or all three (pobh podc pog).

Podc is has big participation rate so it deserves a slow curve to reduced payments. Maybe if there are sports to pobh podc and pog rewards the rewards can be tweaked slowly.

Big changes scare of investors.

 This is partly why I asked if pog rewards can contain send bbp transactions as well.
Title: Re: Mass Adoption for BiblePay II
Post by: Rob Andrews on December 17, 2018, 10:14:33 am
I can appreciate the complexity of pobh podc and pog coexisting. If I read your last post right you want to remove podc altogether? That's a bit much and I think pog podc combo is better. Or all three (pobh podc pog).

Podc is has big participation rate so it deserves a slow curve to reduced payments. Maybe if there are sports to pobh podc and pog rewards the rewards can be tweaked slowly.

Big changes scare of investors.

 This is partly why I asked if pog rewards can contain send bbp transactions as well.

It was made clear that the sanc poll for the ideas acceptance was to replace all of our mining algorithms with pog (for easy adoption).

I'm definitely thinking we would go through a full test phase with POG as the heat mining algorithm, and PODC still existing.  POG gets the heat payment rewards.

Yes, a lot of things scare investors, including stagnating by one user a day and relying on an oracle.

I'm open to ideas about how POG + PODC could coexist (maybe 20% emission to PODC, 80% to pog) for example.  (I would not talk about POBH by itself - its being replaced by POG in testnet and its underlying technology is definitely POBH).  However even if PODC lasts a while, it doesn't make sense to pile massive infrastructure and support into something that might go away.  The moment it breaks, if POG is doing the job then maybe PODC should be retired at that point.  Who wants a half finished UI with broken parts for easy adoption in the PODC if its not going to be used fully.  So imo, the test for POG (as far as easy adoption) should be taken very seriously, and if it works that way (1 new user + per day) then I would consider the next logical step Removing all the unecessary IT code, and becoming a gospel coin like we should be doing in the first place.  Like putting some preachers in the wallet and preaching to users, and a Getting Saved button for example.  And a Getting Saved chat room.  Who will do all that if they are spending all day supporting scientists?


I don't know what you mean by "send transactions with pog", could you explain that in more detail?

Title: Re: Mass Adoption for BiblePay II
Post by: 616westwarmoth on January 02, 2019, 04:59:05 pm
I still believe converting the Masternode rewards to a daily super block would 1) not be a radical change that would scare off current users 2) be beneficial for new users who would get quicker feedback on if they set things up correctly (as in theory, if we hit 1000 MN in the next two years, someone could wait almost a week before getting a reward and during that time could stress out if they had done things right) and 3) stabilize the rewards by removing chance (all MN would earn equal rewards that would be 1/# of MN of the total block versus the current system where rewards vary by as much as 15% between blocks due to DGW difficulty adjustments and the occasions where one MN gets rewarded in back-to-back blocks).

As the logic for a daily superblock is built and works, it would seem like you could maybe prototype that in reasonable time frame.
Title: Re: Mass Adoption for BiblePay II
Post by: sunk818 on January 03, 2019, 03:07:23 pm
> I don't know what you mean by "send transactions with pog", could you explain that in more detail?

PoG reward would be like a mined block where the reward contains transactions from the mempool like a PoW mined block.