TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)

[Rob Andrews]

Hey All,

I'm reviewing the logs and have discovered something critical that we need.

This is excellent because it explains why we had so many problems originally coming to a consensus, and I knew something had to be missing for the nodes to behave this way (IE share only half of their gobjects then create their own).

There is a setting missing that is causing a rate overflow when we share data. 

I will look into fixing this today.

[Rob Andrews]

So as a sneak preview as to what we are trying to accomplish in Evo with campaigns, one of the themes I'm going to introduce in the next Evo nutritional information guide is "BiblePay - Bearing Fruits".

This quantifiable measurement of Bearing Fruit can potentially be accomplished by fostering user activity that bear fruit, such as Healing on the street, Spiritual Warfare campaigns, spreading the gospel, reading the bible, etc. 

It will be a long discussion to find a way to "prove" that one actually bears fruit, but in this next revision, what we will do is place the lions share of the payment weight on hard-consensus rules (IE possibly 90% of the reward % goes toward things like stake-weight or foundation donations) but the remaining percent may possible be voted to go towards bearing fruit another way - healing on the streets, keeping a diary of entries, promising in a contract that a CPK is doing what a CPK claims, and reputation scores.  (Towards the end of the year, users who are caught lying or seem to be anti-Christ can be voted down by others and this will ruin their reputation scores, so the non-hard-consensus earnings get to be more accurate).

To test this out as a guinea pig in Evo, Im going to create a Healing campaign.
(This will also allow us to test multiple campaign payment mix percentages at once- allocation to Healing, and allocation to POG) - since we will have 2 campaigns.  I think in testnet we will make POG 95% and Healing 5% (to satisfy the non-provable component).

In essence Healing is when a person goes out on the street and prays for a total strangers illness or medical condition.  They keep a diary of the persons name and the outcome (and if a video is possible they make a video).

Later in the night the person must type this into biblepay in the diary area of the campaign (only if they are member of Healing).  The system will store this in the blockchain as a GSC-Healing-Transmission with a certain % of stakeweight attached and the Diary note.

This campaign for example might be 5% of the daily rewards.  The user with a diary entry receives a future slice of the daily payment for that particular campaign.

I have reached out to Torben Sondergaard to try to Partner with TLR (The Last Reformation).  He has responded to me (Im actually a street healer already, and Ive been through the kickstart and go out weekly and pray on the streets etc -- and Ive seen miracles occur -- regulary now).  I am waiting to find if Torben will allow us to partner with him.  If so we will make this relationship much more professional.  Otherwise, we can ask him for permission to use "Like TLR" for our brand of healing.  If that fails, we can discuss making our own campaign.

Once this is released Ill explain how to test this.

We should have phase 1 ready today.

[Rob Andrews]

1.4.1.3-Mandatory Upgrade for TestNet

- Remove more log spam
- Add Anti-GPU function phase 1 (not enabled yet)
- Increase GSC sharing capability (increase gov rate limits)
- Enhance exec prominence to show point details by campaign, then totals
per user
- Add ability for Sancs to calculate points from multiple campaigns
- Add configurable tithe and coin-age per campaign per user setting
(with spork defaults)


* Ill post more on how to test the Healing campaign *

Regarding our gobject syncing, we should see a more consistent exec health report in 50 blocks or so if we are successful in fixing the issue.

[Rob Andrews]

I just want to mention, this is our first release with a soft-consensus change to the Sanc side, meaning this exercises our ability to release a point-calculation change to the payment algorithm without breaking the prod chain.

So in this case exec health will be wrong until over 51% upgrade to the new version (this is because the contract creator changed, so as sancs upgrade, the actual contents of the contract will change).

Once we get the upgrades, the exec health warning will dissapear.

[Rob Andrews]

So from a very high level, the plan for the Healing campaign is to create a workflow, where the user  :  Joins, accepts critical documents and signs off, makes diary entries, sends healing transmission records, and then receives payments.

The flow will most likely be like this:  User types 'exec join HEALING', BiblePay sends them a URL with a PDF (explaining what they are getting into), User authorizes acceptance of the terms, User is now enrolled,  User sends a diary entry each time they heal by going to Send Money, typing it in the Diary text memo box, click the Diary checkbox, Select the Campaign Name (Healing), Click Send, .01 BBP is sent out (with a Healing stake in the transmission), the user can read the diary by double clicking on the txlist-tx.  On the server side, we assess the diary text entry as a valid source of Points.


In this rudimentary version today, all we have is the campaign, and a generic stake transmission for healing.

To get started please do this:

exec join HEALING

<BiblePay says true>

exec sendgscc true
(This is force)

Wait for next superblock - check exec prominence - see if we receive revenue from Healing.

Tomorrow I will work on the Diary entries.

[Rob Andrews]

Another side project:

Please refer to the prior post about entering watchman-on-the-wall proposals.
Id like to perform a more elaborate test (one with at least 10 proposals).
Lets wait until block 14350 (the monthly superblock) passes before we start.
Lets add some complicated figures that total more than 4.5 mm biblepay, and lets stress test watchman for the following monthly governance superblock.

[vuli]

I cant  see what is in Proposals tab anymore.

[Rob Andrews]

I cant  see what is in Proposals tab anymore.

Thats because they are all paid.

Proposals tab shows Active proposals.

[Rob Andrews]

One piece of info guys and crypto-gals:

When we have multiple campaigns, exec prominence will show percentages in the detail section that total to that campaigns Percent of the global total, so let me give an example:
We have 5% of our GSC budget set up for HEALING
We have 95% set up for POG currently

The participants in HEALING will total 5% in exec prominence details.  The participants in POG will total 95% in details.

The "Totals" section however will just be points, prominence % (of global), and grand total.


Next, since we require coin-age as a gsc-heal-transmission there really is technically no exploit for bad behavior currently, but it will still be nice to have reputation scores eventually.  Either way we will have the diary very soon.  We can use the diary in the spiritual-warfare campaign also, that will be nice.

[Rob Andrews]

Ready for MacOS

Regarding Ubuntu PPAs, I still have to figure out how to compile Chia-BLS and Relic into PPAs themselves, then add them as an internal dependency... not an easy task at the moment, will report any progress.

Thanks!  If you have a link for me to put on the OP post I will.

[Rob Andrews]

So far, its purring like a kitten...

It looks like we smashed the bug.

[oncoapop]

Good job so far. I have a question:

1/3 sancs that I have reports a different health output:

"votes": 1,
  "required_votes": 3,
  "last_superblock": 14985,
  "next_superblock": 15190,
  "next_superblock_triggered": true,
  "Healthy": true,
  "GSC_Voted_In": false
mastenode outputs
{
  "626a61b0dfa151374bb42f1c432853efacb1742292318f9389c121f51b3310e4": "1"
}

-------------------------
2/3 report this:
  "votes": 5,
  "required_votes": 3,
  "last_superblock": 14985,
  "next_superblock": 15190,
  "next_superblock_triggered": true,
  "Healthy": true,
  "GSC_Voted_In": true

Is that normal behaviour?

[Rob Andrews]

Good job so far. I have a question:

1/3 sancs that I have reports a different health output:

Code Select Expand


"votes": 1,
  "required_votes": 3,
  "last_superblock": 14985,
  "next_superblock": 15190,
  "next_superblock_triggered": true,
  "Healthy": true,
  "GSC_Voted_In": [b]false[/b]
mastenode outputs
{
  "626a61b0dfa151374bb42f1c432853efacb1742292318f9389c121f51b3310e4": "1"
}

-------------------------
2/3 report this:
  "votes": 5,
  "required_votes": 3,
  "last_superblock": 14985,
  "next_superblock": 15190,
  "next_superblock_triggered": true,
  "Healthy": true,
  "GSC_Voted_In": true

Is that normal behaviour?

Thanks for the testing, so let me explain a little more about health, this is a relatively long explanation but Ill try to make it succinct.

So the fact that we see "1" positive vote on your first node, the answer from a high level is, Its "probably OK", but we should do a little more investigation to try to find out whats going on.

On a side note, the underlying goverance-obj hash, that is the native Dash hash for the object, but the PAM hash is the hash of the payments and addresses in the GSC contract. 

The node will be able to recover by the time the superblock hits using various methods, it will attempt to sync (mnsync status, govobjs) first, then it will attempt to unpack the gsc contract manually (this is since it actually runs the same code as the server side), and finally before it fails it will still follow normal superblock rules (IE mark the block as good if its a node thats out of sync), but its still worth going a little further with this one, to see if we have any gov-obj data sync errors.

So lets try to isolate the missing govobj hash.
If you run 'exec health' you will see the height is 15805 (for the next superblock).
Then go to a healthy node and type 'gobject listwild all triggers 15805' and you should see one or more contract triggers (preferably one).
Then copy the governance-object hash (this is the very first hash on the page) to notepad.
Then cat.debug.log | grep hash  in your node that only has one vote.  And see if an error occurred in syncing that hash (it might say something like Exception: failed to sync governance-object nnnnnn) but not exactly this wording.

If we can find that exception, then I can track down why that node did not fully sync.  Also let us know if it recovered.
And also if 'mnsync status' shows that the node is out of sync (IE the row that reads 'IsSynced').  If that failed, the node didn't get all of its gobjects.

Another possibility is being on testnet, we have 4 enabled sancs, and 4 down, it could be that node is still trying to iterate through to the enabled nodes.

I think during testing if we are still having gobject sync problems they will most likely reveal themselves as a lot of data will be passing back and forth.

Right now all 4 of mine are in sync, with exec health true and 4 votes, but I will check my logs to see if any sync errors have been flying around through the night.

(I know we need to shorten the delete duration of gobjects in the next release, this will cut some of this spam and chattiness down also).

[Rob Andrews]

So I thought of another feature we could use in testnet: the ability to see total outbound tithes, outbound coin-age, and inbound-revenue over a superblock period.  And make exec prominence show your user information as a total (so you dont have to look through the list).

Any other requests in that vein?

This would theoretically show the user the summary that they need per day and reveal the ROI and totals that they used for the staking component.

[Rob Andrews]

We still need help entering more proposals, please enter some.

Next superblock @ 17220.