BiblePay - TestNet Thread - Pool Testing for Proof of Bible Hash Pool (PoBh)

[bible_pay]

Some feedback:

1. When you click on switch to testnet it toggles to switch to mainnet. When you click on another like like home, the link switch to mainnet defaults back to switch to testnet which is not correct.
2. There is no page to see stats on the blocks found, who found them, when found, the block's status etc.
3. No anonymous mining option.
4. Pool hash indicator is very close to client side hash

Hi JC,

Thanks for the detailed info.
I agree, #1 is a nuisance, however, the reason it made it so far is the affinity to main_chain, so Im not sure if that will stay that way or not.  The thing is in my experience, once we finish testing we will really for all intents and purposes always be in the main chain.   (To fix this I need to move the setting for your selected chain to Account to a drop down, and then put the indicator (of the active chain) somewhere else- Ill see what I can do).

On #2, check out block distribution history report.  It should have very good details.

On #3, nice idea.... Hmmm, thinking about it.

#4, cool.

And I have a new bug to add:

I think others might have experienced this also.  I have a few nodes solo mining and they are unaffected by this bug.
At 02:45 am this morning we have 5 miners on testnet pool mining.  Myself and I believe 2 others fell off at the time the tithe block hit. I believe our testnet miners crashed.
I believe the issue is, whatever is sent back to the client (either HTTP error, or possibly since the tithe block was mined, an ERROR type response) was handled in a way that caused an unhandled exception to close the whole client.  I will look into this today, and believe this Only affects pool miners.

[1714899828]

1714899828

[1714899828]

1714899828

[1714899828]

1714899828

[1714899828]

1714899828

[1714899828]

1714899828

[happy_merchant]

Hmm, I think I might've killed the pool website. I tried spamming withdrawals to see if it handled it okay. Seemed to be fine while I was spamming it manually, then I set up an autoclicker to hit send about a hundred times a second and now the web server seems to be busy or dead.

--edit--
Site seems to be loading again, but was unresponsive for about 10 minutes.

[tiras]

Hmm, I think I might've killed the pool website. I tried spamming withdrawals to see if it handled it okay. Seemed to be fine while I was spamming it manually, then I set up an autoclicker to hit send about a hundred times a second and now the web server seems to be busy or dead.

looks like ....

Server Error in '/' Application.
Invalid column name 'threads'.
Invalid column name 'BoxHPS'.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Data.SqlClient.SqlException: Invalid column name 'threads'.
Invalid column name 'BoxHPS'.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

[happy_merchant]

Not really related to the test pool, but this is an issue I see a lot even on the main blockchain:

Code:

Block  Timestamp
548    8/9/2017 9:45:08 AM
549    8/9/2017 10:44:51 AM
550    8/9/2017 10:44:51 AM
551    8/9/2017 10:44:51 AM

It'll go about an hour with no blocks, then that fail-safe difficulty reduction kicks in and you often see it followed by 2-3 blocks that are mined instantly. Do you think this is something that will work itself out when the network hashrate starts going up? I don't really know enough about blockchains to speculate on any security issues that might arise from the low difficulty blocks, but at the very least the inconsistency in block time might have an affect on widespread adoption of Biblepay since it directly affects the speed of transactions.

[tiras]

can't login to http://pool.biblepay.org/Login.aspx

the form does nothing.

is it disabled atm ?

[bible_pay]

can't login to http://pool.biblepay.org/Login.aspx

the form does nothing.

is it disabled atm ?

I believe when happy spammed it, it went down until Microsoft restarted the app pool automatically.

Ill work on spam prevention also.

Its up.

[tiras]

can't login to http://pool.biblepay.org/Login.aspx

the form does nothing.

is it disabled atm ?

I believe when happy spammed it, it went down until Microsoft restarted the app pool automatically.

Ill work on spam prevention also.

Its up.

test coins have no value .  right ?

[bible_pay]

Go ahead and try to spam the pool now.

Got to jump out for a little while; spam prevention should be enabled on miner actions, ips, and withdraws.

[bible_pay]

Not really related to the test pool, but this is an issue I see a lot even on the main blockchain:

Code:

Block  Timestamp
548    8/9/2017 9:45:08 AM
549    8/9/2017 10:44:51 AM
550    8/9/2017 10:44:51 AM
551    8/9/2017 10:44:51 AM

It'll go about an hour with no blocks, then that fail-safe difficulty reduction kicks in and you often see it followed by 2-3 blocks that are mined instantly. Do you think this is something that will work itself out when the network hashrate starts going up? I don't really know enough about blockchains to speculate on any security issues that might arise from the low difficulty blocks, but at the very least the inconsistency in block time might have an affect on widespread adoption of Biblepay since it directly affects the speed of transactions.

I have observed this also on all the chains.  I believe the issue is (the chain) eventually selects a difficulty for the next block that is slightly too hard for the miners, probably due to either them getting lucky on the last block, or, maybe some extra miners piling in the wallet.

Anyway, I doubt more hash rate will solve the problem, it might make it less frequent.
I think what we need to do is when we have another mandatory, add in two features in it:
- Retarget difficulty once per block instead of once per 4 blocks
- Lower the threshold for the stuck blocks from one hour to say 35 minutes.  It has to be well over 15 minutes, because the timedrift function for getting the network adjusted time is 15 minutes, and that enforced block drift for disallowing future mining (IE clocks could be off, per se, up to say 7 minutes or so) is used, but we could probably go with 35 minutes for stuck blocks, and that would keep our chain running smoother, and not have people hanging around waiting for confirms.

[bible_pay]

can't login to http://pool.biblepay.org/Login.aspx

the form does nothing.

is it disabled atm ?

I believe when happy spammed it, it went down until Microsoft restarted the app pool automatically.

Ill work on spam prevention also.

Its up.

test coins have no value .  right ?

None at all.

[happy_merchant]

I noticed that my miner wasn't showing up in the block distribution history at times. Here's an example where it's registering fine up to block 575, disappears during blocks 576 and 577, then returns at block 578.

Code:

3d99591e-5790-4b7a-b219-ab22d2eef382	jc12345		578	19994.0000	1668.9717	8/9/2017 2:42:30 PM	23283.17	0.0716814584926104	8/9/2017 2:42:30 PM	jc12345.1: 32152 (23283)
bcbefc8a-c366-48ce-b7d5-47a3380536ed	seriestoo	578	19994.0000	9074.4408	8/9/2017 2:42:30 PM	126593.98	0.0716814584926104	8/9/2017 2:42:30 PM	intel7700k: 150311 (126594)
seriestoo: 61240 (126594)
2cba286c-0e95-443b-b1af-878621dcda79	testbible	578	19994.0000	891.2757	8/9/2017 2:42:30 PM	12433.84	0.0716814584926104	8/9/2017 2:42:30 PM	testbible: 17715 (12434)
eba0fbab-978f-4a75-8c25-8b2033d8538f	jumpinbunny	578	19994.0000	5615.1193	8/9/2017 2:42:30 PM	78334.33	0.0716814584926104	8/9/2017 2:42:30 PM	Jesus777: 113712 (78334)
0879d8c7-7e38-47d0-8cc2-7d974354def8	tiras		578	19994.0000	2042.6564	8/9/2017 2:42:30 PM	28496.3	0.0716814584926104	8/9/2017 2:42:30 PM	tirasworks: 45371 (28496)
0f649be8-eddc-402c-ae62-1f2152327349	happy_merchant	578	19994.0000	701.5361	8/9/2017 2:42:30 PM	9786.86	0.0716814584926104	8/9/2017 2:42:30 PM	happy_merchant00: 13033 (9787)

6f4dc4a8-549d-4e13-b688-07a9b00ac03c	jc12345		577	19995.0000	1453.3782	8/9/2017 2:39:26 PM	23963.58	0.0606494680929861	8/9/2017 2:39:26 PM	jc12345.1: 32154 (23964)
ff81fe6d-0d05-4986-9eff-a594c3cefd39	bible_pay	577	19995.0000	3954.7030	8/9/2017 2:39:26 PM	65205.9	0.0606494680929861	8/9/2017 2:39:26 PM	r15: 87462 (65206)
f3798682-34b9-493b-9750-d2ef2041e71c	seriestoo	577	19995.0000	8053.6146	8/9/2017 2:39:26 PM	132789.53	0.0606494680929861	8/9/2017 2:39:26 PM	intel7700k: 145944 (132790)
seriestoo: 61148 (132790)
89cfbc27-b5a8-47c6-ba6c-8498af2f9a90	jumpinbunny	577	19995.0000	4805.0187	8/9/2017 2:39:26 PM	79226.07	0.0606494680929861	8/9/2017 2:39:26 PM	Jesus777: 113412 (79226)
4ba7e54d-ec4e-4a6f-8003-79fc5cad2487	tiras		577	19995.0000	1728.2855	8/9/2017 2:39:26 PM	28496.3	0.0606494680929861	8/9/2017 2:39:26 PM	tirasworks: 45371 (28496)

6619ecfd-a25f-4393-b90c-196de1cb7f75	jc12345		576	19995.0000	2326.7319	8/9/2017 2:12:48 PM	19874.89	0.117068924354683	8/9/2017 2:12:48 PM	jc12345.1: 32167 (19875)
4fe90646-5b5f-49bf-9c64-f8a913b973e4	bible_pay	576	19995.0000	7585.3988	8/9/2017 2:12:48 PM	64794.3	0.117068924354683	8/9/2017 2:12:48 PM	r15: 88098 (64794)
b289e23d-1d97-4149-ba45-6677ba962b8f	jumpinbunny	576	19995.0000	6335.1291	8/9/2017 2:12:48 PM	54114.52	0.117068924354683	8/9/2017 2:12:48 PM	Jesus777: 55290 (54115)
900716bb-62ca-4cae-b143-89d104cd2d88	tiras		576	19995.0000	3747.7403	8/9/2017 2:12:48 PM	32013.11	0.117068924354683	8/9/2017 2:12:48 PM	tirasworks: 47576 (32013)

b7b2a89d-67e1-408b-8a58-5d713a621301	jc12345		575	19998.0000	3293.6308	8/9/2017 2:02:33 PM	25604.32	0.128635734486599	8/9/2017 2:02:33 PM	jc12345.1: 32126 (25604)
9e8e72a9-c884-40f6-bef9-c6ce61d7cba2	bible_pay	575	19998.0000	8441.5605	8/9/2017 2:02:33 PM	65623.76	0.128635734486599	8/9/2017 2:02:33 PM	r15: 88472 (65624)
31f15a64-61c3-41b2-b380-225442389aa3	testbible	575	19998.0000	2051.2566	8/9/2017 2:02:33 PM	15946.24	0.128635734486599	8/9/2017 2:02:33 PM	testbible: 17689 (15946)
7c9d586e-d28c-4309-a320-5c668a441a7d	tiras		575	19998.0000	5023.1974	8/9/2017 2:02:33 PM	39049.78	0.128635734486599	8/9/2017 2:02:33 PM	tirasworks: 47415 (39050)
8cd55983-1c1f-4be7-b98c-ef836ade429f	happy_merchant	575	19998.0000	1188.3547	8/9/2017 2:02:33 PM	9238.14	0.128635734486599	8/9/2017 2:02:33 PM	happy_merchant00: 13011 (9238)

The debug log at the time shows nothing abnormal:

Code:

2017-08-09 19:01:39 UpdateTip: new best=000013b3e09a5ace4c8d87dcadbd6f1a97d61004ea5b3d7cb46dce501c68871a  height=575  log2_work=26.339499  tx=2067  date=2017-08-09 19:01:36 progress=0.002851  cache=0.4MiB(1915tx)
2017-08-09 19:01:39 ProcessNewBlock : ACCEPTED
2017-08-09 19:11:51 UpdateTip: new best=000001d53cbb572419d76001b3742a27bcee8f8c0030e3bef9bcb4239b8ba630  height=576  log2_work=26.350153  tx=2068  date=2017-08-09 19:11:49 progress=0.002852  cache=0.4MiB(1916tx)
2017-08-09 19:11:51 ProcessNewBlock : ACCEPTED
2017-08-09 19:38:31 UpdateTip: new best=0000076b78a8fc0bb351b2ca2854b55bde5430d9397c3c2fc45173630de023ee  height=577  log2_work=26.362141  tx=2069  date=2017-08-09 19:38:28 progress=0.002854  cache=0.4MiB(1917tx)
2017-08-09 19:38:31 ProcessNewBlock : ACCEPTED
2017-08-09 19:41:36 UpdateTip: new best=00001de0c00c110c5893479e1036ee5dcdf14ab2c8f04b7e66977a849bb9dea7  height=578  log2_work=26.367812  tx=2070  date=2017-08-09 19:41:35 progress=0.002855  cache=0.4MiB(1918tx)
2017-08-09 19:41:36 ProcessNewBlock : ACCEPTED

Also happened at block 582, but this time there was an error:

Code:

2017-08-09 19:46:40 UpdateTip: new best=00000ff5d8a60182a69ac948a8cfec4c6b028950f59d3ee970d3ad95b1644ff7  height=581  log2_work=26.392701  tx=2073  date=2017-08-09 19:46:32 progress=0.002859  cache=0.4MiB(1921tx)
2017-08-09 19:46:40 ProcessNewBlock : ACCEPTED
2017-08-09 20:08:59 UpdateTip: new best=000012a13b09357a7d8f6f67ea01af0e7b44ffee11a2c5434e2e129f85018007  height=582  log2_work=26.407361  tx=2074  date=2017-08-09 20:08:58 progress=0.002860  cache=0.4MiB(1922tx)
2017-08-09 20:08:59 ProcessNewBlock : ACCEPTED
2017-08-09 20:09:21 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-09 20:20:50 UpdateTip: new best=00001b2d31c2c126ccba466a8d001ab77c767e72bed697e1027de02be741ad2b  height=583  log2_work=26.416523  tx=2075  date=2017-08-09 20:20:46 progress=0.002862  cache=0.4MiB(1923tx)
2017-08-09 20:20:50 ProcessNewBlock : ACCEPTED

And finally blocks 584 and 585, with a different error occuring at block 584:

Code:

2017-08-09 20:20:50 UpdateTip: new best=00001b2d31c2c126ccba466a8d001ab77c767e72bed697e1027de02be741ad2b  height=583  log2_work=26.416523  tx=2075  date=2017-08-09 20:20:46 progress=0.002862  cache=0.4MiB(1923tx)
2017-08-09 20:20:50 ProcessNewBlock : ACCEPTED
2017-08-09 20:27:54 UpdateTip: new best=000027558d313d80cad64a45db74624beec59967ba6868793eec6046eb01c6f3  height=584  log2_work=26.423361  tx=2076  date=2017-08-09 20:27:36 progress=0.002863  cache=0.4MiB(1924tx)
2017-08-09 20:27:57  

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

2017-08-09 20:27:58 

BiblepayMiner -- runtime error: CreateNewBlock: TestBlockValidity failed:  (code 0)
2017-08-09 20:27:58 ProcessNewBlock : ACCEPTED
2017-08-09 20:29:51 UpdateTip: new best=00001972088e7933fa642467a8b1b51aa68c55913797c879e714cfc30311ed81  height=585  log2_work=26.429534  tx=2077  date=2017-08-09 20:29:47 progress=0.002864  cache=0.4MiB(1925tx)
2017-08-09 20:29:51 ProcessNewBlock : ACCEPTED
2017-08-09 20:41:46 CBlock(hash=000006dc7eb7c0ed050bb64c295d1cd5e5e530e3b8514a8282e4d7dfd8149fb4, ver=536870912, hashPrevBlock=00001972088e7933fa642467a8b1b51aa68c55913797c879e714cfc30311ed81, hashMerkleRoot=7f41015fd0af276794ee02c2fd083a1b87965d628dfb34c3c263b61111b5892d, nTime=1502311305, nBits=1e19f652, nNonce=17734, vtx=1)
  CTransaction(hash=7f41015fd0, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 024a02022e01)
    CTxOut(nValue=19997.00000000, scriptPubKey=76a9149cff090c148949e19f4ed915)


2017-08-09 20:41:46 generated 19997.00
2017-08-09 20:41:46 UpdateTip: new best=000006dc7eb7c0ed050bb64c295d1cd5e5e530e3b8514a8282e4d7dfd8149fb4  height=586  log2_work=26.439813  tx=2078  date=2017-08-09 20:41:45 progress=0.002866  cache=0.4MiB(1926tx)
2017-08-09 20:41:46 ProcessNewBlock : ACCEPTED

[bible_pay]

I noticed that my miner wasn't showing up in the block distribution history at times. Here's an example where it's registering fine up to block 575, disappears during blocks 576 and 577, then returns at block 578.

Code:

3d99591e-5790-4b7a-b219-ab22d2eef382	jc12345		578	19994.0000	1668.9717	8/9/2017 2:42:30 PM	23283.17	0.0716814584926104	8/9/2017 2:42:30 PM	jc12345.1: 32152 (23283)
bcbefc8a-c366-48ce-b7d5-47a3380536ed	seriestoo	578	19994.0000	9074.4408	8/9/2017 2:42:30 PM	126593.98	0.0716814584926104	8/9/2017 2:42:30 PM	intel7700k: 150311 (126594)
seriestoo: 61240 (126594)
2cba286c-0e95-443b-b1af-878621dcda79	testbible	578	19994.0000	891.2757	8/9/2017 2:42:30 PM	12433.84	0.0716814584926104	8/9/2017 2:42:30 PM	testbible: 17715 (12434)
eba0fbab-978f-4a75-8c25-8b2033d8538f	jumpinbunny	578	19994.0000	5615.1193	8/9/2017 2:42:30 PM	78334.33	0.0716814584926104	8/9/2017 2:42:30 PM	Jesus777: 113712 (78334)
0879d8c7-7e38-47d0-8cc2-7d974354def8	tiras		578	19994.0000	2042.6564	8/9/2017 2:42:30 PM	28496.3	0.0716814584926104	8/9/2017 2:42:30 PM	tirasworks: 45371 (28496)
0f649be8-eddc-402c-ae62-1f2152327349	happy_merchant	578	19994.0000	701.5361	8/9/2017 2:42:30 PM	9786.86	0.0716814584926104	8/9/2017 2:42:30 PM	happy_merchant00: 13033 (9787)

6f4dc4a8-549d-4e13-b688-07a9b00ac03c	jc12345		577	19995.0000	1453.3782	8/9/2017 2:39:26 PM	23963.58	0.0606494680929861	8/9/2017 2:39:26 PM	jc12345.1: 32154 (23964)
ff81fe6d-0d05-4986-9eff-a594c3cefd39	bible_pay	577	19995.0000	3954.7030	8/9/2017 2:39:26 PM	65205.9	0.0606494680929861	8/9/2017 2:39:26 PM	r15: 87462 (65206)
f3798682-34b9-493b-9750-d2ef2041e71c	seriestoo	577	19995.0000	8053.6146	8/9/2017 2:39:26 PM	132789.53	0.0606494680929861	8/9/2017 2:39:26 PM	intel7700k: 145944 (132790)
seriestoo: 61148 (132790)
89cfbc27-b5a8-47c6-ba6c-8498af2f9a90	jumpinbunny	577	19995.0000	4805.0187	8/9/2017 2:39:26 PM	79226.07	0.0606494680929861	8/9/2017 2:39:26 PM	Jesus777: 113412 (79226)
4ba7e54d-ec4e-4a6f-8003-79fc5cad2487	tiras		577	19995.0000	1728.2855	8/9/2017 2:39:26 PM	28496.3	0.0606494680929861	8/9/2017 2:39:26 PM	tirasworks: 45371 (28496)

6619ecfd-a25f-4393-b90c-196de1cb7f75	jc12345		576	19995.0000	2326.7319	8/9/2017 2:12:48 PM	19874.89	0.117068924354683	8/9/2017 2:12:48 PM	jc12345.1: 32167 (19875)
4fe90646-5b5f-49bf-9c64-f8a913b973e4	bible_pay	576	19995.0000	7585.3988	8/9/2017 2:12:48 PM	64794.3	0.117068924354683	8/9/2017 2:12:48 PM	r15: 88098 (64794)
b289e23d-1d97-4149-ba45-6677ba962b8f	jumpinbunny	576	19995.0000	6335.1291	8/9/2017 2:12:48 PM	54114.52	0.117068924354683	8/9/2017 2:12:48 PM	Jesus777: 55290 (54115)
900716bb-62ca-4cae-b143-89d104cd2d88	tiras		576	19995.0000	3747.7403	8/9/2017 2:12:48 PM	32013.11	0.117068924354683	8/9/2017 2:12:48 PM	tirasworks: 47576 (32013)

b7b2a89d-67e1-408b-8a58-5d713a621301	jc12345		575	19998.0000	3293.6308	8/9/2017 2:02:33 PM	25604.32	0.128635734486599	8/9/2017 2:02:33 PM	jc12345.1: 32126 (25604)
9e8e72a9-c884-40f6-bef9-c6ce61d7cba2	bible_pay	575	19998.0000	8441.5605	8/9/2017 2:02:33 PM	65623.76	0.128635734486599	8/9/2017 2:02:33 PM	r15: 88472 (65624)
31f15a64-61c3-41b2-b380-225442389aa3	testbible	575	19998.0000	2051.2566	8/9/2017 2:02:33 PM	15946.24	0.128635734486599	8/9/2017 2:02:33 PM	testbible: 17689 (15946)
7c9d586e-d28c-4309-a320-5c668a441a7d	tiras		575	19998.0000	5023.1974	8/9/2017 2:02:33 PM	39049.78	0.128635734486599	8/9/2017 2:02:33 PM	tirasworks: 47415 (39050)
8cd55983-1c1f-4be7-b98c-ef836ade429f	happy_merchant	575	19998.0000	1188.3547	8/9/2017 2:02:33 PM	9238.14	0.128635734486599	8/9/2017 2:02:33 PM	happy_merchant00: 13011 (9238)

The debug log at the time shows nothing abnormal:

Code:

2017-08-09 19:01:39 UpdateTip: new best=000013b3e09a5ace4c8d87dcadbd6f1a97d61004ea5b3d7cb46dce501c68871a  height=575  log2_work=26.339499  tx=2067  date=2017-08-09 19:01:36 progress=0.002851  cache=0.4MiB(1915tx)
2017-08-09 19:01:39 ProcessNewBlock : ACCEPTED
2017-08-09 19:11:51 UpdateTip: new best=000001d53cbb572419d76001b3742a27bcee8f8c0030e3bef9bcb4239b8ba630  height=576  log2_work=26.350153  tx=2068  date=2017-08-09 19:11:49 progress=0.002852  cache=0.4MiB(1916tx)
2017-08-09 19:11:51 ProcessNewBlock : ACCEPTED
2017-08-09 19:38:31 UpdateTip: new best=0000076b78a8fc0bb351b2ca2854b55bde5430d9397c3c2fc45173630de023ee  height=577  log2_work=26.362141  tx=2069  date=2017-08-09 19:38:28 progress=0.002854  cache=0.4MiB(1917tx)
2017-08-09 19:38:31 ProcessNewBlock : ACCEPTED
2017-08-09 19:41:36 UpdateTip: new best=00001de0c00c110c5893479e1036ee5dcdf14ab2c8f04b7e66977a849bb9dea7  height=578  log2_work=26.367812  tx=2070  date=2017-08-09 19:41:35 progress=0.002855  cache=0.4MiB(1918tx)
2017-08-09 19:41:36 ProcessNewBlock : ACCEPTED

Also happened at block 582, but this time there was an error:

Code:

2017-08-09 19:46:40 UpdateTip: new best=00000ff5d8a60182a69ac948a8cfec4c6b028950f59d3ee970d3ad95b1644ff7  height=581  log2_work=26.392701  tx=2073  date=2017-08-09 19:46:32 progress=0.002859  cache=0.4MiB(1921tx)
2017-08-09 19:46:40 ProcessNewBlock : ACCEPTED
2017-08-09 20:08:59 UpdateTip: new best=000012a13b09357a7d8f6f67ea01af0e7b44ffee11a2c5434e2e129f85018007  height=582  log2_work=26.407361  tx=2074  date=2017-08-09 20:08:58 progress=0.002860  cache=0.4MiB(1922tx)
2017-08-09 20:08:59 ProcessNewBlock : ACCEPTED
2017-08-09 20:09:21 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-09 20:20:50 UpdateTip: new best=00001b2d31c2c126ccba466a8d001ab77c767e72bed697e1027de02be741ad2b  height=583  log2_work=26.416523  tx=2075  date=2017-08-09 20:20:46 progress=0.002862  cache=0.4MiB(1923tx)
2017-08-09 20:20:50 ProcessNewBlock : ACCEPTED

And finally blocks 584 and 585, with a different error occuring at block 584 (I think the transaction in block 586 is just a payout on a solo mined block from a while back):

Code:

2017-08-09 20:20:50 UpdateTip: new best=00001b2d31c2c126ccba466a8d001ab77c767e72bed697e1027de02be741ad2b  height=583  log2_work=26.416523  tx=2075  date=2017-08-09 20:20:46 progress=0.002862  cache=0.4MiB(1923tx)
2017-08-09 20:20:50 ProcessNewBlock : ACCEPTED
2017-08-09 20:27:54 UpdateTip: new best=000027558d313d80cad64a45db74624beec59967ba6868793eec6046eb01c6f3  height=584  log2_work=26.423361  tx=2076  date=2017-08-09 20:27:36 progress=0.002863  cache=0.4MiB(1924tx)
2017-08-09 20:27:57  

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

2017-08-09 20:27:58 

BiblepayMiner -- runtime error: CreateNewBlock: TestBlockValidity failed:  (code 0)
2017-08-09 20:27:58 ProcessNewBlock : ACCEPTED
2017-08-09 20:29:51 UpdateTip: new best=00001972088e7933fa642467a8b1b51aa68c55913797c879e714cfc30311ed81  height=585  log2_work=26.429534  tx=2077  date=2017-08-09 20:29:47 progress=0.002864  cache=0.4MiB(1925tx)
2017-08-09 20:29:51 ProcessNewBlock : ACCEPTED
2017-08-09 20:41:46 CBlock(hash=000006dc7eb7c0ed050bb64c295d1cd5e5e530e3b8514a8282e4d7dfd8149fb4, ver=536870912, hashPrevBlock=00001972088e7933fa642467a8b1b51aa68c55913797c879e714cfc30311ed81, hashMerkleRoot=7f41015fd0af276794ee02c2fd083a1b87965d628dfb34c3c263b61111b5892d, nTime=1502311305, nBits=1e19f652, nNonce=17734, vtx=1)
  CTransaction(hash=7f41015fd0, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 024a02022e01)
    CTxOut(nValue=19997.00000000, scriptPubKey=76a9149cff090c148949e19f4ed915)


2017-08-09 20:41:46 generated 19997.00
2017-08-09 20:41:46 UpdateTip: new best=000006dc7eb7c0ed050bb64c295d1cd5e5e530e3b8514a8282e4d7dfd8149fb4  height=586  log2_work=26.439813  tx=2078  date=2017-08-09 20:41:45 progress=0.002866  cache=0.4MiB(1926tx)
2017-08-09 20:41:46 ProcessNewBlock : ACCEPTED

576 through 578 seem to be right at the same time you were spamming the pool.  Its possible the timespan where you killed the app pool caused the pool to kick you out of that round (it does that if it doesnt hear from you for 3 minutes), and at the same time, the client itself starts signing the blocks with your address, so it shouldnt technically be a concern as the block is either signed into the pool, or signed solo but never both.  I guess its possible that a straggling thread kept signing the blocks for the pool and the pool kicked out the miner, but solving the block under that is a longshot.  I think the main thing we should do is now that we have anti d-dos turned on the pool, let it run for 24 hours and see if you are not in any block reward.  If not we will need to add logging to show what the client did during that span (IE was it solo mining because it thought the pool was down?).  If you want you can edit your config and put in 'debugmaster=true' tonight and let it run all night.  But that will be a HUGE amount of spam, but might be revealing tomorrow if we find a lapse.

[bible_pay]

The pool now recovers from errors where the user tries to hit pages and is no longer logged in.

I added the requested anonymous user feature, if you go to account and click 'cloak' user and save the record.

Regarding my testnet pool miner crashing, I added a global csection that *may* fix that, now I am burning it in tonight, good night.

[marte1982]

Hi dev...when pool go online..i mean mainnet? thanks for your support

[happy_merchant]

Ah, you're right, that was around the same time.

It also happened again quite a bit later at block 604 with the same error as block 584/585:

Code:

2017-08-09 23:33:45 UpdateTip: new best=000015cb5f14b102bd89e9cd1c1e835e9ee56754895a7b6208272c40cac135fa  height=604  log2_work=26.525747  tx=2109  date=2017-08-09 23:33:43 progress=0.002907  cache=0.4MiB(1967tx)
2017-08-09 23:33:45  

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

2017-08-09 23:33:45 

BiblepayMiner -- runtime error: CreateNewBlock: TestBlockValidity failed:  (code 0)
2017-08-09 23:33:45 ProcessNewBlock : ACCEPTED
2017-08-09 23:38:45 UpdateTip: new best=00001db3d3ff8196dc01a228037e4c88254b44aa730e222b7e256426e207cb25  height=605  log2_work=26.533668  tx=2110  date=2017-08-09 23:38:43 progress=0.002908  cache=0.4MiB(1968tx)
2017-08-09 23:38:45 ProcessNewBlock : ACCEPTED
2017-08-09 23:58:15 UpdateTip: new best=00001744716e7698fcaae5352b51c16dde765c7c7a26d1ecbd333790e62ca92b  height=606  log2_work=26.542772  tx=2111  date=2017-08-09 23:58:13 progress=0.002910  cache=0.4MiB(1969tx)
2017-08-09 23:58:15 ProcessNewBlock : ACCEPTED

Went ahead and enabled debugmaster, will check in the morning to see if it happens again tonight.

[happy_merchant]

A minor issue on the website, since I spammed all those withdrawals the transaction history page doesn't seem to be updating any longer. It stops on block 547 after listing a few hundred of the withdrawals. BBP from mining is still being credited and I can still make withdrawals, though, so it looks like it's just a display error.

[bible_pay]

A minor issue on the website, since I spammed all those withdrawals the transaction history page doesn't seem to be updating any longer. It stops on block 547 after listing a few hundred of the withdrawals. BBP from mining is still being credited and I can still make withdrawals, though, so it looks like it's just a display error.

It just shows the last 512 transactions in the transaction log to keep the pages list short, however it was ordered by UPDATED not UPDATED Desc, so that change will be in the *next* pool release, however in the mean time, I deleted the 1200 transactions < .05 BBP from your account so you should be able to see the list now.

[happy_merchant]

Alright, so my miner apparently dropped out of the pool for blocks 642-643 and 659-660. Here's the verbose debug log for blocks 658-661

https://pastebin.com/qdB4v9dX (block 658)
https://pastebin.com/G6kawJYc (block 659)
https://pastebin.com/qG5VSDf2 (block 660)
https://pastebin.com/npy6NbBB (block 661)

https://file.io/ODsv3P (entire log)

Nothing really jumps out at me from the logs. Doesn't look like other miners are having the same issue, so it's a little weird.

[bee_irl]

Ah, you're right, that was around the same time.

It also happened again quite a bit later at block 604 with the same error as block 584/585:

Code:

2017-08-09 23:33:45 UpdateTip: new best=000015cb5f14b102bd89e9cd1c1e835e9ee56754895a7b6208272c40cac135fa  height=604  log2_work=26.525747  tx=2109  date=2017-08-09 23:33:43 progress=0.002907  cache=0.4MiB(1967tx)
2017-08-09 23:33:45  

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

2017-08-09 23:33:45 

BiblepayMiner -- runtime error: CreateNewBlock: TestBlockValidity failed:  (code 0)
2017-08-09 23:33:45 ProcessNewBlock : ACCEPTED
2017-08-09 23:38:45 UpdateTip: new best=00001db3d3ff8196dc01a228037e4c88254b44aa730e222b7e256426e207cb25  height=605  log2_work=26.533668  tx=2110  date=2017-08-09 23:38:43 progress=0.002908  cache=0.4MiB(1968tx)
2017-08-09 23:38:45 ProcessNewBlock : ACCEPTED
2017-08-09 23:58:15 UpdateTip: new best=00001744716e7698fcaae5352b51c16dde765c7c7a26d1ecbd333790e62ca92b  height=606  log2_work=26.542772  tx=2111  date=2017-08-09 23:58:13 progress=0.002910  cache=0.4MiB(1969tx)
2017-08-09 23:58:15 ProcessNewBlock : ACCEPTED

Went ahead and enabled debugmaster, will check in the morning to see if it happens again tonight.

Edit: seems like a normal fork or reorg. Were you watching the network to see if that happened?

[happy_merchant]

Edit: seems like a normal fork or reorg. Were you watching the network to see if that happened?

A blockchain fork? It's not like one miner in a pool can be off mining down the wrong blockchain since work is delegated by the pool server.

At least, that'd normally be the case. Biblehash is a little unique and involves a reference to the previous block in the chain which requires miners to run their own full nodes, so I suppose it might be possible that a user in the pool would be attempting to mine while referencing an orphan block, which would probably result in all their shares being rejected. I don't know if the pool checks to make sure all users are synced properly. I don't think that's the case here though since all the hashes from the logs seem to match up with the test blockchain.