Author

Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 113. (Read 243386 times)

full member
Activity: 1260
Merit: 115
https://chainz.cryptoid.info/bbp/
http://explorer.biblepay.org/

Updated explorer to latest version, performed an erasechain, its synced back up now

I think its been pretty reliable, and I think its good to have a backup explorer (from our history)
Id be totally fine with the url being set to the chainz one though
and I will gladly pass on the job of running the 2nd explorer to anyone interested!
(or if there is some other service we could use)

Iquidus explorer is slow, and has higher costs
Chainz explorer is fast, and has more features

Note: Theres a guy working on multithreading (clustering) Iquidus if anyone is interested to help him
https://github.com/iquidus/explorer/pull/257

This is more related to some prior projects - not iquidis, but its worth a try, could you try this in the config:
rpcthreads=500
litemode=1

And resync?  
I was under the impression with Evo we were communicating much faster with Iquidis (I remember you said there is a big difference), but apparently iquidis gets hung occasionally.

So also could you clarify if the node itself is stuck 200 blocks behind, or is it iquidis that ceases to sync?  (If its not the node, there is no need to resync the entire chain, if its iquidis we would just resync the iquidis database.  But the rpc settings might help if its too dumb to recover).  Maybe the daemon is dying, maybe research how to persistenly keep the daemon running also.

The daemon is running fine, its fully synced, checked blockhashes
(Theres a crontab firing every 5 minutes to make sure its running and restart it if it isnt)

I checked mongodb, log file was 5.3GB, not sure if that is slowing things down, deleted it
I edited the mongod.conf file to try to limit the logging [set quiet to enabled]
(easy worst case I can add a crontab to just delete the log file every day)

Running everything again, everything is going, but the website is not updating with latest blocks, weird,
but if you type in a block number it will show/load it

I started looking into the indexing process more, and it fires off and then disappears quick,
I sent the output to a file, theres an error in Iquidus

Code:
/home/explorer/lib/explorer.js:310
      if (vout[0].scriptPubKey.type == 'nonstandard') {
                 ^
 
TypeError: Cannot read property 'scriptPubKey' of undefined
    at /home/explorer/lib/explorer.js:310:18
    at Object.loop.next (/home/explorer/lib/explorer.js:194:24)
    at Object.module.exports.syncLoop (/home/explorer/lib/explorer.js:205:10)
    at Object.module.exports.prepare_vout (/home/explorer/lib/explorer.js:284:20)
    at /home/explorer/lib/database.js:141:17
    at /home/explorer/lib/explorer.js:392:14
    at Object.loop.next (/home/explorer/lib/explorer.js:194:24)
    at Object.module.exports.syncLoop (/home/explorer/lib/explorer.js:205:10)
    at Object.module.exports.prepare_vin (/home/explorer/lib/explorer.js:369:20)
    at /home/explorer/lib/database.js:140:15
    at Request._callback (/home/explorer/lib/explorer.js:107:14)
    at Request.self.callback (/home/explorer/node_modules/request/request.js:187:22)
    at emitTwo (events.js:87:13)
    at Request.emit (events.js:172:7)
    at Request. (/home/explorer/node_modules/request/request.js:1044:10)
    at emitOne (events.js:77:13)


Looks like its happening in the 3rd parameter, an anonymous function, getting passed into syncLoop()

prepare_vout():
https://github.com/iquidus/explorer/blob/master/lib/explorer.js#L310

syncLoop():
https://github.com/iquidus/explorer/blob/c8ac131aed4f065b4f327ec379eaef2a006e5f50/lib/explorer.js#L169

Looks like this guy ran into similar issue
https://github.com/iquidus/explorer/issues/60
and posted this solution: https://github.com/cryptorex/bitcoinz-explorer/commit/267a0dfd8015bc90488b2b53ae9c49be2da83bff
Ill try adding it and report back

===

Iquidus Block Explorer Guide
https://www.reddit.com/r/BiblePay/comments/7elm7r/iquidus_block_explorer_guide/

===

Options:
1. Try to pinpoint the bug
2. Reset the mongo database to last backup and sync from there
3. Reset the mongo database entirely and sync from the beginning
4. Retire the explorer
5. Change URL to point to Chainz
6. Find and setup 2nd explorer service
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
** DETERMINISTIC SANCS / GIN / PROD **


I promised to mention the status of Prod/dip3 and Deterministic sancs upgrade.

So our prod chain has voted in dip3 successfully, and we will soon be able to continue upgrading to deterministic sancs in prod.

But I would like to make one small change to the schedule.

Since it is so late into July, and our superblock is near, lets postpone the deterministic sancs upgrade until August (after our July superblock pays out).

I will modify the schedule now.

https://wiki.biblepay.org/Evolution_Upgrade

full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
Two of my machines that I started with -erasechain=1 yesterday have again come out of sync.  I'm doing erasechain again but I'm wondering if this is caused by explorer.biblepay.org being stuck?

I don't think there is a relation. I have all my machines synced without problems

@Togo thanks for the effort. I think that it's again stuck like 100 block behind again.

Probably Iquidus is not the most efficient setup for long chains, I agree with you.
Good point.  He could possibly investigate other explorer branches - but so far I see Dash-Green is also running iquidis.  MIP maybe you can find out what explorer Dash uses when you have a free minute.

full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
https://chainz.cryptoid.info/bbp/
http://explorer.biblepay.org/

Updated explorer to latest version, performed an erasechain, its synced back up now

I think its been pretty reliable, and I think its good to have a backup explorer (from our history)
Id be totally fine with the url being set to the chainz one though
and I will gladly pass on the job of running the 2nd explorer to anyone interested!
(or if there is some other service we could use)

Iquidus explorer is slow, and has higher costs
Chainz explorer is fast, and has more features

Note: Theres a guy working on multithreading (clustering) Iquidus if anyone is interested to help him
https://github.com/iquidus/explorer/pull/257

This is more related to some prior projects - not iquidis, but its worth a try, could you try this in the config:
rpcthreads=500
litemode=1

And resync? 
I was under the impression with Evo we were communicating much faster with Iquidis (I remember you said there is a big difference), but apparently iquidis gets hung occasionally.

So also could you clarify if the node itself is stuck 200 blocks behind, or is it iquidis that ceases to sync?  (If its not the node, there is no need to resync the entire chain, if its iquidis we would just resync the iquidis database.  But the rpc settings might help if its too dumb to recover).  Maybe the daemon is dying, maybe research how to persistenly keep the daemon running also.

Btw, I sent you a PM and 2 emails but have not received a reply.

full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
Two of my machines that I started with -erasechain=1 yesterday have again come out of sync.  I'm doing erasechain again but I'm wondering if this is caused by explorer.biblepay.org being stuck?

Let's try to find the root cause.  Do you happen to have the log of one of the machines before it went out of sync?

B) Is this machine running with litemode=1? 

We need to see if the machine is having trouble getting gov data.
Do you have tons of banned peers in the peers list?

MIP
newbie
Activity: 362
Merit: 0
Two of my machines that I started with -erasechain=1 yesterday have again come out of sync.  I'm doing erasechain again but I'm wondering if this is caused by explorer.biblepay.org being stuck?

I don't think there is a relation. I have all my machines synced without problems

@Togo thanks for the effort. I think that it's again stuck like 100 block behind again.

Probably Iquidus is not the most efficient setup for long chains, I agree with you.
newbie
Activity: 99
Merit: 0
Two of my machines that I started with -erasechain=1 yesterday have again come out of sync.  I'm doing erasechain again but I'm wondering if this is caused by explorer.biblepay.org being stuck?
full member
Activity: 1260
Merit: 115
https://chainz.cryptoid.info/bbp/
http://explorer.biblepay.org/

Updated explorer to latest version, performed an erasechain, its synced back up now

I think its been pretty reliable, and I think its good to have a backup explorer (from our history)
Id be totally fine with the url being set to the chainz one though
and I will gladly pass on the job of running the 2nd explorer to anyone interested!
(or if there is some other service we could use)

Iquidus explorer is slow, and has higher costs
Chainz explorer is fast, and has more features

Note: Theres a guy working on multithreading (clustering) Iquidus if anyone is interested to help him
https://github.com/iquidus/explorer/pull/257
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
I would say http://explorer.biblepay.org:3001 is stuck in block 132234 (we are now like 436 blocks ahead that)

It's not forked because blockhashes match.

Official Explorer seem have problem since the block already @132880 now.
Also found it seem have a fork problem?Even I deleted all files and reindex, few days later , some wallet show different blockhash(config are same, maybe some nodes are moving on the wrong road, and some of my machines are coincidentally connected to the node which is on wrong direction.).

 getblockhash 132863

(chainz.cryptoid.info is on this way)
f8ef624e2e81b666f48c6ecef6a18d5ec789c323b71f10d6b31911efe7db8457

186e46fb047626477e400f644497b85e7c202a7512301595c9269c774de5cff3


I just ran my global sanc report and 100% of the nodes are in agreement with Chainz and my local node and the pool:

getblockhash 132922

03fe0f4fbd2ab5848404eb4dfddc543a1f759711201d4841af0169e2d4467e31

In this case it looks like explorer.biblepay.org is wrong - please resync the chain with the -erasechain=1.
Ive seen this happen after a reindex (reindex is not good for Biblepay, we will need to address this right now for the next version.  Im adding to my punchlist now).

If anyone ever goes out of sync, please start with -erasechain=1 and dont do the reindex suggestion that other communities use.  (It does not clean up governance at all and cant handle compact blocks or non fin tx or prayers or SAN data leaving your node in a corrupt state).

EDIT:  explorer.biblepay.org is not forked - its stuck on a block 500 blocks back (look at its hash)

I wonder if we should retire this explorer - if its going to be unreliable.  Togo, can you reset it?




newbie
Activity: 56
Merit: 0
I would say http://explorer.biblepay.org:3001 is stuck in block 132234 (we are now like 436 blocks ahead that)

It's not forked because blockhashes match.

Official Explorer seem have problem since the block already @132880 now.
Also found it seem have a fork problem?Even I deleted all files and reindex, few days later , some wallet show different blockhash(config are same, maybe some nodes are moving on the wrong road, and some of my machines are coincidentally connected to the node which is on wrong direction.).

 getblockhash 132863

(chainz.cryptoid.info is on this way)
f8ef624e2e81b666f48c6ecef6a18d5ec789c323b71f10d6b31911efe7db8457

186e46fb047626477e400f644497b85e7c202a7512301595c9269c774de5cff3
full member
Activity: 1260
Merit: 115
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
is this related to the abn problems?
seems I cannot pool mine without this happening after only a few minutes:
Code:
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132806, block.nbits 469802878.000000, next work 459223285.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132806, block.nbits 469802878.000000, next work 459223285.000000 (code 16)
I dont see a miner by the name of Nipar, please share miner name.


nickname=nichaols1
miner names are  np-01F and np-L2-F

I also downloaded the windows version with the updated getabnweight version 2.7 and it still happens
thanks.

I made a change to the pool to attempt to reveal the problem, did it just resolve (try to 'setgenerate true N') on one of the nodes?

Waiting for the leader board to update and show only 1 miner


No, I mean to see if the problem miner now has a valid ABN?



"poolinfo5": "Internal ABN: Invalid 1563578281; ",
  "abninfo": "Mining with funded Valid ABN 475241571a003cb33dc9c3b71304aea27e6c6d2d1cf221178ef8a39a31ba2bc1; Mining with funded Valid ABN 475241571a003cb33dc9c3b71304aea27e6c6d2d1cf221178ef8a39a31ba2bc1; "
and still produces that fail error


I think you are fixed;  it takes 3-5 mins for all errors to clear.

But the root of the issue was you couldn't get a valid ABN, now you have one.

Also, now if you drill into the leaderboard, you can see the health columns went to 100% now.


So far so good, setgenerate false then true on both, errors cleared. watched the debug log for a bit.

and now it's doing it again:

2019-07-19 23:34:41 {PNB}: ACC  BibleMiner -- started thread 0.000000
2019-07-19 23:35:26 BibleMiner -- started thread 1.000000
2019-07-19 23:35:26 BibleMiner -- started thread 2.000000
2019-07-19 23:35:27 BibleMiner -- started thread 3.000000
2019-07-19 23:35:27 BibleMiner -- started thread 4.000000
2019-07-19 23:35:27 BibleMiner -- started thread 5.000000
2019-07-19 23:35:27  ** Started 6.000000 BibleMiner threads. **
2019-07-19 23:36:11 UpdateTip: new best=297f95c8a0694d9390977b6899cd882825b9565a830d1e570eb717c5172625f1 height=132814 version=0x2000000c log2_work=59.51361825 tx=1098411 date='2019-07-19 23:36:10' progress=1.000000 cache=0.0MiB(0txo)
2019-07-19 23:36:11 {PNB}: ACC
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:29
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:29
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:29
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:29
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:30
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)



this is the linux version of 1443 with getabnweight version 2.6
I am now also recieving a lot of stale blocks from the pool.


..



What is the timestamp range of stale blocks in the log, did it continue?  I believe this is normal behavior.



the stale blocks are not recorded in the debug log.
however there is this:

2019-07-20 00:14:23
ContextualCheckBlock::ABN ERROR!  Block 132819.000000 does not meet anti-bot-net-minimum required guidelines: ReqABNHeight 128597.000000, BlockWeight 0.000000, RequiredWeight 125000.000000UpdateTip: new best=61a0212f43f1849d2f5556be625612edd8ed65d00c2271cd42bd5a30b0cf6894 height=132819 version=0x2000000c log2_work=59.51363320 tx=1098431 date='2019-07-20 00:14:17' progress=1.000000 cache=0.0MiB(0txo)
2019-07-20 00:14:23 {PNB}: ACC



...

We get a little bit of spam per block change in this version, just let it go for tonight and see if you fail to get an ABN for more than 5 mins.

In the next version, Ill make it do an extra test each time it gets an ABN and keep it out of the log, that should help keep the log clean.

jr. member
Activity: 55
Merit: 2
is this related to the abn problems?
seems I cannot pool mine without this happening after only a few minutes:
Code:
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132806, block.nbits 469802878.000000, next work 459223285.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132806, block.nbits 469802878.000000, next work 459223285.000000 (code 16)
I dont see a miner by the name of Nipar, please share miner name.


nickname=nichaols1
miner names are  np-01F and np-L2-F

I also downloaded the windows version with the updated getabnweight version 2.7 and it still happens
thanks.

I made a change to the pool to attempt to reveal the problem, did it just resolve (try to 'setgenerate true N') on one of the nodes?

Waiting for the leader board to update and show only 1 miner


No, I mean to see if the problem miner now has a valid ABN?



"poolinfo5": "Internal ABN: Invalid 1563578281; ",
  "abninfo": "Mining with funded Valid ABN 475241571a003cb33dc9c3b71304aea27e6c6d2d1cf221178ef8a39a31ba2bc1; Mining with funded Valid ABN 475241571a003cb33dc9c3b71304aea27e6c6d2d1cf221178ef8a39a31ba2bc1; "
and still produces that fail error


I think you are fixed;  it takes 3-5 mins for all errors to clear.

But the root of the issue was you couldn't get a valid ABN, now you have one.

Also, now if you drill into the leaderboard, you can see the health columns went to 100% now.


So far so good, setgenerate false then true on both, errors cleared. watched the debug log for a bit.

and now it's doing it again:

2019-07-19 23:34:41 {PNB}: ACC  BibleMiner -- started thread 0.000000
2019-07-19 23:35:26 BibleMiner -- started thread 1.000000
2019-07-19 23:35:26 BibleMiner -- started thread 2.000000
2019-07-19 23:35:27 BibleMiner -- started thread 3.000000
2019-07-19 23:35:27 BibleMiner -- started thread 4.000000
2019-07-19 23:35:27 BibleMiner -- started thread 5.000000
2019-07-19 23:35:27  ** Started 6.000000 BibleMiner threads. **
2019-07-19 23:36:11 UpdateTip: new best=297f95c8a0694d9390977b6899cd882825b9565a830d1e570eb717c5172625f1 height=132814 version=0x2000000c log2_work=59.51361825 tx=1098411 date='2019-07-19 23:36:10' progress=1.000000 cache=0.0MiB(0txo)
2019-07-19 23:36:11 {PNB}: ACC
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:29
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:29
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:29
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:29
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:30
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)



this is the linux version of 1443 with getabnweight version 2.6
I am now also recieving a lot of stale blocks from the pool.


..



What is the timestamp range of stale blocks in the log, did it continue?  I believe this is normal behavior.



the stale blocks are not recorded in the debug log.
however there is this:

2019-07-20 00:14:23
ContextualCheckBlock::ABN ERROR!  Block 132819.000000 does not meet anti-bot-net-minimum required guidelines: ReqABNHeight 128597.000000, BlockWeight 0.000000, RequiredWeight 125000.000000UpdateTip: new best=61a0212f43f1849d2f5556be625612edd8ed65d00c2271cd42bd5a30b0cf6894 height=132819 version=0x2000000c log2_work=59.51363320 tx=1098431 date='2019-07-20 00:14:17' progress=1.000000 cache=0.0MiB(0txo)
2019-07-20 00:14:23 {PNB}: ACC



...
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
is this related to the abn problems?
seems I cannot pool mine without this happening after only a few minutes:
Code:
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132806, block.nbits 469802878.000000, next work 459223285.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132806, block.nbits 469802878.000000, next work 459223285.000000 (code 16)
I dont see a miner by the name of Nipar, please share miner name.


nickname=nichaols1
miner names are  np-01F and np-L2-F

I also downloaded the windows version with the updated getabnweight version 2.7 and it still happens
thanks.

I made a change to the pool to attempt to reveal the problem, did it just resolve (try to 'setgenerate true N') on one of the nodes?

Waiting for the leader board to update and show only 1 miner


No, I mean to see if the problem miner now has a valid ABN?



"poolinfo5": "Internal ABN: Invalid 1563578281; ",
  "abninfo": "Mining with funded Valid ABN 475241571a003cb33dc9c3b71304aea27e6c6d2d1cf221178ef8a39a31ba2bc1; Mining with funded Valid ABN 475241571a003cb33dc9c3b71304aea27e6c6d2d1cf221178ef8a39a31ba2bc1; "
and still produces that fail error


I think you are fixed;  it takes 3-5 mins for all errors to clear.

But the root of the issue was you couldn't get a valid ABN, now you have one.

Also, now if you drill into the leaderboard, you can see the health columns went to 100% now.


So far so good, setgenerate false then true on both, errors cleared. watched the debug log for a bit.

and now it's doing it again:

2019-07-19 23:34:41 {PNB}: ACC  BibleMiner -- started thread 0.000000
2019-07-19 23:35:26 BibleMiner -- started thread 1.000000
2019-07-19 23:35:26 BibleMiner -- started thread 2.000000
2019-07-19 23:35:27 BibleMiner -- started thread 3.000000
2019-07-19 23:35:27 BibleMiner -- started thread 4.000000
2019-07-19 23:35:27 BibleMiner -- started thread 5.000000
2019-07-19 23:35:27  ** Started 6.000000 BibleMiner threads. **
2019-07-19 23:36:11 UpdateTip: new best=297f95c8a0694d9390977b6899cd882825b9565a830d1e570eb717c5172625f1 height=132814 version=0x2000000c log2_work=59.51361825 tx=1098411 date='2019-07-19 23:36:10' progress=1.000000 cache=0.0MiB(0txo)
2019-07-19 23:36:11 {PNB}: ACC
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:29
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:29
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:29
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:29
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:30
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)



this is the linux version of 1443 with getabnweight version 2.6
I am now also recieving a lot of stale blocks from the pool.


..



What is the timestamp range of stale blocks in the log, did it continue?  I believe this is normal behavior.

jr. member
Activity: 55
Merit: 2
is this related to the abn problems?
seems I cannot pool mine without this happening after only a few minutes:
Code:
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132806, block.nbits 469802878.000000, next work 459223285.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132806, block.nbits 469802878.000000, next work 459223285.000000 (code 16)
I dont see a miner by the name of Nipar, please share miner name.


nickname=nichaols1
miner names are  np-01F and np-L2-F

I also downloaded the windows version with the updated getabnweight version 2.7 and it still happens
thanks.

I made a change to the pool to attempt to reveal the problem, did it just resolve (try to 'setgenerate true N') on one of the nodes?

Waiting for the leader board to update and show only 1 miner


No, I mean to see if the problem miner now has a valid ABN?



"poolinfo5": "Internal ABN: Invalid 1563578281; ",
  "abninfo": "Mining with funded Valid ABN 475241571a003cb33dc9c3b71304aea27e6c6d2d1cf221178ef8a39a31ba2bc1; Mining with funded Valid ABN 475241571a003cb33dc9c3b71304aea27e6c6d2d1cf221178ef8a39a31ba2bc1; "
and still produces that fail error


I think you are fixed;  it takes 3-5 mins for all errors to clear.

But the root of the issue was you couldn't get a valid ABN, now you have one.

Also, now if you drill into the leaderboard, you can see the health columns went to 100% now.


So far so good, setgenerate false then true on both, errors cleared. watched the debug log for a bit.

and now it's doing it again:

2019-07-19 23:34:41 {PNB}: ACC  BibleMiner -- started thread 0.000000
2019-07-19 23:35:26 BibleMiner -- started thread 1.000000
2019-07-19 23:35:26 BibleMiner -- started thread 2.000000
2019-07-19 23:35:27 BibleMiner -- started thread 3.000000
2019-07-19 23:35:27 BibleMiner -- started thread 4.000000
2019-07-19 23:35:27 BibleMiner -- started thread 5.000000
2019-07-19 23:35:27  ** Started 6.000000 BibleMiner threads. **
2019-07-19 23:36:11 UpdateTip: new best=297f95c8a0694d9390977b6899cd882825b9565a830d1e570eb717c5172625f1 height=132814 version=0x2000000c log2_work=59.51361825 tx=1098411 date='2019-07-19 23:36:10' progress=1.000000 cache=0.0MiB(0txo)
2019-07-19 23:36:11 {PNB}: ACC
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:29
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:29
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:29
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:29
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)
2019-07-19 23:36:30
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132815, block.nbits 469800705.000000, next work 469794835.000000 (code 16)



this is the linux version of 1443 with getabnweight version 2.6
I am now also recieving a lot of stale blocks from the pool.


..

full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
is this related to the abn problems?
seems I cannot pool mine without this happening after only a few minutes:
Code:
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132806, block.nbits 469802878.000000, next work 459223285.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132806, block.nbits 469802878.000000, next work 459223285.000000 (code 16)
I dont see a miner by the name of Nipar, please share miner name.


nickname=nichaols1
miner names are  np-01F and np-L2-F

I also downloaded the windows version with the updated getabnweight version 2.7 and it still happens
thanks.

I made a change to the pool to attempt to reveal the problem, did it just resolve (try to 'setgenerate true N') on one of the nodes?

Waiting for the leader board to update and show only 1 miner


No, I mean to see if the problem miner now has a valid ABN?



"poolinfo5": "Internal ABN: Invalid 1563578281; ",
  "abninfo": "Mining with funded Valid ABN 475241571a003cb33dc9c3b71304aea27e6c6d2d1cf221178ef8a39a31ba2bc1; Mining with funded Valid ABN 475241571a003cb33dc9c3b71304aea27e6c6d2d1cf221178ef8a39a31ba2bc1; "
and still produces that fail error


I think you are fixed;  it takes 3-5 mins for all errors to clear.

But the root of the issue was you couldn't get a valid ABN, now you have one.

Also, now if you drill into the leaderboard, you can see the health columns went to 100% now.

jr. member
Activity: 55
Merit: 2
is this related to the abn problems?
seems I cannot pool mine without this happening after only a few minutes:
Code:
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132806, block.nbits 469802878.000000, next work 459223285.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132806, block.nbits 469802878.000000, next work 459223285.000000 (code 16)
I dont see a miner by the name of Nipar, please share miner name.


nickname=nichaols1
miner names are  np-01F and np-L2-F

I also downloaded the windows version with the updated getabnweight version 2.7 and it still happens
thanks.

I made a change to the pool to attempt to reveal the problem, did it just resolve (try to 'setgenerate true N') on one of the nodes?

Waiting for the leader board to update and show only 1 miner


No, I mean to see if the problem miner now has a valid ABN?



"poolinfo5": "Internal ABN: Invalid 1563578281; ",
  "abninfo": "Mining with funded Valid ABN 475241571a003cb33dc9c3b71304aea27e6c6d2d1cf221178ef8a39a31ba2bc1; Mining with funded Valid ABN 475241571a003cb33dc9c3b71304aea27e6c6d2d1cf221178ef8a39a31ba2bc1; "
and still produces that fail error
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
is this related to the abn problems?
seems I cannot pool mine without this happening after only a few minutes:
Code:
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132806, block.nbits 469802878.000000, next work 459223285.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132806, block.nbits 469802878.000000, next work 459223285.000000 (code 16)
I dont see a miner by the name of Nipar, please share miner name.


nickname=nichaols1
miner names are  np-01F and np-L2-F

I also downloaded the windows version with the updated getabnweight version 2.7 and it still happens
thanks.

I made a change to the pool to attempt to reveal the problem, did it just resolve (try to 'setgenerate true N') on one of the nodes?

Waiting for the leader board to update and show only 1 miner


No, I mean to see if the problem miner now has a valid ABN?

full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
is this related to the abn problems?
seems I cannot pool mine without this happening after only a few minutes:
Code:
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132806, block.nbits 469802878.000000, next work 459223285.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132806, block.nbits 469802878.000000, next work 459223285.000000 (code 16)
I dont see a miner by the name of Nipar, please share miner name.


nickname=nichaols1
miner names are  np-01F and np-L2-F

I also downloaded the windows version with the updated getabnweight version 2.7 and it still happens
thanks.

I made a change to the pool to attempt to reveal the problem, did it just resolve (try to 'setgenerate true N') on one of the nodes?

jr. member
Activity: 55
Merit: 2
is this related to the abn problems?
seems I cannot pool mine without this happening after only a few minutes:
Code:
ContextualCheckBlockHeader::FAILED incorrect proof of work at 132806, block.nbits 469802878.000000, next work 459223285.000000ERROR: TestBlockValidityLite: Consensus::ContextualCheckBlockHeader: bad-diffbits, incorrect proof of work at 132806, block.nbits 469802878.000000, next work 459223285.000000 (code 16)
I dont see a miner by the name of Nipar, please share miner name.


nickname=nichaols1
miner names are  np-01F and np-L2-F

I also downloaded the windows version with the updated getabnweight version 2.7 and it still happens
thanks.
Jump to: