Bible Pay

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Rob Andrews

Pages: 1 ... 155 156 157 158 159 160 161 [162] 163 164 165 166 167 168 169 ... 263
2416
I cant  see what is in Proposals tab anymore.


Thats because they are all paid.

Proposals tab shows Active proposals.


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


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




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


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


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


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


2423
Hi Rob...How can I verify what version I am on Win32 wallet (testnet)...Help->About says 1.4.0.9 last couple of updates...

Hmmm, it appears the link changed.

Please see the OP post now (edited).

Thanks!


2424
1.4.1.2b-TestNet Mandatory Upgrade

- Refine GSC Voter

2425
So I have all the logs and I can see exactly what happened.
So we made it further this time, we passed through a couple days worth of superblocks without problems.
The problem is still with the GSC superblock (again), this time at height 11,500 it was rejected - half of the network accepted it and the other half rejected it causing a split at 11,501 and this is the reason half of our sancs now show Expired (they are on the wrong chain).

On the bright side, watchman-on-the-wall actually worked already and paid the proper amounts in the last monthly superblock and Im very happy about that.  Even though no one entered the proposals that we needed to test the overages - I had enough in there to at least test one overage (I had the block overpaid by 50K and it did successfully pick the first 3 highest voted that fit).

So looking at the root cause as to why two of my nodes rejected the block, I can see clearly that a non-sanctuary thought it was completely synced with the Sanc network (this has nothing to do with the chain sync, just the gobject sync) but in reality it did Not have the information it needed to make a good call. 

In light of this, what I plan on doing next is tackling this another way.

Please halt testing until the next version.



2426
1.4.1.0-Leisure Upgrade for TestNet

- Add cascading GSC superblock creation (this decreases the propensity
for duplicate GSCs)
- Add intelligent GSC voting system (this means we vote yes on the
lowest PAM hashes and vote no on the highest PAM hashes)
- Add Watchman on the Wall budgeting
- Add 'gobject listwild all type wildcard' - This allows us to search
objects or proposals or gscs or triggers by wild card.  You can also
search by gov plain text data or by hash.
- Add getgschashes - This gives us a list of current gsc hashes for the
next superblock and pertinent data for each hash

2427
Thanks.

bbpd@sanc2:~$ ifconfig
ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 45.62.239.200  netmask 255.255.255.0  broadcast 45.62.239.255
        inet6 fe80::250:56ff:fe95:4682  prefixlen 64  scopeid 0x20<link>
        ether 00:50:56:95:46:82  txqueuelen 1000  (Ethernet)
        RX packets 600708  bytes 190734759 (190.7 MB)
        RX errors 0  dropped 276  overruns 0  frame 0
        TX packets 530771  bytes 225023604 (225.0 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


Yes, I see you as the 4th enabled sanc, great.

So trying to track this down took me longer than when it actually passed, so I found that it would be useful for us to have a couple more features.
1- The ability to see that the exec testgscvote is actually picking the most popular contract; right now I see 2 in there and it appears to be voting on the right one, but we cant really see it from the rpc
2- A way to filter the gobject get with a wildcard. 

Let me enhance the next version then we can test another one.


2428
I appear to be on the correct chain by as far as I can tell (checking manually), I have not seen my sanc (the 4th) vote for any superblock. Does this have to be done manually?

bbpd@sanc2:~/Sanctuary$ cli getblockhash 10120
e13331a79a04776297f1ef66634525bb3d16aca8c9ff8d61a5be21f2c5202caf
bbpd@sanc2:~/Sanctuary$ cli exec health
{
  "Command": "health",
  "govobjhash": "9ff38ea222d3bb56085b2c696a10ddf02d16548cdb23beec3db828ae5ed8b929",
  "Amounts": "736194.00|180067.00|173696.00|101790.00|23491.00|37641.00",
  "Addresses": "yR26BVwFeGTnkgdfw1RRNgVF2LyPnrZqaT|yS9YaCFpQuE6xpBrTvUbnPyJgwaXZep8C8|yUNSEjjtC9pdeHp4spswdFWh1npfV5Jvqe|yfqGyVvuyidYytq5o2QvN1VdVeXtH9Lrkt|ygavD5YuAJXpHDMLRyiiJ199YM5y9fTWfB|yiWrpMBA8YXfVmxntAgZZ1dh18ueaBerbW",
  "votes": 2,
  "required_votes": 3,
  "last_superblock": 10680,
  "next_superblock": 10885,
  "next_superblock_triggered": true,
  "Healthy": true,
  "GSC_Voted_In": false
}

I think things are OK on the back end, but we might need another field - but first whats your sanc Ip, I can check some things to make sure I see your vote?

Btw, no - you should not have to vote manually, this is all automatic.


2429
I've got a fun project coming up for us. 

So basically, here are the requirements for Watchman On The Wall we need to fulfill for replacement of The Sentinel, and be the first coin with our own integrated Watchman (not requiring python):

- Nodes get banned and not paid if they are not running watchman (this prevents people from running sancs that do not help vote on the budget)
- Nodes do not get voted on for a sanc payment if they are down (IE watchdog expired)
- Nodes who do run watchman can create a budget, sort it by votes, exclude proposals that pay dont fit, and vote on the proposal automatically during the warning period

We've got the first two covered (Watchman will automatically run in our sancs in c++, sancs will only vote on sancs who are Up (as we do test for that already), and we already have a spork for payment enforcement), and by the end of our testing, we will ensure Sanc don't expire prematurely--  so in light of all this, all that is left (the elephant in the room), is to test Watchman Budgeting.

In light of that, I am now modifying Watchman to handle budgets.  Where you all will come in to help, is we need to create about 10 *new* proposals (as the old ones are bad) -- for the next superblock (see 'getgovernanceinfo' to see the next budget is at height 11480, with getsuperblockbudget 11480 = 4.1MM bbp).

What we need to do in the future is : Verify proposals that missed a prior superblock deadline are no longer in the proposals list (this is broken currently), that future unpaid proposals are in the proposals list, and that watchman picks up these for budgeting, and sorts them by votes descending, and also excludes items that dont fit the cap.

What I want to do is have us all vote on these, and ensure the ones with low votes are not included and those that are too high for the budget cap are excluded automatically.

The current version *is* capable of taking new proposal now - for block 11480, so please, start now by creating 5-7 new proposals (please only create One at a time and then ensure the block has passed before creading another one).  I think if each of you create 2-3 that is sufficient.

Ill create a few myself now.

After the next release, the bugs above will be fixed and then we can test a watchman dry run at a height of 10% before block 11480 (that is the warning period) (IE 115 blocks early).




2430
Switched to healthy=true on my node..
Yes, thank God we finally made it through the entire night and all the superblocks passed all the rules this time (we had about 4 so far I think).


getblockhash 10120

e13331a79a04776297f1ef66634525bb3d16aca8c9ff8d61a5be21f2c5202caf

I can see we are all still in sync also.  I forgot to mention, you can see by the difficulty that the chain is solid now as it jumped up to 1.4 (from .10 when we had the issues).


Great, now I can take a look at the proposal rules for the monthlies and see if we can expose the height, and test watchman. 


I'm going to be explaining a (what I consider to be) novel use of our new campaigns later today.

We can discuss bearing fruit in Jesus Name with Healing campaigns and spiritual warfare in Evo. 

I'm thinking we can add a CPK startup wizard, with the ability to read an instruction PDF, join a campaign that requires directions (as spiritual warfare for instance is dangerous if a person does not know what they are doing), and once they join, we also need the ability for a user to type in a days activity back into BiblePay.    This would allow the campaign to keep a diary of what the user is doing for the points (for these specific campaigns).




Pages: 1 ... 155 156 157 158 159 160 161 [162] 163 164 165 166 167 168 169 ... 263