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

no, there is no reason. didnt even know I am hiding it.
I uncomment this below and now it got the connection.
#rpcuser=
#rpcpassword=
#rpcallowip=127.0.0.1
#rpcport=40001
#listen=0

So I have a few pieces of advice for anyone creating new deterministic sancs:

1) Do not lose your masternodeblsprivkey (or pubkey).  Keep a copy of your deterministic.conf somewhere.  If you lose your wallet.dat, your sanc will keep running as long as the collateral is locked, and you will not be able to change its IP or its collateral without that blsprivkey and owner privkey.
2) However, I did a test today and found a way to immediately kill your old sanctuary (and allow upgrading).  If you spend your collateral, within minutes the sanctuary will dissapear from the active sancs list! 
3) You cannot re-register the same IP with a new sanc until you either Revoke your old sanctuary (with a proUpRevTx), or if you spend your collateral.

I was successfully able to re-create a new sanc today after I spent my collateral and did a new upgradesanc command.

If otoh you do an upgradesanc before spending and revoking, you will receive an error (duplicate service IP).

no, there is no reason. didnt even know I am hiding it.
I uncomment this below and now it got the connection.
#rpcuser=
#rpcpassword=
#rpcallowip=127.0.0.1
#rpcport=40001
#listen=0

Ok good, I was only asking because yesterday I saw some strange activity that looked like someone was sending things from a fraudulent client (IE a self compiled fraudulent client).

Yeah the addresses are:  dns1.biblepay.org, dns2.biblepay.org and dns3.biblepay.org

I saw in debug " 0 addresses found from DNS seeds" so I was planning in adding them manualy but ok.
 
prict from previus post

Upgraded both wallets to v1.4.2.8b yesterday

I tried to just run them normally, but they would crash right away, tried to reindex and same thing, didnt see anything in the log (may have forgotten to add debug=1), so I wanted till today and tried again with reindex, both worked a couple hours ago

getblockhash 69207
6e40d8f*

Are you sure the terminal window didnt say "assertion failed" when you ran it?

(Thats not a crash - thats an ungraceful exit).  That happens when evo chain pindex != pindexbest.  (Ive seen that a few times).  That happens when the database exits uncleanly without a flush.  We put in a fix for that in classic, but we left it the way it is in Dash since they have it in there I figured it was good enough for us, but its obviously a 6 1/2 dozen other conundrum type issue.

I saw in debug " 0 addresses found from DNS seeds" so I was planning in adding them manualy but ok.
 
prict from previus post

We add them in a non-conforming way (we force them in).

Usually they kick in after 15 mins if your IP was temporarily banned.
That happens very easily when you are on your own chain, your client forwards block headers to the seed nodes, they ddos you and build up a certain amount of minutes ban, then they allow you in again after you stop the activity and try to start from zero.


One other problem with syncing from zero is you may need gen=0 to get started as in testnet its suuuuper easy to solve a block and get on your own chain (I had to do the gen=0 today to sync properly).

v1.4.2.8b, both Ubuntu, both command line daemon, one Ubuntu 16.04, other Ubuntu 18.04,

I was checking the log that didnt have debug=1 in it and couldnt see anything stick out,

by crash, I mean it started up and I typically keep entering "biblepay-cli getinfo" to check its progress, but it would give me some RPC error and biblepayd wouldnt be inside "ps -ef", and Id have to start it up again, and then it would crash again

I just downloaded the one that had debug=1 on, about to go through it, 80mb debug file

=

I believe this is the relevant section of the debug.log, hopefully it is and Im not wasting your time
(uploaded it to file hosting site, 4.7MB)
https://ufile.io/pqaao2vj

=

Code: [Select]

2019-05-08 04:50:28  ABN OK: 1.000000 LoadExternalBlockFile: Processing out of order child 7d37aaa250a86221b5ba434365aec3dc127183af7ccbabdec9367b7e9fa14719 of 4e5bcad04e7082d25315cfc964b463c70f8053de1e68013e532ce38f43d78d95
2019-05-08 04:50:28 ERROR: ReadBlockFromDisk: Deserialize or I/O error - ReadCompactSize(): size too large: iostream error at CBlockDiskPos(nFile=0, nPos=39353)
2019-05-08 04:50:28 *** Failed to read block
2019-05-08 04:50:28 Error: Error: A fatal internal error occurred, see debug.log for details
...
2019-05-08 04:50:28 Interrupting HTTP server
2019-05-08 04:50:28 Interrupting HTTP RPC server
2019-05-08 04:50:28 Interrupting RPC
2019-05-08 04:50:28 Exited http event loop
2019-05-08 04:50:28 addcon thread exit
2019-05-08 04:50:28 mncon thread exit
...
2019-05-08 04:50:28 PrepareShutdown: In progress...
2019-05-08 04:50:28 Stopping HTTP RPC server
2019-05-08 04:50:28 Unregistering HTTP handler for / (exactmatch 1)
2019-05-08 04:50:28 Stopping RPC
2019-05-08 04:50:28 RPC stopped.
2019-05-08 04:50:28 Stopping HTTP server
2019-05-08 04:50:28 Waiting for HTTP worker threads to exit
2019-05-08 04:50:28 Waiting for HTTP event thread to exit
2019-05-08 04:50:28 Stopped HTTP server
2019-05-08 04:50:28 CDBEnv::Flush: Flush(false)
2019-05-08 04:50:28 CDBEnv::Flush: wallet.dat checkpoint
2019-05-08 04:50:28 CDBEnv::Flush: wallet.dat detach
2019-05-08 04:50:28
BiblepayMiner -- terminated
 0CDBEnv::Flush: wallet.dat closed
Is this the culprit?

Code: [Select]

2019-05-08 04:50:28 ERROR: ReadBlockFromDisk: Deserialize or I/O error - ReadCompactSize(): size too large: iostream error at CBlockDiskPos(nFile=0, nPos=39353)
2019-05-08 04:50:28 *** Failed to read block
2019-05-08 04:50:28 Error: Error: A fatal internal error occurred, see debug.log for details
=

From other logs it seems typically theres:

Code: [Select]

ThreadRPCServer method=stopor with GUI

Code: [Select]

GUI: requestShutdown : Requesting shutdown
GUI: shutdown : Running Shutdown in thread

v1.4.2.8b, both Ubuntu, both command line daemon, one Ubuntu 16.04, other Ubuntu 18.04,

I was checking the log that didnt have debug=1 in it and couldnt see anything stick out,

by crash, I mean it started up and I typically keep entering "biblepay-cli getinfo" to check its progress, but it would give me some RPC error and biblepayd wouldnt be inside "ps -ef", and Id have to start it up again, and then it would crash again

I just downloaded the one that had debug=1 on, about to go through it, 80mb debug file

=

I believe this is the relevant section of the debug.log, hopefully it is and Im not wasting your time
(uploaded it to file hosting site, 4.7MB)
https://ufile.io/pqaao2vj

=

Code: [Select]

2019-05-08 04:50:28  ABN OK: 1.000000 LoadExternalBlockFile: Processing out of order child 7d37aaa250a86221b5ba434365aec3dc127183af7ccbabdec9367b7e9fa14719 of 4e5bcad04e7082d25315cfc964b463c70f8053de1e68013e532ce38f43d78d95
2019-05-08 04:50:28 ERROR: ReadBlockFromDisk: Deserialize or I/O error - ReadCompactSize(): size too large: iostream error at CBlockDiskPos(nFile=0, nPos=39353)
2019-05-08 04:50:28 *** Failed to read block
2019-05-08 04:50:28 Error: Error: A fatal internal error occurred, see debug.log for details
...
2019-05-08 04:50:28 Interrupting HTTP server
2019-05-08 04:50:28 Interrupting HTTP RPC server
2019-05-08 04:50:28 Interrupting RPC
2019-05-08 04:50:28 Exited http event loop
2019-05-08 04:50:28 addcon thread exit
2019-05-08 04:50:28 mncon thread exit
...
2019-05-08 04:50:28 PrepareShutdown: In progress...
2019-05-08 04:50:28 Stopping HTTP RPC server
2019-05-08 04:50:28 Unregistering HTTP handler for / (exactmatch 1)
2019-05-08 04:50:28 Stopping RPC
2019-05-08 04:50:28 RPC stopped.
2019-05-08 04:50:28 Stopping HTTP server
2019-05-08 04:50:28 Waiting for HTTP worker threads to exit
2019-05-08 04:50:28 Waiting for HTTP event thread to exit
2019-05-08 04:50:28 Stopped HTTP server
2019-05-08 04:50:28 CDBEnv::Flush: Flush(false)
2019-05-08 04:50:28 CDBEnv::Flush: wallet.dat checkpoint
2019-05-08 04:50:28 CDBEnv::Flush: wallet.dat detach
2019-05-08 04:50:28
BiblepayMiner -- terminated
 0CDBEnv::Flush: wallet.dat closed
Is this the culprit?

Code: [Select]

2019-05-08 04:50:28 ERROR: ReadBlockFromDisk: Deserialize or I/O error - ReadCompactSize(): size too large: iostream error at CBlockDiskPos(nFile=0, nPos=39353)
2019-05-08 04:50:28 *** Failed to read block
2019-05-08 04:50:28 Error: Error: A fatal internal error occurred, see debug.log for details
=

From other logs it seems typically theres:

Code: [Select]

ThreadRPCServer method=stopor with GUI

Code: [Select]

GUI: requestShutdown : Requesting shutdown
GUI: shutdown : Running Shutdown in thread

Thanks, got it (downloaded the file and analyzed).
At least I can tell you what exactly happened (that its not a systemic problem preventing release).

So in your case, your node ran and flushed the blocks db correctly on the prior run.
You ran it with reindex and it made it to height 21598 when it ran into a bad serialized block (IE the length pointer was longer than the maximum allowed data) meaning to biblepay, it believed the blocks database was corrupted.  This obviously was probably not corrupted but something the reindex did to the file instead.  For one it was reading the blocks out of order since height 1100, which is not too good for biblepay because of our contextual checkblock rules.

I personally have had a lot of problems with -reindex, so much that I stopped doing it (I always just sync from the network now). 
My non-optimal solution is to create a blocks file download in prod weekly or monthly for our users who want high performance download of the initial blocks from biblepay.org/snapshot for example.  We can make that a possibility when we hit around block 150K. 

In this case, the program handled the exception but obviously exited and that left you with no choice but to resync the chain.
Note that -reindex does work when the blocks are read in sequentially, but they are not guaranteed to be sequential in berkeleydb.

Thank you for looking into it Rob!

 gen=0 is the first thing I did.

Hi Guys,

I've upgraded to 1.4.2.8. My sanc says the following:

10:07:01

masternode status


10:07:01

{
  "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
  "service": "84.29.XXX.XXX:40001",
  "state": "WAITING_FOR_PROTX",
  "status": "Waiting for ProTx to appear on-chain"
}

My controller wallet shows the Sanc in the DIP3 tab though, and I've been getting payments?

I'm sorry. I don't have much time to dive into the Dash documentation

Hi Guys,

I've upgraded to 1.4.2.8. My sanc says the following:
My controller wallet shows the Sanc in the DIP3 tab though, and I've been getting payments?

I'm sorry. I don't have much time to dive into the Dash documentation

Yeah, the payments will start deterministically based on this new algo, and continue until your node is PosE banned.  PosE happens if your node is Off for a certain amount of time (and gets voted down), or if your node isnt participating in the new LLMQs (long living masternode quorums).

As far as the node itself, it cant find its own proreg tx on the chain.
Most likely because the masternodeblsprivkey is missing.

Please copy the key from the deterministic.conf to the node and reboot it and see?

gen=0 is the first thing I did.

Well you will know if that is the problem if your node syncs to a certain height and stops syncing (as it tries to prefer the block you solved).  If you get enough connections it will recover though.

Let us know if you still have a problem.  I can always check my logs for your ip if you provide it.

Yeah, the payments will start deterministically based on this new algo, and continue until your node is PosE banned.  PosE happens if your node is Off for a certain amount of time (and gets voted down), or if your node isnt participating in the new LLMQs (long living masternode quorums).

As far as the node itself, it cant find its own proreg tx on the chain.
Most likely because the masternodeblsprivkey is missing.

Please copy the key from the deterministic.conf to the node and reboot it and see?

Working! Somehow a wrong private-key ended up in my masternodeblsprivkey. Probably got something to do that I used some Dash documentation when setting everything up...

Before I draft an upgrade plan to transition to Evo I thought I would share my idea here first.

Please comment if you have any questions concerns or possible enhancements.
Also, I haven't heard any negative comments on POG/Healing or the payment system, and I assume everyone is happy with the payments compared to the coin age and the tithe levels.

Upgrade to Evo Plan of Action:

Around June 2nd 2019 (this is after our May monthly superblock pays out in biblepay-classic): (Height approx 124000):
At this height, all Sanctuaries must upgrade to Evo, and re-lock 4.5MM in Legacy Sanc mode.
Notify entire network to upgrade to Evo (also at 124,000).  Note: The entire network will be running in classic mode in Evo, with non-deterministic sancs.
Notify exchanges to upgrade at height 124,000 (this is Optional, but I think for best practices, we will ask them to upgrade along with us at 124,000).
Pools upgrade at 124,000 also.

The goal from blocks 124,000 through blocks 131,000 will be to finish upgrading all sancs to non-deterministic sancs, and through this entire period we will be in POBH (classic mode) - this will also give a little extra time for late upgraders who are running classic.  This plan also ensures that we do not break biblepay classics block structure while we upgrade to non-deterministic.  (Note that sanctuary payments will start as soon as approx 10 sancs upgrade (this will most likely happen the first day - IE June 2nd).

At block 131,000 (after the June superblock budget is paid in Evo with non-deterministic sancs), we start upgrading to deterministic sancs (this should be a transparent change as we will not flip dip15 until block 138,000). 

At approx block 132,000, we will also enable GSCs, and QT.  ABN & Anti-GPU will be enabled around block 134,000 if the network is healthy in small phases.

After the July superblock (height 139,000) - we enable dip15 (which makes deterministic sancs permanent).