BIBLEPAY - TESTNET THREAD - TESTING SANCTUARIES FOR GO LIVE AT CHRISTMAS

Rob,

i did it by your instrunctions,typed and nothing... and btw: i had in crontab correct    when you checked my screens what i posted here .. you must saw it
it looks,that all your setup is broken.Exists anybody whom working masternode except you? I dont know this person.By me nobody.It will be very hard start masternode when doesnt working still.





what happened when ill close controller-win-wallet and again run it? its OK?


thanks

That command you ran is good.  When it results in an empty result, Watchman is working.  I see your IP is working on the list also, so its obviously working.  The trick is to get the exact command that runs in the crontab working from the command line, then ensure its in the crontab, and then every 5 mins when it runs, your watchdog will not squeal out to the network that your node is down.

I dont think our guide is bad.  I think it needs a couple rough edges polished.  Ive already edited it based on Togo and Your issues over the last 2 days.

What we need is someone to come in here and start a new one and give us fresh advice.  Anyone who wants to start a testnet Sanctuary,
run the Wiki.biblepay.org/Create_Masternode Guide, and let us know if you think it is lacking.  We have to also take into account that it was written in English, and we have no Polish translation, so Im sure communication is part of the problem.  Also, keep in mind not everyone will use biblepayd to run the commands, for example, I set up my Cold node using the windows RPC, and used Samba and nano for all my settings changes.

now again working masternode= received rewards .... nice

for CZECH+SLOVAK languages i can help
user Slovakia can help with CZECH SLOVAKIA HUNGARY

Alright, should I mine at the same time or just be connected and synced to the network?

You can mine if you want, no problem, as long as you are synced first.

But now all of a sudden we have a fork.  I dont know if it has anything to do with your nodes coming on? How many did you bring into testnet?

We all need to be synced before I can make any sense out of the test harness forensic commands.

it looks,that we are stuck on 41100

Yeah I see half the network is on 41116 and the other half on 41293....

Looking...  Not sure why this started all of a sudden, we were going so well other than having a rag tag set of sanctuaries we were staying in sync for a long time.  This happened at 5AM this morning (4 hours ago).

Yeah I see half the network is on 41116 and the other half on 41293....

Looking...  Not sure why this started all of a sudden, we were going so well other than having a rag tag set of sanctuaries we were staying in sync for a long time.  This happened at 5AM this morning (4 hours ago).

If you see my post above, I hope it's not my node who broke the network!

If you see my post above, I hope it's not my node who broke the network!

Whats your IP, Id like to see if you are banned on any of my 3 nodes?

Whats your IP, Id like to see if you are banned on any of my 3 nodes?

The mining node now on block 41309 is 94.130.49.121 or 2a01:4f8:10b:26e3::2

The mining node now on block 41309 is 94.130.49.121 or 2a01:4f8:10b:26e3::2

Ah, good news, we had Exactly 50-50 on both chains!  I just resynced one node, and the balance is shifting.  Im observing this very closely to see if the reset of the net syncs up to 41309+...  I just see one node is reorging by itself.
Unfortunately Ive got company stopping in now, I may be gone for a litle while. 

Ah, good news, we had Exactly 50-50 on both chains!  I just resynced one node, and the balance is shifting.  Im observing this very closely to see if the reset of the net syncs up to 41309+...  I just see one node is reorging by itself.
Unfortunately Ive got company stopping in now, I may be gone for a litle while.

haha no worries. It's 3 am so I won't be up for long too.

Also,  I only brought the two nodes I talked about in my 2 previous posts above. 1 mining and 1 non-mining that's it.

This is what happened around the time of the "fork" so I'm wondering if it could have been me.

hmm.. so I decided to turn mining on for one of the node and leave mining off for the other one so I could compare it and....

The node not mining didn't like the blocks of the node mining? This is what appeared immediately after:

2017-11-16 11:07:57 IsBlockPayeeValid -- ERROR: Invalid masternode payment detected at height 41101: CTransaction(hash=88bf52d0cb, ver=1, vin.size=1, vout.size=3, nLockTime=0)
    CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 038da0000107)
    CTxOut(nValue=7749.70501005, scriptPubKey=2102678e7dc966def90b47ee67e28a)
    CTxOut(nValue=13.02700000, scriptPubKey=2102678e7dc966def90b47ee67e28a)
    CTxOut(nValue=7762.73201004, scriptPubKey=76a914e32c41f9a7dd95011fcdd66e)
2017-11-16 11:07:57 ERROR: ConnectBlock(biblepay): couldn't find masternode or superblock payments
2017-11-16 11:07:57 InvalidChainFound: invalid block=8dc6e2f72ed1ecd72d2dcdfc2349d229c7afe987d886a24edcd027ef0dffc055  height=41101  log2_work=45.429083  date=2017-11-16 11:07:52
2017-11-16 11:07:57 InvalidChainFound:  current best=4235f1419b54be4e2587ed371b1ecad7c116a1744861d429b0df37770f373340  height=41100  log2_work=45.429078  date=2017-11-16 11:07:17
2017-11-16 11:07:57 ERROR: ConnectTip(): ConnectBlock 8dc6e2f72ed1ecd72d2dcdfc2349d229c7afe987d886a24edcd027ef0dffc055 failed
2017-11-16 11:07:57 InvalidChainFound: invalid block=8dc6e2f72ed1ecd72d2dcdfc2349d229c7afe987d886a24edcd027ef0dffc055  height=41101  log2_work=45.429083  date=2017-11-16 11:07:52
2017-11-16 11:07:57 InvalidChainFound:  current best=4235f1419b54be4e2587ed371b1ecad7c116a1744861d429b0df37770f373340  height=41100  log2_work=45.429078  date=2017-11-16 11:07:17
2017-11-16 11:07:57 ProcessNewBlock : ACCEPTED
2017-11-16 11:07:58 ERROR: AcceptBlockHeader: block is marked invalid
2017-11-16 11:07:58 ERROR: invalid header received 8dc6e2f72ed1ecd72d2dcdfc2349d229c7afe987d886a24edcd027ef0dffc055
2017-11-16 11:08:43 ERROR: AcceptBlockHeader: prev block invalid
2017-11-16 11:08:43 Misbehaving: 94.130.49.121:40001 (0 -> 100) BAN THRESHOLD EXCEEDED
2017-11-16 11:08:43 ERROR: invalid header received 8e4bf23f0f469470c24c70fd52d35cac975b36df65a1f5c99f05edae5be0132f
2017-11-16 11:08:43 ERROR: AcceptBlockHeader: prev block invalid
2017-11-16 11:08:43 Misbehaving: [2a01:4f8:10b:26e3::2]:34718 (0 -> 100) BAN THRESHOLD EXCEEDED
2017-11-16 11:08:43 ERROR: invalid header received 8e4bf23f0f469470c24c70fd52d35cac975b36df65a1f5c99f05edae5be0132f
2017-11-16 11:08:49 ERROR: AcceptBlockHeader: prev block invalid
2017-11-16 11:08:49 Misbehaving: [2001:0:9d38:6ab8:34dd:1fdc:d97b:d656]:54081 (0 -> 100) BAN THRESHOLD EXCEEDED
2017-11-16 11:08:49 ERROR: invalid header received 8e4bf23f0f469470c24c70fd52d35cac975b36df65a1f5c99f05edae5be0132f

94.130.49.121 and 2a01:4f8:10b:26e3::2 is the same machine which is the node I just activated mining on btw.

I didn't see any error on the mining node and it is still happily mining.

The node mining is now on block 41112 while the other one seems to be stuck on 41100.

I've been trying to get my masternode up and running again (making sure watchdog is functioning).

My sanctuary wallet was indeed stuck on a certain block and wouldn't sync. But I've reindexed both and it seems I'm on the right chain right now (both wallets are on the same block).

Controller wallet:

Code: [Select]


{
  "version": 1000506,
  "protocolversion": 70708,
  "walletversion": 61000,
  "wallet_fullversion": "1.0.5.6",
  "balance": 38514484.00745234,
  "privatesend_balance": 0.00000000,
  "blocks": 41330,
  "timeoffset": -2,
  "connections": 3,
  "proxy": "",
  "difficulty": 0.1980807012241197,
  "testnet": true,
  "keypoololdest": 1507285625,
  "keypoolsize": 1001,
  "paytxfee": 0.00000000,
  "relayfee": 0.00010000,
  "errors": ""
}

Sanctuary wallet:

Code: [Select]

{
  "version": 1000508,
  "protocolversion": 70708,
  "walletversion": 61000,
  "wallet_fullversion": "1.0.5.8",
  "balance": 0.00000000,
  "privatesend_balance": 0.00000000,
  "blocks": 41330,
  "timeoffset": 0,
  "connections": 8,
  "proxy": "",
  "difficulty": 0.1980807012241197,
  "testnet": true,
  "keypoololdest": 1508425662,
  "keypoolsize": 1001,
  "paytxfee": 0.00000000,
  "relayfee": 0.00010000,
  "errors": ""
}

The only thing now is that the 'masternodelist' command gets different results on my controller and sanctuary wallet.

Controller wallet:

Code: [Select]

17:21:14

{
  "04ca4bd54153476e6d19b72dc26bc27b74cdbbd687aea07c6cc1cd2182beab60-1": "NEW_START_REQUIRED",
  "a23321871670924fa669c26284aeb9b36987d6bb3d7a590eaf2b5406b85201f4-1": "ENABLED",
  "a27ae7dcc93df0ff266d2f11cb906f4929b7ad7d6b46bc98c192ac7998aa1058-1": "WATCHDOG_EXPIRED",
  "8ff3d83216612e2c79a36c5f66f191b34a07eb1d01600b104a76b3151de9e7f6-1": "NEW_START_REQUIRED",
  "78a235e8d3427b7fec1a0f3635cf3aeb2dbf7d0d53c44578815060d80280a271-1": "ENABLED",
  "7b3873de1969b087f63cd287c64694b14250aecf7779c67f68691533a6616f3c-1": "NEW_START_REQUIRED",
  "d183b913e7a4b95c0202bf15d296e00bbdf0bedce317e340985a2c78af06cba4-1": "ENABLED",
  "404f50700e2ffc8c4adb76bea92fb572584b1f3e24ec736d6883a64cc88417fb-1": "ENABLED",
  "be3eaf8322909bbb150d89058bf261f0a2bf96369c8928313a3d69e2d5087add-1": "ENABLED",
  "e413e134f7ecb6388ddfe401870f1e0ba602479abb8de8a5bf78c59c4087ee28-1": "NEW_START_REQUIRED",
  "b0cfdfa2194556e211099bc620a7e27487958aa5774db0c78ded0f839e3105d2-1": "NEW_START_REQUIRED",
  "c5a8405cbc39dd97004a64c1db586313ed25f3c4553ca59a0bdad30dd0c551d5-1": "NEW_START_REQUIRED",
  "44d550fef16c8bc5e340599cddbd6d98736218e1900f92b4625768e5830abfd0-1": "NEW_START_REQUIRED",
  "847be5b647856e9b030d785d7bc82f146362371a28663348e7a3d28df3e38c55-1": "ENABLED"
}

Sanctuary wallet:

Code: [Select]

{
  "04ca4bd54153476e6d19b72dc26bc27b74cdbbd687aea07c6cc1cd2182beab60-1": "NEW_START_REQUIRED",
  "a23321871670924fa669c26284aeb9b36987d6bb3d7a590eaf2b5406b85201f4-1": "ENABLED",
  "a27ae7dcc93df0ff266d2f11cb906f4929b7ad7d6b46bc98c192ac7998aa1058-1": "NEW_START_REQUIRED",
  "8ff3d83216612e2c79a36c5f66f191b34a07eb1d01600b104a76b3151de9e7f6-1": "NEW_START_REQUIRED",
  "78a235e8d3427b7fec1a0f3635cf3aeb2dbf7d0d53c44578815060d80280a271-1": "NEW_START_REQUIRED",
  "7b3873de1969b087f63cd287c64694b14250aecf7779c67f68691533a6616f3c-1": "NEW_START_REQUIRED",
  "d183b913e7a4b95c0202bf15d296e00bbdf0bedce317e340985a2c78af06cba4-1": "NEW_START_REQUIRED",
  "404f50700e2ffc8c4adb76bea92fb572584b1f3e24ec736d6883a64cc88417fb-1": "NEW_START_REQUIRED",
  "be3eaf8322909bbb150d89058bf261f0a2bf96369c8928313a3d69e2d5087add-1": "NEW_START_REQUIRED",
  "b0cfdfa2194556e211099bc620a7e27487958aa5774db0c78ded0f839e3105d2-1": "NEW_START_REQUIRED",
  "e413e134f7ecb6388ddfe401870f1e0ba602479abb8de8a5bf78c59c4087ee28-1": "NEW_START_REQUIRED",
  "44d550fef16c8bc5e340599cddbd6d98736218e1900f92b4625768e5830abfd0-1": "NEW_START_REQUIRED",
  "c5a8405cbc39dd97004a64c1db586313ed25f3c4553ca59a0bdad30dd0c551d5-1": "NEW_START_REQUIRED",
  "847be5b647856e9b030d785d7bc82f146362371a28663348e7a3d28df3e38c55-1": "ENABLED"
}

I am 'a23321871670924fa669c26284aeb9b36987d6bb3d7a590eaf2b5406b85201f4' btw.

haha no worries. It's 3 am so I won't be up for long too.

Also,  I only brought the two nodes I talked about in my 2 previous posts above. 1 mining and 1 non-mining that's it.

This is what happened around the time of the "fork" so I'm wondering if it could have been me.

Cool, I took a look at that log, and I can see how that particular node would go off on its own and ban everyone.  In this case, it did not have the same mncache.dat view that everyone else had, so its mnpayment schedule was different, and since we enforce masternode recipients, it was not going to agree on the next block (because it couldnt fill out a masternode while the supermajority could). The question is how did it get all synced with a different view of mncache?  Probably because of the headers it rejected it was mining on a fork or something earlier.

The other thing is, if we have a supermajority that is synced with synced masternode data, a couple bad fraudulently compiled nodes with hosed up integrated business logic compiled in should not be able to take us down.  Of course with the fragility of testnet, having only 4 synced masternodes, its possible to hose us up if you bring just 2 bad nodes online. 

Either way lets move past this one and wait til you have the checkblock(1) error showing and then maybe that will shed light on why your headers were rejected. 

I've been trying to get my masternode up and running again (making sure watchdog is functioning).

My sanctuary wallet was indeed stuck on a certain block and wouldn't sync. But I've reindexed both and it seems I'm on the right chain right now (both wallets are on the same block).

Controller wallet:

Code: [Select]


{
  "version": 1000506,
  "protocolversion": 70708,
  "walletversion": 61000,
  "wallet_fullversion": "1.0.5.6",
  "balance": 38514484.00745234,
  "privatesend_balance": 0.00000000,
  "blocks": 41330,
  "timeoffset": -2,
  "connections": 3,
  "proxy": "",
  "difficulty": 0.1980807012241197,
  "testnet": true,
  "keypoololdest": 1507285625,
  "keypoolsize": 1001,
  "paytxfee": 0.00000000,
  "relayfee": 0.00010000,
  "errors": ""
}

Sanctuary wallet:

Code: [Select]

{
  "version": 1000508,
  "protocolversion": 70708,
  "walletversion": 61000,
  "wallet_fullversion": "1.0.5.8",
  "balance": 0.00000000,
  "privatesend_balance": 0.00000000,
  "blocks": 41330,
  "timeoffset": 0,
  "connections": 8,
  "proxy": "",
  "difficulty": 0.1980807012241197,
  "testnet": true,
  "keypoololdest": 1508425662,
  "keypoolsize": 1001,
  "paytxfee": 0.00000000,
  "relayfee": 0.00010000,
  "errors": ""
}

The only thing now is that the 'masternodelist' command gets different results on my controller and sanctuary wallet.

Controller wallet:

Code: [Select]

17:21:14

{
  "04ca4bd54153476e6d19b72dc26bc27b74cdbbd687aea07c6cc1cd2182beab60-1": "NEW_START_REQUIRED",
  "a23321871670924fa669c26284aeb9b36987d6bb3d7a590eaf2b5406b85201f4-1": "ENABLED",
  "a27ae7dcc93df0ff266d2f11cb906f4929b7ad7d6b46bc98c192ac7998aa1058-1": "WATCHDOG_EXPIRED",
  "8ff3d83216612e2c79a36c5f66f191b34a07eb1d01600b104a76b3151de9e7f6-1": "NEW_START_REQUIRED",
  "78a235e8d3427b7fec1a0f3635cf3aeb2dbf7d0d53c44578815060d80280a271-1": "ENABLED",
  "7b3873de1969b087f63cd287c64694b14250aecf7779c67f68691533a6616f3c-1": "NEW_START_REQUIRED",
  "d183b913e7a4b95c0202bf15d296e00bbdf0bedce317e340985a2c78af06cba4-1": "ENABLED",
  "404f50700e2ffc8c4adb76bea92fb572584b1f3e24ec736d6883a64cc88417fb-1": "ENABLED",
  "be3eaf8322909bbb150d89058bf261f0a2bf96369c8928313a3d69e2d5087add-1": "ENABLED",
  "e413e134f7ecb6388ddfe401870f1e0ba602479abb8de8a5bf78c59c4087ee28-1": "NEW_START_REQUIRED",
  "b0cfdfa2194556e211099bc620a7e27487958aa5774db0c78ded0f839e3105d2-1": "NEW_START_REQUIRED",
  "c5a8405cbc39dd97004a64c1db586313ed25f3c4553ca59a0bdad30dd0c551d5-1": "NEW_START_REQUIRED",
  "44d550fef16c8bc5e340599cddbd6d98736218e1900f92b4625768e5830abfd0-1": "NEW_START_REQUIRED",
  "847be5b647856e9b030d785d7bc82f146362371a28663348e7a3d28df3e38c55-1": "ENABLED"
}

Sanctuary wallet:

Code: [Select]

{
  "04ca4bd54153476e6d19b72dc26bc27b74cdbbd687aea07c6cc1cd2182beab60-1": "NEW_START_REQUIRED",
  "a23321871670924fa669c26284aeb9b36987d6bb3d7a590eaf2b5406b85201f4-1": "ENABLED",
  "a27ae7dcc93df0ff266d2f11cb906f4929b7ad7d6b46bc98c192ac7998aa1058-1": "NEW_START_REQUIRED",
  "8ff3d83216612e2c79a36c5f66f191b34a07eb1d01600b104a76b3151de9e7f6-1": "NEW_START_REQUIRED",
  "78a235e8d3427b7fec1a0f3635cf3aeb2dbf7d0d53c44578815060d80280a271-1": "NEW_START_REQUIRED",
  "7b3873de1969b087f63cd287c64694b14250aecf7779c67f68691533a6616f3c-1": "NEW_START_REQUIRED",
  "d183b913e7a4b95c0202bf15d296e00bbdf0bedce317e340985a2c78af06cba4-1": "NEW_START_REQUIRED",
  "404f50700e2ffc8c4adb76bea92fb572584b1f3e24ec736d6883a64cc88417fb-1": "NEW_START_REQUIRED",
  "be3eaf8322909bbb150d89058bf261f0a2bf96369c8928313a3d69e2d5087add-1": "NEW_START_REQUIRED",
  "b0cfdfa2194556e211099bc620a7e27487958aa5774db0c78ded0f839e3105d2-1": "NEW_START_REQUIRED",
  "e413e134f7ecb6388ddfe401870f1e0ba602479abb8de8a5bf78c59c4087ee28-1": "NEW_START_REQUIRED",
  "44d550fef16c8bc5e340599cddbd6d98736218e1900f92b4625768e5830abfd0-1": "NEW_START_REQUIRED",
  "c5a8405cbc39dd97004a64c1db586313ed25f3c4553ca59a0bdad30dd0c551d5-1": "NEW_START_REQUIRED",
  "847be5b647856e9b030d785d7bc82f146362371a28663348e7a3d28df3e38c55-1": "ENABLED"
}

I am 'a23321871670924fa669c26284aeb9b36987d6bb3d7a590eaf2b5406b85201f4' btw.

Yeah, I have the same problem.  It looks like everyone who reindexed the chain today lost all their masternode data (stored in mncache.dat), all the governance objects are getting revoted on now etc.  So basically the masternode state is very bad in testnet.  We will have to wait a while to see if our 5 masternodes switch back to enabled. 

all 5 MNodes is ENABLED but we are STUCKED? 41124

all 5 MNodes is ENABLED but we are STUCKED? 41124

All my 3 nodes rolling at 41534 and synced; status = ENABLED, try on your bad node, try going to peers and ban anyone with a low height, and see if it syncs, if not -reindex.

I got some errors for you 

https://pastebin.com/NaHRQBi7

Also I'm not sure if you saw it but this is what I got on mainnet just before switching that box to testnet

2017-11-16 01:53:00 ProcessNewBlock : ACCEPTED
2017-11-16 02:01:14 CheckProofOfWork(1.0): BlockHash 333e1c9e6fc52027012f734b2b701a3325591759ec6f29686879faae98a4b585, ProdChain TRUE, SSLVersion OpenSSL 1.0.1t  3 May 2016, BlockTime 1510797674.000000, PrevBlockTime 1510797171.000000, BibleHash 0000000000072c18e0c42605b5431bd2e2343ced7942038c6a39f76ffa077225, TargetHash 000000000007e281000000000000000000000000000000000000000000000000, Forensics exec biblehash 333e1c9e6fc52027012f734b2b701a3325591759ec6f29686879faae98a4b585 1510797674 1510797171 16911
2017-11-16 02:01:14 ERROR: CheckProofOfWork(1): BibleHash does not meet POW level, prevheight 16911.000000 pindexPrev f3479b24cae1e5b5fb10572b0eac0ea45492f7f4e32e88029ce72eb6cd48b1bb
2017-11-16 02:01:14 ERROR: CheckBlockHeader(): proof of work failed
2017-11-16 02:01:14 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-11-16 02:01:14 Misbehaving: 217.182.73.71:40000 (0 -> 5)
2017-11-16 02:01:14 UpdateTip: new best=333e1c9e6fc52027012f734b2b701a3325591759ec6f29686879faae98a4b585  height=16912  log2_work=57.78389  tx=28553  date=2017-11-16 02:01:14 progress=1.000000  cache=0.0MiB(7tx)
--
2017-11-16 03:03:15 ProcessNewBlock : ACCEPTED
2017-11-16 03:03:39 CheckProofOfWork(1.0): BlockHash 5468ae8523dbe8fc9d895343f0deb9f27a7d74763eb4d0cf8e71a419c77b5395, ProdChain TRUE, SSLVersion OpenSSL 1.0.1t  3 May 2016, BlockTime 1510801402.000000, PrevBlockTime 1510801390.000000, BibleHash 00000000000677ab6388f8cd607de8c458d9083599fef6192c63b517bf3eb730, TargetHash 00000000000a858a000000000000000000000000000000000000000000000000, Forensics exec biblehash 5468ae8523dbe8fc9d895343f0deb9f27a7d74763eb4d0cf8e71a419c77b5395 1510801402 1510801390 16917
2017-11-16 03:03:39 ERROR: CheckProofOfWork(1): BibleHash does not meet POW level, prevheight 16917.000000 pindexPrev 89d18d6ae6043337ed9b650244e7e4fac4004aa7d61e40e892d51ea9dd9e7955
2017-11-16 03:03:39 ERROR: CheckBlockHeader(): proof of work failed
2017-11-16 03:03:39 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-11-16 03:03:39 Misbehaving: 208.113.166.223:40000 (0 -> 5)
2017-11-16 03:03:39 UpdateTip: new best=5468ae8523dbe8fc9d895343f0deb9f27a7d74763eb4d0cf8e71a419c77b5395  height=16918  log2_work=57.785222  tx=28561  date=2017-11-16 03:03:22 progress=0.999999  cache=0.0MiB(16tx)
--
2017-11-16 03:44:09 ProcessNewBlock : ACCEPTED
2017-11-16 03:57:38 CheckProofOfWork(1.0): BlockHash 6c8efa4788a6aa5e42d2d7b5f54fe24e1f9fb4483fa707fcfe4b4c8ec0bbdf57, ProdChain TRUE, SSLVersion OpenSSL 1.0.1t  3 May 2016, BlockTime 1510804572.000000, PrevBlockTime 1510803844.000000, BibleHash 0000000000007a70102622f79b71810b12687066d52a06d53ff74f9a59389587, TargetHash 00000000000947eb000000000000000000000000000000000000000000000000, Forensics exec biblehash 6c8efa4788a6aa5e42d2d7b5f54fe24e1f9fb4483fa707fcfe4b4c8ec0bbdf57 1510804572 1510803844 16922
2017-11-16 03:57:38 ERROR: CheckProofOfWork(1): BibleHash does not meet POW level, prevheight 16922.000000 pindexPrev c49314cb92548b7722cccbb773922c48f3eb4fe9fe6a0e3c95a129312f9161c8
2017-11-16 03:57:38 ERROR: CheckBlockHeader(): proof of work failed
2017-11-16 03:57:38 Misbehaving: 208.113.166.223:40000 (5 -> 10)
2017-11-16 03:57:38 ERROR: invalid header received 6c8efa4788a6aa5e42d2d7b5f54fe24e1f9fb4483fa707fcfe4b4c8ec0bbdf57
2017-11-16 03:57:38 UpdateTip: new best=6c8efa4788a6aa5e42d2d7b5f54fe24e1f9fb4483fa707fcfe4b4c8ec0bbdf57  height=16923  log2_work=57.786245  tx=28570  date=2017-11-16 03:56:12 progress=0.999997  cache=0.0MiB(38tx)