Bible Pay

Read 415682 times

  • togoshigekata
  • Hero Member

    • 527


    • 31
    • September 01, 2017, 10:21:10 AM
    • USA
    more
Biblepay
1.0.9.2-Mandatory Upgrade for TestNet


- Add Spork for Team Biblepay Requirement for PODC
- Enforce Team requirement in PODC Contract
- Add PODC Difficulty Measurement for getmininginfo, and add exec podcdifficulty RPC command
- Extend instantsend signing timeout to allow higher transmission amounts
- Increase PrivateSend Mixing Denominations by 1000
- Add team value and warning to exec getboincinfo
- Added exec leaderboard

** Windows is Compiling **

Yeah, this version has really shaken things up...

Can you all please upgrade to 1092c now.... and try syncing again please.

Windows is rebuilding now...

Got one sanctuary updated and running and the other is still updating :)


  • T-Mike
  • Sr. Member

    • 375


    • 2
    • February 06, 2018, 06:12:58 PM
    more

Yeah, this version has really shaken things up...

Can you all please upgrade to 1092c now.... and try syncing again please.



Windows is rebuilding now...

Rob, appears to be working good now. Great job!


  • Rob Andrews
  • Administrator

    • 4097


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Got one sanctuary updated and running and the other is still updating :)

Great!  Were you going to enter a proposal to vote on the team requirement, or are we going with it?

It might be a good idea, so that is part of the accepted transition of power to PODC.



  • togoshigekata
  • Hero Member

    • 527


    • 31
    • September 01, 2017, 10:21:10 AM
    • USA
    more
Im pretty neutral, Id have to think about it more and also check Gridcoin and their pros/cons of the team requirement

I have 2 testnet sanctuaries up!


  • T-Mike
  • Sr. Member

    • 375


    • 2
    • February 06, 2018, 06:12:58 PM
    more
Im pretty neutral, Id have to think about it more and also check Gridcoin and their pros/cons of the team requirement

I have 2 testnet sanctuaries up!

Honestly, I didn't really want everyone flooding in to take a share of the pie, but that's just being greedy. So if helping with cancer research is our top goal, then it doesn't really matter if people are double dipping or triple dipping. Now if we want to advertise ourselves, we could always use the combined RAC and have a counter on the website. I think there is more to think about here so we should let it churn a little more.


  • Rob Andrews
  • Administrator

    • 4097


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Im pretty neutral, Id have to think about it more and also check Gridcoin and their pros/cons of the team requirement

I have 2 testnet sanctuaries up!


Ok cool.

So on the superblock creator in prod, I originally convinced myself that dash-central hidden PHP created the superblocks, LOL, so that particular weekend, I wrote the superblock hex creator, hence the reason we arent using the watchman superblock creator that ranks the proposals by vote descending .

So I took a look at that function and I think it looks pretty valuable, so Im going to work on enabling it in testnet over the next few days.  It appears we have two changes necessary to make it work:  1) The biblepay address validator needs one character updated in Watchman, and the superblock proposal ranker requires proposal start and end dates to be really exact, unbelievinably exact, so we need to change the code to allow a fudge of like a week for the target superblock (since we have slow blocks in prod), so Ill make these two changes, then we will need to update our Testnet watchmen, restart them, and create a testnet proposal in the pool.

Ill update more on this as I get closer to being ready to test it.

The advantage here is I believe the triggers will create themselves, and vote on themselves (IE we may not have to vote on the budget anymore).  I think I created that process inadvertently (thinking we had to), but we shall see.



  • Rob Andrews
  • Administrator

    • 4097


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Anyone waiting for Windows version in testnet:

1092 is now available.



  • togoshigekata
  • Hero Member

    • 527


    • 31
    • September 01, 2017, 10:21:10 AM
    • USA
    more

Ok cool.

So on the superblock creator in prod, I originally convinced myself that dash-central hidden PHP created the superblocks, LOL, so that particular weekend, I wrote the superblock hex creator, hence the reason we arent using the watchman superblock creator that ranks the proposals by vote descending .

So I took a look at that function and I think it looks pretty valuable, so Im going to work on enabling it in testnet over the next few days.  It appears we have two changes necessary to make it work:  1) The biblepay address validator needs one character updated in Watchman, and the superblock proposal ranker requires proposal start and end dates to be really exact, unbelievinably exact, so we need to change the code to allow a fudge of like a week for the target superblock (since we have slow blocks in prod), so Ill make these two changes, then we will need to update our Testnet watchmen, restart them, and create a testnet proposal in the pool.

Ill update more on this as I get closer to being ready to test it.

The advantage here is I believe the triggers will create themselves, and vote on themselves (IE we may not have to vote on the budget anymore).  I think I created that process inadvertently (thinking we had to), but we shall see.

Awesome!


  • togoshigekata
  • Hero Member

    • 527


    • 31
    • September 01, 2017, 10:21:10 AM
    • USA
    more
One request that I would like to see considered.  Require team Biblepay to receive rewards.

Currently, we are open to exploit by a botnet.  Its believed we are losing a large and measurable percentage to botnet(s) and it's not inconceivable it could exceed 50% with little difficulty, since this is what Monero, the hybrid CPU/GPU coin is suspected to be at.

Right now, Team Biblepay is 76th, with RAC of 30K, the top team is Team Gridcoin with 4.8M RAC.  I understand the desire to reach out and open the door for more users, but I worry that the current proposal of allowing anyone to receive rewards regardless of team, allows for Gridcoin users to effectively get credit at Gridcoin as well as at Biblepay for no more work (since they can be Team Gridcoin for Gridcoin rewards, and use just their user Account Key to get BBP).  Since Gridcoin users are on some level participating in R@h for Cryptocurrency rewards, it seems reasonable to think many, if not most, will gravitate to BBP since they can buy 1 BBP to receive rewards.  If, and I say IF, they are there solely for the reward and we cannot minister to them, then they are no better to our core users than the botnet.  If we reached the 1% ranking, we'd have roughly 100K RAC, if 25% of the Gridcoin users started with BBP, they'd have 1M RAC, and so if we could not convert them as genuine users, we'd be back to a 10% - 90% split with the majority of the coins going to people outside our user base.  Additionally, by not requiring team Biblepay membership, we lose a valuable asset which is the PR benefit from the overall ranking on R@h which could very easily be top 10 to maybe top 5 in a very short period of time.  Because without requiring to be a part of team Biblepay, most of our users I believe will end up on team Gridcoin as that would make the most financial sense.

I believe the goal to move to PoDC is a good one.  This particular piece of the puzzle however, I am concerned about and think needs addressed before the implementation.

In the end, the question to me boils down to, are there many R@h users we can reach out to that would not join us if they had to leave their current teams.  If so, can we reach more users with our own higher ranking team?

Yes, you have valid concerns.  I have always actually been on the side of the fence where the least the researcher can do is join the team in order to receive rewards.  I have held Rob Halfords perspective on double dipping, back when Ripple offered a chance to receive Ripple rewards for boinc users, if they crunch a certain project- at that time one of the same projects Gridcoin users crunched.  The rule in Gridcoin was those users must be within the team in order to receive rewards, and that prevented double rewards from both Ripple and Gridcoin.

However I saw a lot of scalability arguments against the team requirement and I guess I originally thought, hey lets solve that problem with Biblepay!  Lets make a feature where we have unlimited scalability and open the door to the massive Boinc Userbase (of over 1 million accounts).  So, under the hood Biblepay is now prepared for that.  We can literally handle the entire Boinc userbase if necessary (it requires us to increment a flag to send out multiple superblock payments per day, but we dont have to monkey with that feature until we have more than 32767 researchers on board).

But honing in on this issue Ive actually always been on the side of the fence where a miner should provide some value for us, and with that, they receive rewards, and have more of a propensity to buy and hold BBP for the long term - and be a loyal user (in contrast to a miner who comes and uses us, and pumps n dumps the coin).

So, in light of that view, I think we need to support requiring the team in order to mine biblepay.  We still support unlimited users, but the user must jump in and modify the team from the Rosetta account and join our team to receive rewards.

This way, when we go live, we will not only eliminate the botnet, but we will only have loyal users pulling slices of the BBP pie per day.  This will allow us to grow slowly in an organic Christian way, we can reach out to small swaths at a time and promote Christian values and see if we scare them away.

Great idea, Im going to add two features to the core client:
1) A system wide spork, to hold the Team Required Value (our team=15044 btw, Biblepay).
2) If the spork is active, PODC payments require Team Biblepay
3) The SanctuaryQuorum will be modified to log the users team in the contract
4) The exec getboincinfo will be modified to display the team, and display a corresponding warning if the team is required, enabled, and the user is not part of the team:  Warning - This CPID is not part of team Biblepay - This CPID is not receiving rewards for research work

Biblepay
1.0.9.2-Mandatory Upgrade for TestNet


- Add Spork for Team Biblepay Requirement for PODC
- Enforce Team requirement in PODC Contract
- Add PODC Difficulty Measurement for getmininginfo, and add exec podcdifficulty RPC command
- Extend instantsend signing timeout to allow higher transmission amounts
- Increase PrivateSend Mixing Denominations by 1000
- Add team value and warning to exec getboincinfo
- Added exec leaderboard

** Windows is Compiling **

Hmmm I thought we wanted to avoid having a team requirement?
so that anyone can mine Rosetta without having to leave their research team?

Im pretty much okay with Gridcoin users getting BiblePay and Gridcoin,
but given the incentives in place for that, It would be in my best interest as a researcher to end up joining Team Gridcoin so I could get the rewards for both Gridcoin and BiblePay

What other possible solutions are there?

I think the only way to handle this is to put a poll in for it...  Im relatively neutral, and now leaning towards requiring the team so that we dont give away all our rewards to every stranger so quickly.  But I can see part of the other side, where we want to appeal to the masses. 

Could you create a forum topic and put a proposal vote in for it?  Maybe for 2500 BBP so that you get reimbursed for the proposal?

Then I guess whatever way it ends it ends.

The code in testnet is set up so the team can be disabled if we set the team spork to 0.

Were you going to enter a proposal to vote on the team requirement, or are we going with it?

It might be a good idea, so that is part of the accepted transition of power to PODC.

Im pretty neutral, Id have to think about it more and also check Gridcoin and their pros/cons of the team requirement

Honestly, I didn't really want everyone flooding in to take a share of the pie, but that's just being greedy. So if helping with cancer research is our top goal, then it doesn't really matter if people are double dipping or triple dipping. Now if we want to advertise ourselves, we could always use the combined RAC and have a counter on the website. I think there is more to think about here so we should let it churn a little more.


  • togoshigekata
  • Hero Member

    • 527


    • 31
    • September 01, 2017, 10:21:10 AM
    • USA
    more
"As a long term BOINCer, I know may users are very dedicated to their teams, and would never change. If we waived this requirement the number of GRC users will increase significantly." -Fuzzy Duck

"I don't think that if we delete this requirement, BOINC projects will get more crunchers. It would be much more important to bring Bitcoiners and Alt-coiners (=non boincers) to Gridcoin. For such people, the team requirement wouldn't be a problem" - DC7D

"The main reasons I'm in favour of removing the requirement is because of the 'team poaching' issue when discussing Gridcoin on BOINC team forums/Tech forums (very negative reactions to team poaching derails any discussion of gridcoin with potential target audience), and beause I believe it may increase the effectiveness of boincstats advertising

"On one hand sure recruiting existing BOINC users to gridcoin isn't introducing new users to BOINC, but if existing users can offset the cost of electricity they may be able to justify increasing their computing capabilities for BOINC" -C.M

"at first after deleting the requirement, existing users will get less GRC due to the (significant?) increasing number of new members. Therefore, maybe some will stop crunching," -DC7D

"The number of GRC earned via PoR will reduce. However, the value of the GRC will increase due to supply and demand" -Fuzzy Duck

https://cryptocurrencytalk.com/topic/44260-discussion-mandatory-team-gridcoin-membership-requirement/?page=2&tab=comments#comment-206758

https://cryptocurrencytalk.com/topic/44260-discussion-mandatory-team-gridcoin-membership-requirement/?page=2&tab=comments#comment-206789

https://cryptocurrencytalk.com/topic/44260-discussion-mandatory-team-gridcoin-membership-requirement/?page=3&tab=comments#comment-207164

"If we remove the team requirements we won't be able to determine what percentage of all Boinc work Gridcoin participants are donating"

==

"I've thought about it for a while and came up with this possible solution: how about not changing Gridcoin but BOINC? By letting the BOINC user join two teams instead of one people could easily stay in their beloved team and join Team Gridcoin beside it. This way they can continue to crunch for their teams and earn"

==

https://www.reddit.com/r/gridcoin/comments/6mq3tu/new_blockchain_poll_impact_to_price_of_grc_if/dkdisz0/

https://www.reddit.com/r/gridcoin/comments/6mq3tu/new_blockchain_poll_impact_to_price_of_grc_if/dkdo1b8/

==

"What will really happen to the price of GRC if the team requirement is lifted?

The common belief by people who want to see the team requirement lifted is that we would be unlocking the growth potential of Gridcoin mining, and since miners have various incentives to hold GRC (voting weight, frequency of staking, interest) we should see increased demand for GRC and thus increased price


What is the argument for why the price of GRC might be reduced if the team requirement is lifted?

NeuralMiner believes that by adding potentially thousands of pure "mine and dump" type miners who don't care about Gridcoin as a currency, we will actually increase selling pressure of the coin because these miners will be minting some of the coins that "mine and HODLers" like NeuralMiner and myself currently receive on a daily basis.

I thought that was a very intelligent point, and it is well-taken. My counter-argument.... really more of a counter-question was: for every 100 "mine and dump" type miners, how many "mine and HODL" type miners will we potentially add? How many people might we add (like myself) who will invest their own money into the coin?"

==

https://steemit.com/gridcoin/@cm-steem/gridcoin-s-mandatory-team-requirement-should-it-stay-or-should-it-go

"2. To prevent BOINC users from "Double-dipping"
During the early days of Gridcoin's existence (before the introduction of the team requirement), Ripple was distributing Ripple to BOINC users within their Ripple Labs team.

We found that several users crunching for the Ripple Labs team were also claiming Gridcoin rewards. This discovery was negatively perceived as "Double-dipping" (getting rewarded twice for their work done), and was leading motivation for the introduction of the mandatory team 'Gridcoin' requirement to prevent this occurring again in the future.


Statistics websites are obsolete, we have a Neural Network!
We now store all of the important statistics within the client (NN), so when asked how much BOINC computation is being rewarded by Gridcoin we can simply point them towards neural network statistics instead of towards our team statistic pages on Boincstats."

=================================================

References:

https://cryptocurrencytalk.com/topic/44260-discussion-mandatory-team-gridcoin-membership-requirement/

https://docs.google.com/document/d/15sEYTzJIROmReCWGAQTZie0Il7NIURUANozKYhR8gus/pub

https://gridcoinstats.eu/poll/technical_poll_:_what_should_we_do_regarding_the_mandatory_team_requirement

https://github.com/Erkan-Yilmaz/Gridcoin-tasks/issues/94

https://www.reddit.com/r/gridcoin/comments/6mq3tu/new_blockchain_poll_impact_to_price_of_grc_if/

https://www.reddit.com/r/gridcoin/comments/41efuo/discussion_mandatory_team_gridcoin_membership/

https://steemit.com/beyondbitcoin/@xaqfields/the-great-debate-lifting-the-gridcoin-team-requirement

https://steemit.com/gridcoin/@cm-steem/gridcoin-s-mandatory-team-requirement-should-it-stay-or-should-it-go
« Last Edit: February 18, 2018, 03:55:39 AM by togoshigekata »


  • jaapgvk
  • Hero Member

    • 558


    • 31
    • September 01, 2017, 08:02:57 PM
    • Netherlands
    more
Thanks for compiling that list Togo. It doesn't make the decision easier for me, but it does give me more perspective :)


  • togoshigekata
  • Hero Member

    • 527


    • 31
    • September 01, 2017, 10:21:10 AM
    • USA
    more
Overall it seems like the Gridcoin community is split on the issue, and there are good points on both sides of the debate

Im still on the fence


  • Rob Andrews
  • Administrator

    • 4097


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Overall it seems like the Gridcoin community is split on the issue, and there are good points on both sides of the debate

Im still on the fence

Basically, to summarize the pros and cons, and remove wives tails:

By enforcing the team, we provably become a boincstats competing force, a driving team with more total RAC on the aggregator sites, and more credibility (from an auditing perspective), and we are not open to the masses receiving a piece of the 1.3MM daily pie, without joining the team.  There seems to be more of a propensity of being a loyal BBP community member if one were to join the team.

By not enforcing the team, we provide more free PR for the coin, because the word will spread all by itself, hey you can receive BBP by Rosetta mining, you dont even have to change your team.  The issue is we will receive thousands of researchers who are loyal to places like US Navy and Overclocking forums,  and we worry that maybe they will mine-n-dump us.  The wives tail here is they are crashing the coin because they are using us and not investing long term, but in reality they are potentially providing selling pressure on our price and that means others can *buy* BBP cheap with this effect.

So it really is a 50-50 hardline deal.    (IE its 0 compensation for non team members as is now).


« Last Edit: February 18, 2018, 09:03:30 AM by Rob A. »


  • Rob Andrews
  • Administrator

    • 4097


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
I recommend that we keep enforcing the team for now. 

Swongle is posting in the PODC consensus algo thread some lower risk attack vectors that GRC, Boinc, Asics and bitcoin go/went through, and so far from a high level, these are all already known and accounted for in Biblepay in this PODC algorithm, however I dont think its a good idea to open the floodgates for every single boinc user at this time until we address those in more detail over time.

I do however think the system is solid enough for a March go live, for our community and members of team biblepay.

What I think we should do however, is address the finer issues raised and become the first cryptocurrency to actually Solve the problem.  Lets make PODC computing secure and trustable to the 99% level - above where it currently is (in the 90% trust level).

It sounds to me like the only relevant attack vectors raised have to do with: sql tampering for boincside credit falsification (lying about work performed), 3rd party workunit validation (Rosetta being stood up at gunpoint to validate all workunits), centralization (a centralized authority validating workunits).

RISK 1 - CENTRALIZATION:

I believe we have overcome the centralization risk, based on a 99.9% uptime of boinc/rosetta, since both entities have multiple servers on each level, my assumption here is we can deal with a day of downtime while executing our disaster recovery plan (we enter DR mode when boinc or rosetta is down).  We live with a day of downtime a year (as a crypto), since we have POBH for front line block security.  The overall good work outweighs the bad single day of outage, and the net result is we have a year of cancer research in exchange for a day of downtime centralization risk.  This is why I summarize this particular risk to be mitigated.  In addition, if we do create a concentrated cancer proxy account, centralization risk drops even further.  (This would be to anonymize cancer tasks).

TRUSTING A THIRD PARTY FOR WORKUNIT VALIDATION:

I believe this is an accepted and fundamentally known requirement for a project like Rosetta, because the software is client server, meaning it is so complicated, it is developed by 150 scientists and hundreds of programmers, each module is testing protein folds and compiling the results in a way that can only be checked by the corresponding closed source server validation system.  There is no way to keep up with an opensource version of the software to validate workunits without creating more hacking vectors.  I view this as a low risk and a known tradeoff to use a high level analysis program for mining.


WORK UNIT TAMPERING:

Im sure there are many potential risks here, from coercion and corruption inside Rosetta, coercion at gunpoint, tampering of the SQL database, mass credit validation, however, the key here lies in catching a forward only anonymous system in a tampered state.  Right now we know the state of the researchers total credit as they ask for more work.  I think we can solve this problem by detecting when a CPID-MachineID total credit changes in a way that is tampered, and mark it as Broken and cancel it until the CPID is reset.  Right now we rely on Rosetta telling us the truth about : Work unit Is validated, How long it took, Credit rewarded, and BOINC calculates the RAC based on all that info.  We can only detect tampering from the standpoint of do the numbers roll up.   This is the one area where I think we can make a difference by investigating the potential idea of proxying and anonmyzing cancer tasks through a sanctuary, having the sanctuary reward a static reward (not based on task duration, based on Rosettas validation call).  That would eliminate the "lying" vector on task duration by machine.  I view this risk as the only relatively weak risk in the system and one that we should address over the long term.

EDIT:  So Im auditing the inner workings of the Rosetta task to see what kind of "lying vector" risk we have for RAC awarded per task.  I see the Rosetta cancer server gives each researcher a 400 megabyte database of protiens and a lot of medical tables with strange names for each molecule and the results are sent in base64 encoded format with rows per protein decoy and energy to be analyzed on the server side.  The great news is, I see Rosetta rewards are based on how many protien decoys are generated - but not specifically based on the CPU time required to generate the decoys - meaning that some workunits yield more credit than others, but credit cant be exaggerated due to long processing times.   This means that we have one less thing to worry about in that respect - we only need to monitor the validation event per task, and monitor the credit delta changes.   

« Last Edit: February 18, 2018, 10:28:01 AM by Rob A. »


  • togoshigekata
  • Hero Member

    • 527


    • 31
    • September 01, 2017, 10:21:10 AM
    • USA
    more
./biblepay-cli getinfo

"errors": "Warning: We do not appear to fully agree with our peers! You may need to upgrade, or other nodes may need to upgrade."

Im seeing this on both of my testnet sanctuaries