Mass Adoption for BiblePay II

[MIP]

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/

[Rob Andrews]

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.

[Rob Andrews]

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

[Rob Andrews]

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.

[Rob Andrews]

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.

[BBP537]

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! 

[Rob Andrews]

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

[way2]

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!

[Rob Andrews]

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.

[Rob Andrews]

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.

[way2]

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. 

[Rob Andrews]

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.

[sunk818]

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?

[sunk818]

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?

[Rob Andrews]

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.