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

1.4.1.5-Mandatory Upgrade for TestNet

- Mandatory upgrade before block 25,500 for TestNet
- Add leaderboard UI
- Ensure QT does not turn on until sancs vote on the first future price,
ensure monthly governance budget is based on last months QT level for
planning purposes

This is just a personal observation about the Healing campaign - and overall fairness.  However I do feel strongly about the benefit we can achieve by bearing quantifiable fruit in Jesus name (IE rewarding people for physical actions).

I realize that it would be unfair to single out 'healing campaigns' as 5% of the total GSC budget, so I think what we can do is change the Healing campaign to be a more general category for the total budget allocated to campaigns that require a diary entry.

So, what I plan on doing is creating a few PDFs with instructions, one for spiritual warfare, one for healing/driving out demons, one for spreading the gospel, and one for praying for others.  And what we do is ask the user to follow the PDF (or all the PDFs) before engaging in any of the activities requiring a diary entry.

In the end, anyone enrolled in 'healing' can then enter a diary entry for :
- Conducting spiritual warfare
- Healing/Driving out demons (healing is pray for a persons health affliction and commanding the affliction out)
- Witnessing out in public (spreading the gospel)
- Praying for loved ones/prayer list (prayer closet)

All of these things bear fruit, but the idea is to summarize the daily activity that made a difference into a diary entry once per day and enter it - regardless of the actual category above (later we can add the sub categories).  This will share the 5% among everyone with an active diary entry for the day.

1.4.1.4-Mandatory Upgrade for TestNet

- Bubble GSC transmission errors into getmininginfo
- Add Diary Entry to sendcoinsentry UI page
- Add ability to make a Diary entry for campaigns supporting diary
entries
- Add ability to see Diary Entry from the Transaction List double click
- Change exec getpogpoints to exec getpoints, make getpoints capable of
showing any GSC transmission type tx points
- Modify exec prominence to show personal prominence (exec prominence
true) or all (exec prominence false)
- Added exec sentgsc report (To see mining expenses, run this, this
breaks down donations, coinage transmissions, and totals).  To see
revenue, run exec prominence true.
- Added exec price (this shows the current BBP price, BTC price, and QT
level)

1) We now bubble GSC errors into getmininginfo.  That should take care of the problem Orbis had.

2) To see your total outbound GSCTs sent in the last 205 blocks, just type : exec sentgsc

3) You can type 'exec getpoints txid' to see the point calculation for a sent-gsc-tx

4) You can compare exec sentgsc (as your mining expense) to exec prominence true (as your revenue).  Exec prominence true shows only your details.

5) You can now see the Leaderboard UI totals by clicking the Leaderboard menu.  (QT).

6) To enter a diary entry (for one of the bearing fruit records), (first be sure you have joined Healing with exec join healing), then go to Send Money, click Diary Entry.  Type the diary entry. 

7) At 25,500 we can test QT (Quant-tightening).  I am deliberately testing things in layers.

6) is it working? because it doesnt make a transaction. -diary entry
If you check "Donate to fundation" is the same address and it make a transaction.

I think we are on this blockhash :

09:03:54

getblockhash 25354


09:03:54

72887c9dec86fe2cc3c97ef7caa3691505c81adbb021af177fd34088c72fdbfd

(Some nodes got banned as we upgraded etc).

Diff = .41

6) is it working? because it doesnt make a transaction. -diary entry
If you check "Donate to fundation" is the same address and it make a transaction.

Yes.

Please post the error you get, as we bubble the error to the screen in QT (are you using QT)?
If no error on the screen its also written to the log.

EDIT: Also, please post the diary entry here, so I can reproduce.  It must be > 10 chars in length to be valid.

Nothing happens, well no error, it just clear everything out.
I am using QT, desktop version. Unless I am doing smth wrong.

2019-04-11 16:59:19 WalletModel::CreateDiaryEntry::Creating diary entry ... DIARY ENTRY : HELLO WORLD OF BIBLE Received a GET request for / from 202.97.251.157:46264
2019-04-11 16:59:33 ProcessMessages(version, 109 bytes) FAILED peer=8360
2019-04-11 16:59:39 CMasternodeSync::NotifyHeaderTip -- pindexNew->nHeight: 25553 fInitialDownload=0
2019-04-11 16:59:39 UpdateTip: new best=0368d885bd5aa5517ede5ff01bf470a270ad63e79df5154f3e2d39cb960e744a height=25553 version=0x20000001 log2_work=44.48151079 tx=81668 date='2019-04-11 16:59:28' progress=0.999999 cache=0.0MiB(0txo)
2019-04-11 16:59:39 {PNB}: ACC 
block rejected.CreateNewBlock() packages: 0.00ms (0 packages, 0 updated descendants), validity: 0.00ms (total 0.00ms)
2019-04-11 16:59:41  ABN OK: 1.000000 CreateNewBlock() packages: 0.00ms (0 packages, 0 updated descendants), validity: 0.00ms (total 0.00ms)
2019-04-11 16:59:44  ABN OK: 1.000000 CMasternodeMan::CheckAndRemove -- mMnbRecoveryGoodReplies size=0
2019-04-11 16:59:46 CreateNewBlock() packages: 0.00ms (0 packages, 0 updated descendants), validity: 0.00ms (total 0.00ms)
2019-04-11 16:59:46  ABN OK: 1.000000

Nothing happens, well no error, it just clear everything out.
I am using QT, desktop version. Unless I am doing smth wrong.

I have a different hash for 25553.  I am pretty sure some nodes banned each other (due to the mandatory), could you please rm chainstate -r rm evodb -r rm blocks -r rm banlist.dat, and resync and see if your hash matches the one from a few blocks earlier - then please retry the tx? 

Then also see if you can scrape the txid out of the transaction double click, and also, it should have the diary entry at the very end of the window.

I think we are on this blockhash :

09:03:54

getblockhash 25354


09:03:54

72887c9dec86fe2cc3c97ef7caa3691505c81adbb021af177fd34088c72fdbfd

this one is the sameon my side :

20:16:32

getblockhash 25354


20:16:32

72887c9dec86fe2cc3c97ef7caa3691505c81adbb021af177fd34088c72fdbfd

this one is the sameon my side :

20:16:32

getblockhash 25354


20:16:32

72887c9dec86fe2cc3c97ef7caa3691505c81adbb021af177fd34088c72fdbfd

But when you pasted your log it shows a bad hash here:

2019-04-11 16:59:39 UpdateTip: new best=0368d885bd5aa5517ede5ff01bf470a270ad63e79df5154f3e2d39cb960e744a height=25553 version=0x20000001 log2_work=44.48151079 tx=81668 date='2019-04-11 1

Did you resync just now?

We will have to be a little patient as we have most likely Slovakia playing games - the diff is 20 now in prod and chain is reorging. 

Im sure it has nothing to do with Evo or the latest version, because the mandatory height hasn't hit yet.

I see we rolled back when this person who tithes 666.66 hit us with big hash.

Seems that all my sanc are went out of sync and are unable to sync up to that block. Stuck at 23234 when I initially got one sanc to sync with your 3 even after resync.

isn’t the ABN feature supposed to prevent these sorts of attacks? Please help me understand in layperson terms what is happening and how did that bypass ABN?

Thank you.

Seems that all my sanc are went out of sync and are unable to sync up to that block. Stuck at 23234 when I initially got one sanc to sync with your 3 even after resync.

isn’t the ABN feature supposed to prevent these sorts of attacks? Please help me understand in layperson terms what is happening and how did that bypass ABN?

Thank you.

1) We had synced from 23234 up to about 23336 but with a difficulty of .10 (IE very low).
The wallet will reorganize back to 23234 if it finds a chain with greater total chain work (which is possible since 23234 had a diff of 20.)

(As long as the re-org block is valid).

2) ABN tries to prevent single rich kiddies (IE someone who has 20 servers) from solving an inordinate amount of blocks personally.  It does this by using up their coin-age.  But in testnet this 20 diff could come from a few high powered machines, although more likely 4-5 miners running full speed right up to that block (so you are correct abn might have helped, but in testnet everyone has a lot of coin age also).

2a.  We actually don't have ABN turned on right now , I disabled it so we can test one feature at a time.  I planned on enabling qt next then abn later, but now we have to figure out this sync problem first.

3.  I am also rolled back to 23234 right now, so you are experiencing the same thing as me (another words the hash I posted is no longer valid).

Ill do some poking around.  We probably need to turn up our miners to more threads to solve the next block.

1) We had synced from 23234 up to about 23336 but with a difficulty of .10 (IE very low).
The wallet will reorganize back to 23234 if it finds a chain with greater total chain work (which is possible since 23234 had a diff of 20.)

(As long as the re-org block is valid).

2) ABN tries to prevent single rich kiddies (IE someone who has 20 servers) from solving an inordinate amount of blocks personally.  It does this by using up their coin-age.  But in testnet this 20 diff could come from a few high powered machines, although more likely 4-5 miners running full speed right up to that block (so you are correct abn might have helped, but in testnet everyone has a lot of coin age also).

2a.  We actually don't have ABN turned on right now , I disabled it so we can test one feature at a time.  I planned on enabling qt next then abn later, but now we have to figure out this sync problem first.

3.  I am also rolled back to 23234 right now, so you are experiencing the same thing as me (another words the hash I posted is no longer valid).

Ill do some poking around.  We probably need to turn up our miners to more threads to solve the next block.

Ok thank you for that explanation!  We seem to be moving along.

thats why I am stuck at 25237 after re-sync.
 019-04-11 19:45:03 SPORK -- hash: 00f31f1feb64a49df40213e52e3e3ce2191e6f19f6241a1740043f08efdb1ba6 id: 10011 value:          0 bestHeight: 25237 peer=436 seen
2019-04-11 19:45:03 SPORK -- hash: 644278d68318691dc8f02c6f714a12eaf27a63764caf590fc8aaeb6118725051 id: 10090 value:          0 bestHeight: 25237 peer=436 seen
2019-04-11 19:45:27 SPORK -- hash: 0b55391d2c25736279fb64125f046026b833b7021b00cafb296dcd287b72106f id: 10008 value:          0 bestHeight: 25237 peer=5 seen
2019-04-11 19:45:27 SPORK -- hash: 00f31f1feb64a49df40213e52e3e3ce2191e6f19f6241a1740043f08efdb1ba6 id: 10011 value:          0 bestHeight: 25237 peer=5 seen
2019-04-11 19:45:27 SPORK -- hash: 644278d68318691dc8f02c6f714a12eaf27a63764caf590fc8aaeb6118725051 id: 10090 value:          0 bestHeight: 25237 peer=5 seen
2019-04-11 19:45:27 SPORK -- hash: 0b55391d2c25736279fb64125f046026b833b7021b00cafb296dcd287b72106f id: 10008 value:          0 bestHeight: 25237 peer=6 seen
2019-04-11 19:45:27 SPORK -- hash: 00f31f1feb64a49df40213e52e3e3ce2191e6f19f6241a1740043f08efdb1ba6 id: 10011 value:          0 bestHeight: 25237 peer=6 seen
2019-04-11 19:45:27 SPORK -- hash: 644278d68318691dc8f02c6f714a12eaf27a63764caf590fc8aaeb6118725051 id: 10090 value:          0 bestHeight: 25237 peer=6 seen
2019-04-11 19:45:29 ProcessMessages(version, 109 bytes) FAILED peer=558
2019-04-11 19:45:29 ProcessMessages(version, 109 bytes) FAILED peer=559
2019-04-11 19:45:33 ProcessMessages(version, 109 bytes) FAILED peer=561
2019-04-11 19:45:39 ProcessMessages(version, 109 bytes) FAILED peer=562
2019-04-11 19:45:41 ProcessMessages(version, 109 bytes) FAILED peer=563
2019-04-11 19:45:42 ProcessMessages(version, 109 bytes) FAILED peer=564
2019-04-11 19:46:17 ProcessMessages(version, 109 bytes) FAILED peer=565
2019-04-11 19:46:24 ProcessMessages(version, 109 bytes) FAILED peer=566
2019-04-11 19:47:07 ProcessMessages(version, 109 bytes) FAILED peer=568
2019-04-11 19:47:19 ProcessMessages(version, 109 bytes) FAILED peer=569
2019-04-11 19:47:22 ProcessMessages(version, 109 bytes) FAILED peer=570
2019-04-11 19:47:52 ProcessMessages(version, 109 bytes) FAILED peer=571
2019-04-11 19:47:53 ProcessMessages(version, 109 bytes) FAILED peer=572