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

[orbis]

Rob,
I think, that would be nice to have these stats (from production) in tx details:

Code Select Expand

Height: XXX
Difficulty: XXX
Time: XXX
Subsidy: XXX
Now its really hard to count block height when the tx has been done.
Maybe block height would be enough.

[Rob Andrews]

Rob,
I think, that would be nice to have these stats (from production) in tx details:

Code Select Expand

Height: XXX
Difficulty: XXX
Time: XXX
Subsidy: XXX
Now its really hard to count block height when the tx has been done.
Maybe block height would be enough.

Good idea, I will add them (added to list).


Also I was just reading about the procedure to upgrade a Sanc to a deterministic sanc, and although on the positive side, its just a single page of commands that can be done from the home wallet itself, if someone owns a lot of sancs, they might miss out  on a major family event like birth of new child, etc.  In light of that I was thinking it might be useful for us to add an upgrade command.  I believe we can potentially access what we need by scanning down to the existing entry in the masternode.conf, then generating the new info, signing it and sending it.  One last step we can not do is move the 'masternodeblsprivkey=' to the hosted sanc, but we can emit that in the output of the upgradesanc command.  I think Ill work on this command before we move to dip3.      https://docs.dash.org/en/stable/masternodes/dip3-upgrade.html

Something like 'upgradesanc existing_sanc_name' would be nice.  Then it outputs: masternodeblsprivkey=nnnnnn.

[Rob Andrews]

So, I did add the legacy double click info to our txlist, and over the last day, I added a new command to allow us to upgrade a sanc to deterministic.

Let me iterate through the punchlist, and verify some other small things we might need for our next round of testing, and then ill create a new release for testnet.

BTW, our ABN feature worked about 95%, but I did discover a bug in it so only 1 of its 2 features are enabled, will fix this as part of this next release also.

Progress is now speeding up, and everything looks very solid.  I feel bullish about the next version of BiblePay.

[Rob Andrews]

The new version is almost ready, but I see the 4.5MM lockup poll is most likely winning.

I believe this is a good time for us to include the higher collateral in the next release (since we need a mandatory change anyway for the ABN rule).

We will need to re-create our sancs @ 4.5 MM.

Stay tuned...

[Rob Andrews]

I'm starting to add some documentation to explain to new users how to get started:

Getting started with Evolution:
https://wiki.biblepay.org/Getting_Started_with_Evolution
GSC's:
https://wiki.biblepay.org/Generic_Smart_Contracts
Healing Campaign:
https://wiki.biblepay.org/BiblePay_Healing_Campaign
Street Healing:
https://wiki.biblepay.org/Street_Healing
Spiritual Warfare:
https://wiki.biblepay.org/Spiritual-Warfare-I



I realize we need a specific section for Grandma also - I'll continue to refine the getting started guide.

Please let me know if anyone would like to see more expanded info on any of these, and/or if this is sufficient to call us "easy to use" with the release of Evo.

[Rob Andrews]

1.4.1.7 - Mandatory Upgrade for TestNet

- Fix bug showing old proposals in Proposals List page
- Change sanctuary lockup collateral to 4,500,001
- Upgrade persisted data storage system from v1.0 to v1.1
- Add txlist double click drill in: display of biblepay-classic fields:
height, time, difficulty
- Add RPC leaderboard command (leaderboard me=true/false [height ||
last || future]
- Add exec upgradesanc sancname.  This is a BiblePay utility that allows
you to upgrade a non-deterministic sanc to a deterministic sanc.  We
also add the deterministic.conf file, so the user can write scripts to
read their own deterministic sanc keys and automate the deployment of
the keys to the remote server(s).
- Fix low-abn-weight bug
- Make exec join healing display the wiki URL so the user can learn
about the healing campaign first


Note:  We just changed our sanctuary lockup collateral to 4,500,001.  Please re-create your sancs.

We will talk about Deterministic a little later, for now please re-create the standard way - but note: It is recommended that we re-create Cold sancs, as the upgrade to dip3 will require cold sancs.  (Hot sancs cannot be upgraded to dip3).

[Rob Andrews]

I'm seeing this hash:
getblockhash 37124
1e0d0a836d61d246d0202507747a71e2960eaf683668d45b38365616cbed6ffa

Last night I recreated my 3 sancs and enabled them but through the night people upgraded and reorganized and erased the block I sent my 4.5MM in.
I just recreated my 3 legacy sancs again; re-starting sancs now.

[Rob Andrews]

Actually it looks like we are encountering a brand new Evo-specific issue as of a new block from yesterday:

2019-04-18 13:59:56 ERROR: ConnectBlock(): ProcessSpecialTxsInBlock for block 4b1205177d60daa173491b742e39501ae29a48605bf3ed617ade77149feb6fb2 failed with bad-protx-collateral (code 16)

It looks like two of us tried to create deterministic sancs before the spork was enabled.  But what is interesting is this was legal yesterday but today the block is actually being rejected.  (I can understand that partially since all the sancs are disabled right now), but what is interesting to me is that we reject the entire block if the Pro-reg-tx fails.

Let me take a look at this issue in detail.  In the mean time I think the only way to sync is to re-sync every node to before 34510 occurred.

[Rob Andrews]

Actually it looks like we are encountering a brand new Evo-specific issue as of a new block from yesterday:

2019-04-18 13:59:56 ERROR: ConnectBlock(): ProcessSpecialTxsInBlock for block 4b1205177d60daa173491b742e39501ae29a48605bf3ed617ade77149feb6fb2 failed with bad-protx-collateral (code 16)

It looks like two of us tried to create deterministic sancs before the spork was enabled.  But what is interesting is this was legal yesterday but today the block is actually being rejected.  (I can understand that partially since all the sancs are disabled right now), but what is interesting to me is that we reject the entire block if the Pro-reg-tx fails.

Let me take a look at this issue in detail.  In the mean time I think the only way to sync is to re-sync every node to before 34510 occurred.

Ok.  I see whats going on here.  At first it seems a little strange that a single bad pro-reg tx could fork the chain (because business logic rejects the entire block that contains the bad pro-reg) -- but thats not whats really happening in the bigger picture. 

In the bigger picture we will always have a supermajority of sancs online in prod to make the call, so with sancs actually online, the pro-reg would have been processed or the sanc-quorum would have rejected the block.

The rule goes like this:  For chainlocks, llmqs, and pro-reg-special-transactions, all of these are forwarded to a processor that checks validity based on the llmq (long living masternode quorum), and if any fail, the entire block is rejected.

So what we need to do first everyone, please re-sync your chain to before 34510 and please do not send any 'upgradesanc' commands or pro-regs until we successfully recreate our sanc quorum with 4.5 mm locks.  Also just to be safe, lets ensure diff is > 1.0 and we solve the next GSC superblock after that with exec health showing true.

Then we can re-group and talk about testing the next layer(s).

[Rob Andrews]

Ok, Ive resynced all my nodes and restarted my sancs  - they went to enabled, Im seeing this hash:

getblockhash 34746
123eebf58f402f349adc10d578ef80a9e8a4200a45326db28b6eb39ab0b364a8

[MIP]

1.4.1.7 - Mandatory Upgrade for TestNet

I compiled a version of the daemon/cli for Linux amd64, available here
https://www.biblepay.org/biblepayd-1.4.0.7-x86_64-pc-linux-gnu.tar.gz

And MacOS QT version here
https://www.biblepay.org/biblepaycore-testnet.dmg

[vuli]

I am stuck the whole day at Syncing Headers 96,3% , progress bar  is  2sec behind.

19:25:02
getblockhash 36743

19:25:02
d7d64e0701e5480e3b53429d7015b03ae0351c025dfd6d4de9c86f05f8294bd6

[Rob Andrews]

I am stuck the whole day at Syncing Headers 96,3% , progress bar  is  2sec behind.

19:25:02
getblockhash 36743

19:25:02
d7d64e0701e5480e3b53429d7015b03ae0351c025dfd6d4de9c86f05f8294bd6

I took a look at that stuck 1-10 second behind header issue, and it turns out what that means is your node doesn't have a fully synced gobject list (IE it believes the masternodes and gobjects are not synced) - also, if you do an mnsync status, you are probably in chain synced true and gobjects synced = false. 
Another words, that is a feature that lets you know something is wrong with the mnsync status only.

EDIT: Ok, so yes you are synced on the blockchain - my hash agrees.

I think you just have a bad mncache.

Try this:  stop node, rm mnc*.*, rm gov*, rm mnp*,  restart wallet, wait 10 mins - see if mnsync status shows all trues then and the bar dissapears?

[Rob Andrews]

I see someone was nice enough to enter about 15 proposals right before we upgraded!

Thanks!

Who was that btw?

Unfortunately all this work was in vain because we had the mandatory upgrade right after, and there were no sancs around to vote at that height for that superblock (see getgovernanceinfo, see last superblock height), that block ended up turning out to be a regular block.

This is to be expected in this case.

So please let us do it again soon.

[Rob Andrews]

I compiled a version of the daemon/cli for Linux amd64, available here
https://www.biblepay.org/biblepayd-1.4.0.7-x86_64-pc-linux-gnu.tar.gz

And MacOS QT version here
https://www.biblepay.org/biblepaycore-testnet.dmg

Thanks - added the Mac version to the OP post.