BiblePay - New Coin Launch - Official Thread

[happy_merchant]

Edit the biblepay.conf file, and place the following lines in the config:

poolport=80
pool=http://pool.biblepay.org
workerid=the_worker_id
gen=1
genproclimit=5

Is correct??

That will only work on the testnet. If you try it on the main blockchain it'll reject your connection and additionally you'll be mining much slower than normal because it'll be trying to reconnect to the pool every iteration.

[inblue]

I think I may be on to something. In 3 full days I've found only 3 blocks (instead of at least like 50 blocks or so), so I decided to dig into debug.log and I've found something which may be a problem.

First of all, this is how a normal block find looks like in my log, I'm sure you know it, but here it is just for reference.

2017-08-11 20:31:11 CBlock(hash=00000107572a9b18c8584459675dd7fade8c046701c162ff46b1ee14805e8520, ver=536870913, hashPrevBlock=00000284a57ec79cc997532d124e2d41d2347d25215bfd0d1b17f98bf5a5fe4e, hashMerkleRoot=e824ec77c3abc71a9ac06d256d003890f9f29024fa1f2c6d1e412f089a2036e7, nTime=1502483469, nBits=1e01929c, nNonce=19363, vtx=2)
  CTransaction(hash=f284dfea18, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 02970a029501)
    CTxOut(nValue=19958.00004260, scriptPubKey=2103af29ac2bc19110ac2e973f7eaf)

  CTransaction(hash=4c1e66855c, ver=1, vin.size=1, vout.size=1, nLockTime=2710)
    CTxIn(COutPoint(c72f9d67ddd408b7be94527944e7cb8af2b15c4637d833b4667aa8019a4c9959, 0), scriptSig=47304402204fcdc987b422f6, nSequence=4294967294)
    CTxOut(nValue=19955.99995740, scriptPubKey=76a9145da07b168e99d2d9e73c7669)


2017-08-11 20:31:11 generated 19958.0000426
2017-08-11 20:31:11 UpdateTip: new best=00000107572a9b18c8584459675dd7fade8c046701c162ff46b1ee14805e8520  height=2711  log2_work=32.293101  tx=3221  date=2017-08-11 20:31:09 progress=0.999999  cache=0.0MiB(92tx)
2017-08-11 20:31:11 AddToWallet f284dfea18f24d86f54e8f5c9ba843225d7439fd0d3ff2677ac738282d4111c1  new
2017-08-11 20:31:11 ProcessNewBlock : ACCEPTED
2017-08-11 20:31:11 keypool keep 3
2017-08-11 20:31:17 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done

OK, then here I have a stale block, only one, so it's fine, bad luck I guess. No problem here either, just for reference.

2017-08-09 18:10:06 UpdateTip: new best=000000abf6434add4da1c4d39e349cb066601106ee48814173a7eec8f700b14d  height=2416  log2_work=31.743101  tx=2809  date=2017-08-09 18:10:03 progress=0.999999  cache=0.5MiB(2025tx)
2017-08-09 18:10:06 ProcessNewBlock : ACCEPTED
2017-08-09 18:10:12 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-09 18:12:12 UpdateTip: new best=0000000f163c2bfcf381b04b16017321fa1ae3e27db059bf93592e6571d89856  height=2417  log2_work=31.744362  tx=2810  date=2017-08-09 18:12:14 progress=1.000001  cache=0.5MiB(2026tx)
2017-08-09 18:12:12  

** TestBlockValidity FAILED - pindexNew->pprev != chainActive.Tip() (assert(pindexNew->pprev == chainActive.Tip())); **

2017-08-09 18:12:12

BiblepayMiner -- runtime error: CreateNewBlock: TestBlockValidity failed:  (code 0)
2017-08-09 18:12:12 ProcessNewBlock : ACCEPTED
2017-08-09 18:12:12 CBlock(hash=0000052cdf42990efb3111168df6383ac9e67469e13779e9191045e2519c625d, ver=536870913, hashPrevBlock=000000abf6434add4da1c4d39e349cb066601106ee48814173a7eec8f700b14d, hashMerkleRoot=6957720542ed422b568ef6729ce2003bc0374230a89a08fd7e9eb52f6cc9656b, nTime=1502302331, nBits=1e0556e7, nNonce=17044, vtx=1)
  CTransaction(hash=6957720542, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 027109027902)
    CTxOut(nValue=19909.00000000, scriptPubKey=21025ce570545d93eaf020b0b9ed51)


2017-08-09 18:12:12 generated 19909.00
2017-08-09 18:12:12 ERROR: ProcessBlockFound -- generated block is stale
2017-08-09 18:12:12 keypool keep 7
2017-08-09 18:12:18 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-09 18:12:20 UpdateTip: new best=000000aad1cdcb0345f5f8bf2860df001b8e1ce7694758b156b1423122674022  height=2418  log2_work=31.74527  tx=2811  date=2017-08-09 18:12:22 progress=1.000001  cache=0.5MiB(2027tx)
2017-08-09 18:12:20 ProcessNewBlock : ACCEPTED
2017-08-09 18:12:26 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done

OK, now here is where it gets interesting. I found like a dozen of these errors on each of my machines, which can roughly correlate to the number of blocks I should have found.

2017-08-12 07:21:39 UpdateTip: new best=000000a9939e109169f91c3c72737e26f11b093dc2062175a4814ee57db83d99  height=2769  log2_work=32.402216  tx=3294  date=2017-08-12 07:21:34 progress=0.999998  cache=0.0MiB(218tx)
2017-08-12 07:21:39 ProcessNewBlock : ACCEPTED
2017-08-12 07:21:45 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-12 07:24:27 UpdateTip: new best=0000001ae8594b890ff5b97168ba3f57ec1cf64e2c3351275e592ed6a7a52396  height=2770  log2_work=32.403584  tx=3295  date=2017-08-12 07:24:22 progress=0.999998  cache=0.0MiB(219tx)
2017-08-12 07:24:27  

 ** TestBlockValidity FAILED - pindexNew->pprev != chainActive.Tip() (assert(pindexNew->pprev == chainActive.Tip())); **

2017-08-12 07:24:27

BiblepayMiner -- runtime error: CreateNewBlock: TestBlockValidity failed:  (code 0)
2017-08-12 07:24:27 ProcessNewBlock : ACCEPTED
2017-08-12 07:24:33 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-12 07:25:32 UpdateTip: new best=0000034d6225764bc4e45c7d05c6171a2563ed0b221a8e5998c81572cc79800f  height=2771  log2_work=32.404542  tx=3296  date=2017-08-12 07:25:28 progress=0.999999  cache=0.0MiB(220tx)
2017-08-12 07:25:32 ProcessNewBlock : ACCEPTED
2017-08-12 07:25:38 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done

Note that in the stale block log I pasted above this one, you can also see the two TestBlockValidity failed lines, but there is also data about the found block and an attempt to generate 19909 BBP to credit the wallet and then the message that the block is stale. But in all of these instances, there is none of that, just invalid block errors. What could that be? I am of course not knowledgeable about this, but to me it looks like I was finding blocks but they were invalid for some reason.

[happy_merchant]

Note that in the stale block log I pasted above this one, you can also see the two TestBlockValidity failed lines, but there is also data about the found block and an attempt to generate 19909 BBP to credit the wallet and then the message that the block is stale. But in all of these instances, there is none of that, just invalid block errors. What could that be? I am of course not knowledgeable about this, but to me it looks like I was finding blocks but they were invalid for some reason.

I'm not really an expert on the blockchain details either, but for the attempting to generate 19909 BBP on the stale block part, that'd probably be because the node you're running on your machine accepted the block that it mined itself until the blockchain rejected it. Something like:

-you mined a block
-your node said it was valid and adds it to your local copy of the blockchain
-your wallet reads the block and adds 19909 BBP to your immature balance
-a fraction of a second later you receive a a block of the same height from the p2p network
-your node checks it and because its solution is a higher difficulty than the block you mined your node orphans the block you found and replaces it with the block you received
-reading the new blockchain your wallet removes the 19909 immature BBP from your wallet.

The order of the errors within the same timeframe in the debug log probably don't mean much since it's heavily multithreaded. That should be a rare event, but because of the occasionally difficulty drops we're seeing with Biblepay it's probably more common than it should be. But, it's something that would affect everyone equally, so it shouldn't influence the payout statistics over time.

The 3rd error log I don't really know, maybe the dev has an idea. I noticed it's block 2770, which is a multiple of 10 so it'd be a tithe block so it might be related to that. Or maybe it was a block that you received from the network that your node rejected. 0000001ae8594b890ff5b97168ba3f57ec1cf64e2c3351275e592ed6a7a52396 is the hash for block 2770 though, so the network didn't seem to reject it.

I'd try to audit the code myself, but C++ goes over my head for the most part. I should really get around to learning the basics one of these days...

[xxkaiwaxx]

Can someone help me find a way to mine this coin or any coin for that matter. Links that would help me start mining using my laptop. I would appreciate the help if ever. Everytime I read people discuss about hashrates and sources and pools, I feel like I am in a different planet. Thanks.

If u gonna mine with ur laptop (CPU Mining)...then, id say that the instructions found in this thread are as Easy as it will get ^^"

So , u should really try and take the time to try and follow the instructions, to get it running.

Coz if u cant follow these instructions, then ur only asking for trouble... going any further into "it".

So just Relax, no rush...and try to do what they say. And youll learn a WHOLE lot by doing it that way ^^.

And if u tried ur best (meaning, spending an hour minimum, on Each obstacle u come across)...and u just cant "get it"... Then, try asking in here again... stating what ur problem is "specifically"/ where ur stuck... and ppl may recognize the fact that u really tried (due to the amount of detail u add into ur question/problem) ...and will probably be able to help u better  

[inblue]

I'm not really an expert on the blockchain details either, but for the attempting to generate 19909 BBP on the stale block part, that'd probably be because the node you're running on your machine accepted the block that it mined itself until the blockchain rejected it. Something like:

-you mined a block
-your node said it was valid and adds it to your local copy of the blockchain
-your wallet reads the block and adds 19909 BBP to your immature balance
-a fraction of a second later you receive a a block of the same height from the p2p network
-your node checks it and because its solution is a higher difficulty than the block you mined your node orphans the block you found and replaces it with the block you received
-reading the new blockchain your wallet removes the 19909 immature BBP from your wallet.

The order of the errors within the same timeframe in the debug log probably don't mean much since it's heavily multithreaded. That should be a rare event, but because of the occasionally difficulty drops we're seeing with Biblepay it's probably more common than it should be. But, it's something that would affect everyone equally, so it shouldn't influence the payout statistics over time.

Thank you for your effort to break it down, everything is clear as day. I don't think this is an issue as long as it happens rarely. One more user here mentioned he had the same situation, the wallet briefly showed him the new credit and then disappeared, but I still think that's sufficiently rare, as I found only one stale block in 7 debug logs across 7 machines mining for 3 days.

The 3rd error log I don't really know, maybe the dev has an idea. I noticed it's block 2770, which is a multiple of 10 so it'd be a tithe block so it might be related to that. Or maybe it was a block that you received from the network that your node rejected. 0000001ae8594b890ff5b97168ba3f57ec1cf64e2c3351275e592ed6a7a52396 is the hash for block 2770 though, so the network didn't seem to reject it.

Smart guess about the tithe block, but that occurrence was accidentally a multiple of 10. Here, I'll paste another one, the newest.

2017-08-12 08:39:48 UpdateTip: new best=00000024a3327afa5e3ff620607e48841ec35c6a92a554a132e0dbb616b5526d  height=2782  log2_work=32.427115  tx=3308  date=2017-08-12 08:39:47 progress=1.000000  cache=0.0MiB(117tx)
2017-08-12 08:39:48  

 ** TestBlockValidity FAILED - pindexNew->pprev != chainActive.Tip() (assert(pindexNew->pprev == chainActive.Tip())); **

2017-08-12 08:39:48

BiblepayMiner -- runtime error: CreateNewBlock: TestBlockValidity failed:  (code 0)
2017-08-12 08:39:48 ProcessNewBlock : ACCEPTED
2017-08-12 08:39:55 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done

And about my machine rejecting the block from the network - I'm not so sure, because it keeps up with that block height properly, and with the next one etc, and continues to synchronize correctly. I hope the dev can give some insight into this.

I'd try to audit the code myself, but C++ goes over my head for the most part. I should really get around to learning the basics one of these days...

Good idea, same here, but I'll try to skim through the code anyway.

Edit:
One very important thing to note is that the invalid block error on some block (for example block 2782 in the above paste) only appears on that machine. On all 6 others it's normal, like this:

2017-08-12 08:39:49 UpdateTip: new best=00000024a3327afa5e3ff620607e48841ec35c6a92a554a132e0dbb616b5526d  height=2782  log2_work=32.427115  tx=3308  date=2017-08-12 08:39:47 progress=0.999999  cache=0.0MiB(233tx)
2017-08-12 08:39:49 ProcessNewBlock : ACCEPTED
2017-08-12 08:39:55 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-12 08:59:27 UpdateTip: new best=000000018734cbb6422e82aeaa2f52162760f95ea4d485a2a5c8de3a46bc47b9  height=2783  log2_work=32.43188  tx=3309  date=2017-08-12 08:59:25 progress=0.999999  cache=0.0MiB(234tx)
2017-08-12 08:59:27 ProcessNewBlock : ACCEPTED
2017-08-12 08:59:33 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done

Then some other block will be invalid again only on one machine (6 of them are identical btw), so that leads me to believe those are found blocks which are invalid for some reason.

[happy_merchant]

One very important thing to note is that the invalid block error on some block (for example block 2782 in the above paste) only appears on that machine. On all 6 others it's normal, like this:

2017-08-12 08:39:49 UpdateTip: new best=00000024a3327afa5e3ff620607e48841ec35c6a92a554a132e0dbb616b5526d  height=2782  log2_work=32.427115  tx=3308  date=2017-08-12 08:39:47 progress=0.999999  cache=0.0MiB(233tx)
2017-08-12 08:39:49 ProcessNewBlock : ACCEPTED
2017-08-12 08:39:55 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-12 08:59:27 UpdateTip: new best=000000018734cbb6422e82aeaa2f52162760f95ea4d485a2a5c8de3a46bc47b9  height=2783  log2_work=32.43188  tx=3309  date=2017-08-12 08:59:25 progress=0.999999  cache=0.0MiB(234tx)
2017-08-12 08:59:27 ProcessNewBlock : ACCEPTED
2017-08-12 08:59:33 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done

Then some other block will be invalid again only on one machine (6 of them are identical btw), so that leads me to believe those are found blocks which are invalid for some reason.

Unfortunately, I don't think that necessarily means much. A block your node discovers is only broadcast to peers that you're directly connected to. I think that defaults to 8 connections? So, say a node sends out a bad block to the 8 peers it's connected to (that node might be mining on a fork or something). Unless those 8 peers are mining on the same fork, they would reject the block and it wouldn't be propagated across the network. So, unless multiple of your machines shared that same peer, the rejected block would be unlikely to show up more than once.

I'm completely assuming here that rejected blocks sent from the network show up in the debug log, by the way. I have no idea if they do or not, but I'd think they would.

That doesn't actually seem to be a rejected block, though. The hash matches up with the blockchain. I'll try looking through the source and see if I can figure anything out about that error since I get it a lot too, but I can't really promise much.

[inblue]

Unfortunately, I don't think that necessarily means much. A block your node discovers is only broadcast to peers that you're directly connected to. I think that defaults to 8 connections? So, say a node sends out a bad block to the 8 peers it's connected to (that node might be mining on a fork or something). Unless those 8 peers are mining on the same fork, they would reject the block and it wouldn't be propagated across the network. So, unless multiple of your machines shared that same peer, the rejected block would be unlikely to show up more than once.

Good thinking. Yes, I have exactly 8 connections on all instances. I just checked your theory and between the computers only 1 peer is consistent and always at the top of the list and that's 97.99.69.33:40000 (node.biblepay.org). Aside from that one, two computers generally share between themselves 1 or 2 more peers. Other 5-6 peers are different.

I'll try looking through the source and see if I can figure anything out about that error since I get it a lot too, but I can't really promise much.

Maybe here would be a good place to start.

since I get it a lot too

That reminded me - I wanted to ask you if on your hash rate you get about the same number of those errors or proportionally to the hash rate? Per one 140k computer, I got between 10 and 16 of those for 24 hours of 2017-08-11. Actually now that I think of it, it would be way too much to find that amount of blocks for that hash rate. So it's probably something else.

[happy_merchant]

2017-08-12 08:39:48 UpdateTip: new best=00000024a3327afa5e3ff620607e48841ec35c6a92a554a132e0dbb616b5526d  height=2782  log2_work=32.427115  tx=3308  date=2017-08-12 08:39:47 progress=1.000000  cache=0.0MiB(117tx)
2017-08-12 08:39:48  

 ** TestBlockValidity FAILED - pindexNew->pprev != chainActive.Tip() (assert(pindexNew->pprev == chainActive.Tip())); **

2017-08-12 08:39:48

BiblepayMiner -- runtime error: CreateNewBlock: TestBlockValidity failed:  (code 0)
2017-08-12 08:39:48 ProcessNewBlock : ACCEPTED
2017-08-12 08:39:55 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done

So, (assuming I'm reading this right) the error isn't related to block 2782, but rather the following block. Block 2782 was received by the network and accepted by your node. Your node then calls CreateNewBlock where it assembles the transactions and headers to create block 2783 before sending the block on to be hashed (which is the actual mining process).

At the top of the CreateNewBlock method, pindexPrev is defined as a pointer to the block currently at the top of the chain (2782 in this case):

Code:

CBlockIndex* pindexPrev = chainActive.Tip();

That's referenced throughout the block creation to get information necessary for creating the new block. Once the block is finished being created, TestBlockValidity is called with pindexPrev as one of the arguments:

Code:

if (!TestBlockValidity(state, chainparams, *pblock, pindexPrev, false, false)) {
        throw std::runtime_error(strprintf("%s: TestBlockValidity failed: %s", __func__, FormatStateMessage(state)));
}

and in that method it's failing this test:

Code:

if (!(pindexPrev && pindexPrev == chainActive.Tip()))
{
	LogPrintf(" \r\n ** TestBlockValidity FAILED - pindexNew->pprev != chainActive.Tip() (assert(pindexNew->pprev == chainActive.Tip())); ** \r\n");
	return false;
}

then returns and throws the runtime error seen in the error log.

pindexPrev is never reassigned, so in order to fail the test pindexPrev == chainActive.Tip() that means that the value returned by chainActive.Tip() changed. I don't see anything in CreateNewBlock() that looks like it's changing the blockchain, so it's probably caused by another thread. That's all I can gather from reading the code, finding out more would require actual debugging.

I'm not sure where the thrown exception gets handled, so I don't know how the node responds to this. The entire thing doesn't crash so something takes care of it, but I don't know if it attempts to build a new block or what. Mining doesn't seem to just stop since blocks continue to be mined after the error. I'm also not sure how much of this is Biblepay-specific code and how much is carried over from Dash.

Oh, and looking through some of my really old logs, this is what an error looks like when a peer sends you an invalid block:

Code:

2017-08-07 09:09:28 ERROR: CheckProofOfWork(): BibleHash does not meet POW level
2017-08-07 09:09:28 ERROR: CheckBlockHeader(): proof of work failed
2017-08-07 09:09:28 Misbehaving: 97.99.69.33:40000 (0 -> 50)
2017-08-07 09:09:28 ERROR: invalid header received 0000024a49a386eee621d31124cf1dea0131b0b0233ec168f8dbcc8ea22cca0e
2017-08-07 09:09:28 ProcessMessages(headers, 82 bytes) FAILED peer=1

Also, I looked through the chain parameters and they appear to be configured correctly for a 7 minute block time, so whatever is affecting that is more complex than just a configuration error.

[bible_pay]

 ** TestBlockValidity FAILED - pindexNew->pprev != chainActive.Tip() (assert(pindexNew->pprev == chainActive.Tip())); **

Regarding mining in general and seeing this error in the log:
First, it is normal for the miner to be stuck in a busy-wait loop busy hashing the current block, while the chainActive.Tip() moves on to a new block, and occasionally, for some reason in AcceptBlock it is possible right at a microsecond instant that the main wallet thread is assigning the pindexNew->pprev to something new, pindexNew->pprev to the miner is NULL, and this results in the miner throwing an error and having to go start over and CreateNewBlock.

This part of it is absolutely normal and as long as it is happening about once every 4 hours or less, no harm is being done and the miner is not slowing down.

The wallet Is set up with the correct parameters, and handling this condition, but
The main stress I want to make on this is that we ensure these things:
1. If the wallet is set up with 10 mining threads to begin with, each thread is handling that particular error and still mining at the end of the day. (Check this).
2.  The wallet does not crash.
3.  The HashPs of the Box itself should bear out a similar value as when the day started.


If #3 especially is true, then everything is fine.  I would suggest grabbing a baseline hashps from the box 5 min after start, and then checking on it 24 hours later.  If the hashps is the same, then dont worry about the error as long as its very rare in the log.

One additional note, if you turn on too many debug switches, the box gets busy just writing the Logs!  So after we are stable we need to focus on not logging everything in non-debug mode as that can slow down the miner.

Thanks.

[inblue]

So, (assuming I'm reading this right) the error isn't related to block 2782, but rather the following block. Block 2782 was received by the network and accepted by your node. Your node then calls CreateNewBlock where it assembles the transactions and headers to create block 2783 before sending the block on to be hashed (which is the actual mining process).

I'm not sure if I understood that correctly, but here I pasted the same log for block 2782, only this time with the surrounding blocks so you can see more info. I highlighted the time stamps which I think are related to the block 2782 in yellow, and the ones which are related to the block 2783 in green.

2017-08-12 08:30:45 UpdateTip: new best=000001631b73838c0fbb1c77726900fca1326f7ed687722ba68664da2b20e66e  height=2781  log2_work=32.422993  tx=3307  date=2017-08-12 08:30:33 progress=0.999996  cache=0.0MiB(116tx)
2017-08-12 08:30:45 ProcessNewBlock : ACCEPTED
2017-08-12 08:30:51 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-12 08:39:48 UpdateTip: new best=00000024a3327afa5e3ff620607e48841ec35c6a92a554a132e0dbb616b5526d  height=2782  log2_work=32.427115  tx=3308  date=2017-08-12 08:39:47 progress=1.000000  cache=0.0MiB(117tx)
2017-08-12 08:39:48

** TestBlockValidity FAILED - pindexNew->pprev != chainActive.Tip() (assert(pindexNew->pprev == chainActive.Tip())); **

2017-08-12 08:39:48

BiblepayMiner -- runtime error: CreateNewBlock: TestBlockValidity failed:  (code 0)
2017-08-12 08:39:48 ProcessNewBlock : ACCEPTED
2017-08-12 08:39:55 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-12 08:59:25 UpdateTip: new best=000000018734cbb6422e82aeaa2f52162760f95ea4d485a2a5c8de3a46bc47b9  height=2783  log2_work=32.43188  tx=3309  date=2017-08-12 08:59:25 progress=1.000000  cache=0.0MiB(118tx)
2017-08-12 08:59:25 ProcessNewBlock : ACCEPTED
2017-08-12 08:59:31 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-12 09:57:59 UpdateTip: new best=00000156f9db92abe88a4de4462004df12893c6b4718e8daca291ef06e765eb1  height=2784  log2_work=32.434599  tx=3311  date=2017-08-12 09:57:59 progress=1.000000  cache=0.0MiB(7tx)
2017-08-12 09:57:59 ProcessNewBlock : ACCEPTED
2017-08-12 09:58:05 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done

So I don't understand what does block 2783 have to do with the error which appeared in the yellow timeline, because that block was found in the green timeline 20 minutes later. Unless you mean it was supposed to be found by the miner back then, but the error always appears in the same second as the UpdateTip for the previous block.

Oh, and looking through some of my really old logs, this is what an error looks like when a peer sends you an invalid block:

Code:

2017-08-07 09:09:28 ERROR: CheckProofOfWork(): BibleHash does not meet POW level
2017-08-07 09:09:28 ERROR: CheckBlockHeader(): proof of work failed
2017-08-07 09:09:28 Misbehaving: 97.99.69.33:40000 (0 -> 50)
2017-08-07 09:09:28 ERROR: invalid header received 0000024a49a386eee621d31124cf1dea0131b0b0233ec168f8dbcc8ea22cca0e
2017-08-07 09:09:28 ProcessMessages(headers, 82 bytes) FAILED peer=1

Wow, I guess 5 days is really old in the crypto world.

So this means the TestBlockValidity error is not caused by a peer sending an invalid block?

Also, I looked through the chain parameters and they appear to be configured correctly for a 7 minute block time, so whatever is affecting that is more complex than just a configuration error.

I also found the 205 blocks per day parameters in the code, so I am very worried about this, there's definitely something strange here and I hope it's not very complex to fix.


OK, bible_pay answered while I was making this post.

This part of it is absolutely normal and as long as it is happening about once every 4 hours or less, no harm is being done and the miner is not slowing down.

Somewhere I found two of these errors for the two blocks right next to each other and somewhere I found it to occur 3 times in about half an hour. But majority of the time it's at least a few hours apart.

The wallet Is set up with the correct parameters, and handling this condition, but
The main stress I want to make on this is that we ensure these things:
1. If the wallet is set up with 10 mining threads to begin with, each thread is handling that particular error and still mining at the end of the day. (Check this).
2.  The wallet does not crash.
3.  The HashPs of the Box itself should bear out a similar value as when the day started.

If #3 especially is true, then everything is fine.  I would suggest grabbing a baseline hashps from the box 5 min after start, and then checking on it 24 hours later.  If the hashps is the same, then dont worry about the error as long as its very rare in the log.

For me all three are check. I find that hash rate is the same after many hours, maybe even 1% higher than in the first few minutes.

[bible_pay]

I also found the 205 blocks per day parameters in the code, so I am very worried about this, there's definitely something strange here and I hope it's not very complex to fix.

Real quick on the 205 blocks per day, nothing to be worried about that is correct:
60/7*24
 205.7

HH/7Min Blocks * 24 Hrs per day = 205.7.  The integer is fine, its just an input for diff retargets, and lookback functions such as the gather prayers per week, etc.  Nothing looks awry.

I am still checking the rest of your post

[inblue]

Correct, but in reality there are about 144 blocks every day which is 10 minutes mean block time.

Edit: Here's happy_merchant's post if you missed it:

@bible_pay: Could you maybe explain the fact that only ~70% of blocks are found each day?

26928 minutes / 2675 blocks = 10.0665 minutes/block

[bible_pay]

I'm not sure if I understood that correctly, but here I pasted the same log for block 2782, only this time with the surrounding blocks so you can see more info. I highlighted the time stamps which I think are related to the block 2782 in yellow, and the ones which are related to the block 2783 in green.

2017-08-12 08:30:45 UpdateTip: new best=000001631b73838c0fbb1c77726900fca1326f7ed687722ba68664da2b20e66e  height=2781  log2_work=32.422993  tx=3307  date=2017-08-12 08:30:33 progress=0.999996  cache=0.0MiB(116tx)
2017-08-12 08:30:45 ProcessNewBlock : ACCEPTED
2017-08-12 08:30:51 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-12 08:39:48 UpdateTip: new best=00000024a3327afa5e3ff620607e48841ec35c6a92a554a132e0dbb616b5526d  height=2782  log2_work=32.427115  tx=3308  date=2017-08-12 08:39:47 progress=1.000000  cache=0.0MiB(117tx)
2017-08-12 08:39:48

** TestBlockValidity FAILED - pindexNew->pprev != chainActive.Tip() (assert(pindexNew->pprev == chainActive.Tip())); **

2017-08-12 08:39:48

BiblepayMiner -- runtime error: CreateNewBlock: TestBlockValidity failed:  (code 0)
2017-08-12 08:39:48 ProcessNewBlock : ACCEPTED
2017-08-12 08:39:55 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-12 08:59:25 UpdateTip: new best=000000018734cbb6422e82aeaa2f52162760f95ea4d485a2a5c8de3a46bc47b9  height=2783  log2_work=32.43188  tx=3309  date=2017-08-12 08:59:25 progress=1.000000  cache=0.0MiB(118tx)
2017-08-12 08:59:25 ProcessNewBlock : ACCEPTED
2017-08-12 08:59:31 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-12 09:57:59 UpdateTip: new best=00000156f9db92abe88a4de4462004df12893c6b4718e8daca291ef06e765eb1  height=2784  log2_work=32.434599  tx=3311  date=2017-08-12 09:57:59 progress=1.000000  cache=0.0MiB(7tx)
2017-08-12 09:57:59 ProcessNewBlock : ACCEPTED
2017-08-12 09:58:05 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done

So I don't understand what does block 2783 have to do with the error which appeared in the yellow timeline, because that block was found in the green timeline 20 minutes later. Unless you mean it was supposed to be found by the miner back then, but the error always appears in the same second as the UpdateTip for the previous block.

Hi Inblue,

Looking at 2782 and 2783 and the timeline, it is OK if 2783 was actually solved 20 minutes later, what appears to be happening is this (I can say this based on the TestBlockValidity context):

2782 is accepted at 2017-08-12 08:30:45
2783 is accepted at 2017-08-12 08:59:25

In between these timestamps, at 08:39 AM, One of your mining threads throws a ** TestBlockValidity FAILED.

So you are alluding to the possibility that the miner could not create a new block, but yet the tip had no reason to be updated as a block didnt arrive until 20 minutes later.  Its possible createnewblock is affected by many competing threads,
 possibly a mutex issue causing a missing pindexprev pointer.  We can add more logging in createnewblock and try to find out why occasionally, the miner can not create a new block, and that results in testblockvalidy failing.  It looks like it is unrelated to network activity, orphans, reorganizations, and only the actual activeChain.tip, because the tip was not changing on the node.  So it really appears the createnewblock is sometimes in a blue moon returning a new block with a missing pindexprev pointer, or something to that effect.  It might be revealing for us to put in a little busy wait loop right when that occurs for 7 seconds and log info about the chainactive.tip before throwing the error, just to see if the node recovers its tip by itself.
I will add that to my todo list.

[bible_pay]

Correct, but in reality there are about 144 blocks every day which is 10 minutes mean block time.

Edit: Here's happy_merchant's post if you missed it:

@bible_pay: Could you maybe explain the fact that only ~70% of blocks are found each day?

26928 minutes / 2675 blocks = 10.0665 minutes/block

18 days is not a long enough sample time to make the assumption that the parameters are failing.
I believe there was a discussion early on in litecoins thread that it took about a year for the diff retarget to average out.

However, I do want to ensure we start retargeting our diff every single block (instead of 4 as it is currently), and decrease our stuck blocks down to 30 mins during the next mandatory.  We have quite a few slow blocks, and that will drag this short sample period up significantly.

[happy_merchant]

So I don't understand what does block 2783 have to do with the error which appeared in the yellow timeline, because that block was found in the green timeline 20 minutes later. Unless you mean it was supposed to be found by the miner back then, but the error always appears in the same second as the UpdateTip for the previous block.

Mining the next block starts as soon as the current block is found. Block 2782 was found at 08:39:48. It immediately creates the next block, then starts hashing it. A hash that satisfies PoBh was then found at 08:59:25.

You might be confused about the difference between creating the block and mining it. Really basically, a block is a collection of transactions and header information. For a block to be mined, it has to produce a hash that meets the difficulty requirements when ran through the mining algorithm. So, the block needs to exist before you can start hashing it. Obviously, the same data will always produce the same hash, so there' a value in the header called the nonce that starts at 0 and is incremented after each hash attempt until a solution is found.

[happy_merchant]

18 days is not a long enough sample time to make the assumption that the parameters are failing.
I believe there was a discussion early on in litecoins thread that it took about a year for the diff retarget to average out.

However, I do want to ensure we start retargeting our diff every single block (instead of 4 as it is currently), and decrease our stuck blocks down to 30 mins during the next mandatory.  We have quite a few slow blocks, and that will drag this short sample period up significantly.

Yeah, I was thinking about that a little afterwards, and for most of that time the number of miners were so few that one or two people dropping in or out of the pool would be a significant portion of the network hash which would mess up the difficulty. So, trying to draw a conclusion from that might not actually be as accurate as you'd think just given the sample size. I might try running some daily averages and see how things progress. The network hash is increasing pretty rapidly, we've gone up like 20% in a day.

[samspaces]

Did anyone find a block with the updated miner? Mining with 1/100 of nethash and haven't seen a block in 600 blocks.

[inblue]

Mining the next block starts as soon as the current block is found. Block 2782 was found at 08:39:48. It immediately creates the next block, then starts hashing it. A hash that satisfies PoBh was then found at 08:59:25.

You might be confused about the difference between creating the block and mining it. Really basically, a block is a collection of transactions and header information. For a block to be mined, it has to produce a hash that meets the difficulty requirements when ran through the mining algorithm. So, the block needs to exist before you can start hashing it. Obviously, the same data will always produce the same hash, so there' a value in the header called the nonce that starts at 0 and is incremented after each hash attempt until a solution is found.

Thanks for the explanation, I didn't know blocks were created before being mined.

18 days is not a long enough sample time to make the assumption that the parameters are failing.
I believe there was a discussion early on in litecoins thread that it took about a year for the diff retarget to average out.

However, I do want to ensure we start retargeting our diff every single block (instead of 4 as it is currently), and decrease our stuck blocks down to 30 mins during the next mandatory.  We have quite a few slow blocks, and that will drag this short sample period up significantly.

Yeah, I was thinking about that a little afterwards, and for most of that time the number of miners were so few that one or two people dropping in or out of the pool would be a significant portion of the network hash which would mess up the difficulty. So, trying to draw a conclusion from that might not actually be as accurate as you'd think just given the sample size. I might try running some daily averages and see how things progress. The network hash is increasing pretty rapidly, we've gone up like 20% in a day.

Hmm, but why would people dropping in or out be so important if the difficulty changes every 4 blocks? It's not every block (yet), but still, if the diff readjusts ~35 times a day, isn't it enough to not allow for any wild fluctuations?

Especially considering that the trend still continues - yesterday there was only 135 blocks, but nethash is much bigger and more stable now. And it's never more than 205 blocks per day, not even more than 155 per day. It's always less. One would think it would fluctuate to both directions if the early instability was an issue.

[TheKingInYellow]

Did anyone find a block with the updated miner? Mining with 1/100 of nethash and haven't seen a block in 600 blocks.

Nothing yet. I used to get blocks every couple days.

At this point it's almost cheaper just to buy the BBP people are deciding to dump for basically nothing.

[Ginzink]

Did anyone find a block with the updated miner? Mining with 1/100 of nethash and haven't seen a block in 600 blocks.

Yeah, but not as many as id think comparing to nethash. I am wondering if nethash is displayed wrong? As we can be 500+ miners that dont add up to nethash unless it is alot of rasperry pi or people with old miner / 1 thread

And yeah, the price ppl are selling for is just funny. Hope we get to a bigger exchange soon and when updates are ready for the coin i guess the current buyers are the winners