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.

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.

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

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

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.

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.

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.

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!

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

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!

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.

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.

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.