Mass Adoption for BiblePay II

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

[Rob Andrews]

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.

[Rob Andrews]

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.

[Rob Andrews]

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.

[jmmc]

Can we keep both PoBH and POG ? To me, more mining options is better.

[Rob Andrews]

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.