BiblePay - New Coin Launch - Official Thread

[tiras]

Please be ready for a mandatory upgrade in 4 hours.

I was born ready. Awesome work, very fast.

I see 1.0.3.2 is already on GitHub, so we can start the upgrade?

Lets give it a couple hours at least, so the windows users have a "chance" to come online.
This way we can all sort of get in together. 

I started linux upgrades.  they will take at least an hour anyway .  thanks Bible_pay

Yeah, "make" takes around half an hour on high spec machines. Is there a way to only build changed files, like src/main.cpp and src/pow.cpp?

On my debian box, I do partial non-clean builds, and all I do is run a script that does the git pull origin master, then I skip over to 'make' (dont configure or autogen), and it builds a lot faster.

sorry to say , but 1.0.3.2 on linux is dying the same way as 1.0.3.1   .   have to follow the same routine restarting the daemon 

[bible_pay]

Code:

************************
EXCEPTION: St13runtime_error
tinyformat: Not enough conversion specifiers in format string
biblepay in ProcessMessages()

2017-09-13 15:34:23 ProcessMessages(block, 191 bytes) FAILED peer=1
2017-09-13 15:34:23 89

************************

I got this error in 1.0.3.2 in debug.log, repeated many times, and it stopped syncing after that. The error started right after block 7099 has been synced.

I am getting a similar error with Windows 32 bit v1.0.3.2 exe

Code:

2017-09-13 15:32:59 init message: Activating best chain...
2017-09-13 15:32:59 

************************
EXCEPTION: St13runtime_error       
tinyformat: Not enough conversion specifiers in format string       
C:\Program Files (x86)\BiblepayCore\biblepay-qt.exe in Runaway exception       

2017-09-13 15:33:02 CDBEnv::EnvShutdown: Error 22 shutting down database environment: Invalid argument
2017-09-13 15:34:21 

Checking, but in the mean time I vaguely remember this happens when the wallet cant open the wallet.dat file.  Please try restoring a backup of wallet.dat  from the backups folder and let me know.

[Shoko943]

Please be ready for a mandatory upgrade in 4 hours.

I was born ready. Awesome work, very fast.

I see 1.0.3.2 is already on GitHub, so we can start the upgrade?

Lets give it a couple hours at least, so the windows users have a "chance" to come online.
This way we can all sort of get in together.  

I started linux upgrades.  they will take at least an hour anyway .  thanks Bible_pay

Yeah, "make" takes around half an hour on high spec machines. Is there a way to only build changed files, like src/main.cpp and src/pow.cpp?

On my debian box, I do partial non-clean builds, and all I do is run a script that does the git pull origin master, then I skip over to 'make' (dont configure or autogen), and it builds a lot faster.

sorry to say , but 1.0.3.2 on linux is dying the same way as 1.0.3.1   .   have to follow the same routine restarting the daemon  

I just upgraded and I have had no issues so far. I'm running Ubuntu 17.04.

[bible_pay]

sorry to say , but 1.0.3.2 on linux is dying the same way as 1.0.3.1   .   have to follow the same routine restarting the daemon 

Im not sure I completely understand, what is dying and restarting which daemon? (I know we always restart the daemon), and Im dealing with many spinning errors, not sure what you mean about 'dying'.

[bible_pay]

Well explained, like Blu I'll have to re-read it again to get a complete understanding.  But I would echo his request on versions, if there would be a way for the Core to report what OS was used, it would be very interesting to know and could lead to some improvements.  Thanks as always for your attention and willingness to work that keeps this coin moving forward.

Yeah, I think what we can do is during the init.cpp, we can determine if its Win (as code exists to choose the windows tcp stack), linux (as we know its not win and not mac), or MAC.  And set a variable globally.  Then when the user hits the pool, relay the client version and the OS.

This would be useful to allow the pool to collect user baseline.  Then later we can expose a report in the pool to show the % by OS flavor.

I think we can do this.

[616westwarmoth]

Biblepay v1.0.3.2 - Mandatory Upgrade
https://www.biblepay.org
https://github.com/biblepay/biblepay

- Fix f7000 Low-Subsidy based on High-Diff calculation
- Fix Pool banning issue
- Fix Read Disk error

Got a Runaway Exception pop up on two of my boxes so far (Win7) on Windows 64bit file.  "A fatal error occurred. Biblepay Core can no longer safely continue and will quit."

Debug file :

EXCEPTION: St13runtime_error      
tinyformat: Not enough conversion specifiers in format string      
C:\Program Files\BiblepayCore\biblepay-qt.exe in Runaway exception      

2017-09-13 15:52:44 CDBEnv::EnvShutdown: Error 22 shutting down database environment: Invalid argument

[bible_pay]

Biblepay v1.0.3.2 - Mandatory Upgrade
https://www.biblepay.org
https://github.com/biblepay/biblepay

- Fix f7000 Low-Subsidy based on High-Diff calculation
- Fix Pool banning issue
- Fix Read Disk error

Got a Runaway Exception pop up on two of my boxes so far (Win7) on Windows 64bit file.  "A fatal error occurred. Biblepay Core can no longer safely continue and will quit."

Debug file :

EXCEPTION: St13runtime_error      
tinyformat: Not enough conversion specifiers in format string      
C:\Program Files\BiblepayCore\biblepay-qt.exe in Runaway exception      

2017-09-13 15:52:44 CDBEnv::EnvShutdown: Error 22 shutting down database environment: Invalid argument

I believe this happens when you Kill your client without pressing File | Exit.
Try restoring wallet.dat and tell me if it comes up?

EDIT: Also, tell me if your biblepay.conf file is corrupted?

[maarekelets]

sorry to say , but 1.0.3.2 on linux is dying the same way as 1.0.3.1   .   have to follow the same routine restarting the daemon  

Im not sure I completely understand, what is dying and restarting which daemon? (I know we always restart the daemon), and Im dealing with many spinning errors, not sure what you mean about 'dying'.

Sorry to add to the list of errors, but the Windows client on Windows 10( PRO 64bit - 1.0.3.2) had a bout of throwing handled exceptions. Client didn't crash and it seemed to recover but I thought you would want to see these:


2017-09-13 15:45:53 ProcessNewBlock : ACCEPTED
2017-09-13 15:45:53 89UpdateTip: new best=2809f4104b07d723c0f40c923b3d0cd30dbf58d520d231ed049f998d2b553f0f  height=7449  log2_work=48.978403  tx=11461  date=2017-09-13 15:30:44 progress=0.999908  cache=0.0MiB(4tx)
2017-09-13 15:45:53 ProcessNewBlock : ACCEPTED
2017-09-13 15:45:54 89

************************
EXCEPTION: St13runtime_error      
tinyformat: Not enough conversion specifiers in format string      
C:\Program Files\BiblepayCore\biblepay-qt.exe in ProcessMessages()      

2017-09-13 15:45:54 ProcessMessages(block, 191 bytes) FAILED peer=2
2017-09-13 15:45:54 89

************************
EXCEPTION: St13runtime_error      
tinyformat: Not enough conversion specifiers in format string      
C:\Program Files\BiblepayCore\biblepay-qt.exe in ProcessMessages()      

2017-09-13 15:45:54 ProcessMessages(block, 190 bytes) FAILED peer=2
2017-09-13 15:45:54 89

************************
EXCEPTION: St13runtime_error      
tinyformat: Not enough conversion specifiers in format string      
C:\Program Files\BiblepayCore\biblepay-qt.exe in ProcessMessages()      

2017-09-13 15:45:54 ProcessMessages(block, 191 bytes) FAILED peer=2
2017-09-13 15:46:04 P2P peers available. Skipped DNS seeding.
2017-09-13 15:46:04 dnsseed thread exit
2017-09-13 15:46:15 89

************************
EXCEPTION: St13runtime_error      
tinyformat: Not enough conversion specifiers in format string      
C:\Program Files\BiblepayCore\biblepay-qt.exe in ProcessMessages()      

2017-09-13 15:46:15 ProcessMessages(block, 190 bytes) FAILED peer=7
2017-09-13 15:46:15 89

************************
EXCEPTION: St13runtime_error      
tinyformat: Not enough conversion specifiers in format string      
C:\Program Files\BiblepayCore\biblepay-qt.exe in ProcessMessages()      

2017-09-13 15:46:15 ProcessMessages(block, 428 bytes) FAILED peer=7
2017-09-13 15:46:15 89

************************
EXCEPTION: St13runtime_error      
tinyformat: Not enough conversion specifiers in format string      
C:\Program Files\BiblepayCore\biblepay-qt.exe in ProcessMessages()      

2017-09-13 15:46:15 ProcessMessages(block, 190 bytes) FAILED peer=7
2017-09-13 15:46:15 89

************************
EXCEPTION: St13runtime_error      
tinyformat: Not enough conversion specifiers in format string      
C:\Program Files\BiblepayCore\biblepay-qt.exe in ProcessMessages()


Seems to be functioning without it, and maybe it's due to the mixed version network right now but I wanted you to see anyway.

--edit-- I'll try relaunching and restoring the wallet

--continuing--

After removing wallet.dat and having a new one built I have this happen after the conclusion which crashes the app:

2017-09-13 16:08:24  wallet               146680ms
2017-09-13 16:08:24 init message: Activating best chain...
2017-09-13 16:08:24

************************
EXCEPTION: St13runtime_error      
tinyformat: Not enough conversion specifiers in format string      
C:\Program Files\BiblepayCore\biblepay-qt.exe in Runaway exception      


If I delete the new wallet and copy the old wallet.dat that worked with 1.0.3.2 earlier but had the recoverable errors, the application crashes like it did with the new built wallet. config.conf looks ok.

[Shoko943]

Sorry to add to the list too but I have noticed that my upgraded miners were banning a lot of people. Could we get the same issue of us banning each other or is it just a coincidence? I have never really paid attention to it before.

[x5650]

Biblepay v1.0.3.2 - Mandatory Upgrade
https://www.biblepay.org
https://github.com/biblepay/biblepay

- Fix f7000 Low-Subsidy based on High-Diff calculation
- Fix Pool banning issue
- Fix Read Disk error

Got a Runaway Exception pop up on two of my boxes so far (Win7) on Windows 64bit file.  "A fatal error occurred. Biblepay Core can no longer safely continue and will quit."

Debug file :

EXCEPTION: St13runtime_error      
tinyformat: Not enough conversion specifiers in format string      
C:\Program Files\BiblepayCore\biblepay-qt.exe in Runaway exception      

2017-09-13 15:52:44 CDBEnv::EnvShutdown: Error 22 shutting down database environment: Invalid argument

Same error here on W10x64

[bible_pay]

So on the ST13 error, I see we have a line of code for DGW that is strictly used to log to the screen and it could potentially be causing the ST13 error.

I commented that out, and pushed 1.0.3.3 out.  Anyone on Linux that has this ST13 error, please upgrade to 1.0.3.3 and let us know if that fixes the ST13 error.

Ill build a new version of Win just in case.

I have to run a few errands, windows is building now.

Regarding the Ban issue:  This new version will ban 1031 and down, because the subsidy is higher.  We will just have to wait until everyone upgrades to 1033 to test the ban issue to make sure its gone.

[616westwarmoth]

Biblepay v1.0.3.2 - Mandatory Upgrade
https://www.biblepay.org
https://github.com/biblepay/biblepay

- Fix f7000 Low-Subsidy based on High-Diff calculation
- Fix Pool banning issue
- Fix Read Disk error

Got a Runaway Exception pop up on two of my boxes so far (Win7) on Windows 64bit file.  "A fatal error occurred. Biblepay Core can no longer safely continue and will quit."

Debug file :

EXCEPTION: St13runtime_error      
tinyformat: Not enough conversion specifiers in format string      
C:\Program Files\BiblepayCore\biblepay-qt.exe in Runaway exception      

2017-09-13 15:52:44 CDBEnv::EnvShutdown: Error 22 shutting down database environment: Invalid argument

I believe this happens when you Kill your client without pressing File | Exit.
Try restoring wallet.dat and tell me if it comes up?

EDIT: Also, tell me if your biblepay.conf file is corrupted?

The issue I think was likely related to the box doing a Windows Update and restart (that I could have sworn I told it not to do without asking) and borking the file.  Running the Core with -reindex flag has worked so that's good.

[tiras]

sorry to say , but 1.0.3.2 on linux is dying the same way as 1.0.3.1   .   have to follow the same routine restarting the daemon 

Im not sure I completely understand, what is dying and restarting which daemon? (I know we always restart the daemon), and Im dealing with many spinning errors, not sure what you mean about 'dying'.

I meant they are not showing up at the pool .    i.e. behaving the same way as the prev. version.

here is the log of one of them :

Code:

2017-09-13 14:48:05 BibleMiner -- started thread 0.000000 
2017-09-13 14:48:05 BibleMiner -- started thread 1.000000 
2017-09-13 14:48:05 BibleMiner -- started thread 2.000000 
2017-09-13 14:48:05 BibleMiner -- started thread 3.000000 
2017-09-13 14:48:06 BibleMiner -- started thread 4.000000 
2017-09-13 14:48:06 BibleMiner -- started thread 5.000000 
2017-09-13 14:48:06 BibleMiner -- started thread 6.000000 
2017-09-13 14:48:06 BibleMiner -- started thread 7.000000 
2017-09-13 14:48:06  ** Started 8.000000 BibleMiner threads. ** 
2017-09-13 14:48:06 init message: Done loading
2017-09-13 14:48:06 89UpdateTip: new best=53899619490e4df90ee5210ce243a9325ee0195d0a5bd6d65c3025bba69198ca  height=7444  log2_work=48.931185  tx=11454  date=2017-09-13 14:07:23 progress=0.999753  cache=0.0MiB(1tx)
2017-09-13 14:48:06 ProcessNewBlock : ACCEPTED
2017-09-13 14:48:06 89UpdateTip: new best=a3a854b9f21c6d9aea6c00a5453dfb2cfa8a85f7a399806524afb93430557a42  height=7445  log2_work=48.947845  tx=11456  date=2017-09-13 14:31:19 progress=0.999898  cache=0.0MiB(4tx)
2017-09-13 14:48:06 ProcessNewBlock : ACCEPTED
2017-09-13 14:48:06 89UpdateTip: new best=f11cbc8e8537a0dd1f34605b79a9ab84fa653414ece1b61a4966e6a57d695b19  height=7446  log2_work=48.957962  tx=11457  date=2017-09-13 14:33:17 progress=0.999910  cache=0.0MiB(5tx)
2017-09-13 14:48:06 ProcessNewBlock : ACCEPTED
2017-09-13 14:48:06 89UpdateTip: new best=0e976d8710235bebfb812049db26f53ea21162af1db0842e56a92dbe64f61266  height=7447  log2_work=48.965428  tx=11458  date=2017-09-13 14:48:04 progress=1.000000  cache=0.0MiB(6tx)
2017-09-13 14:48:06 ProcessNewBlock : ACCEPTED
2017-09-13 14:48:16 P2P peers available. Skipped DNS seeding.
2017-09-13 14:48:16 dnsseed thread exit
2017-09-13 14:50:37 socket recv error Connection reset by peer (104)
2017-09-13 15:07:15 89UpdateTip: new best=1306c023eb72cd0c0a62790680248212d02a82f83214145de5259137b2482269  height=7448  log2_work=48.972865  tx=11459  date=2017-09-13 15:07:16 progress=1.000000  cache=0.0MiB(8tx)
2017-09-13 15:07:15 ProcessNewBlock : ACCEPTED
2017-09-13 15:07:21 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-09-13 15:10:28 connection from 104.196.246.79:60390 dropped (banned)
2017-09-13 15:15:54 89ProcessNewBlock : ACCEPTED
2017-09-13 15:16:00 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-09-13 15:20:44 ERROR: CheckProofOfWork(): BibleHash does not meet POW level, prevheight 7448.000000 pindexPrev 1306c023eb72cd0c0a62790680248212d02a82f83214145de5259137b2482269 
2017-09-13 15:20:44 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 15:20:44 Misbehaving: 137.74.0.113:40000 (0 -> 1)
2017-09-13 15:20:44 ERROR: invalid header received b45e9f2c2f000255cafe23c4dd20f259433cb42989c3387e5891b0fd43c4595d
2017-09-13 15:20:44 ProcessMessages(headers, 82 bytes) FAILED peer=9
2017-09-13 15:20:44 89UpdateTip: new best=b45e9f2c2f000255cafe23c4dd20f259433cb42989c3387e5891b0fd43c4595d  height=7449  log2_work=48.979726  tx=11461  date=2017-09-13 15:20:48 progress=1.000000  cache=0.0MiB(10tx)
2017-09-13 15:20:44 ProcessNewBlock : ACCEPTED
2017-09-13 15:20:56 socket recv error Connection reset by peer (104)
2017-09-13 15:21:32 socket recv error Connection reset by peer (104)
2017-09-13 15:22:03 socket recv error Connection reset by peer (104)
2017-09-13 15:26:32 89UpdateTip: new best=7abd337581727a798e60c50a919c8c3f216e1695f57fce61854d8680354cb612  height=7450  log2_work=48.984157  tx=11462  date=2017-09-13 15:26:37 progress=1.000001  cache=0.0MiB(11tx)
2017-09-13 15:26:32 ProcessNewBlock : ACCEPTED
2017-09-13 15:27:17 socket recv error Connection reset by peer (104)
2017-09-13 15:30:49 89ERROR: CheckProofOfWork(): BibleHash does not meet POW level, prevheight 7450.000000 pindexPrev 7abd337581727a798e60c50a919c8c3f216e1695f57fce61854d8680354cb612 
2017-09-13 15:30:49 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 15:30:49 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-09-13 15:30:49 Misbehaving: 137.74.0.113:40000 (1 -> 2)
2017-09-13 15:30:49 89UpdateTip: new best=ccd605c48407d2a57215c1a057e65613965252860260ea6b77e94f9574dd03d2  height=7451  log2_work=48.988323  tx=11463  date=2017-09-13 15:30:49 progress=1.000000  cache=0.0MiB(12tx)
2017-09-13 15:30:49 ProcessNewBlock : ACCEPTED
2017-09-13 15:31:55 socket recv error Connection reset by peer (104)
2017-09-13 15:33:25 socket recv error Connection reset by peer (104)
2017-09-13 15:33:33 connection from 58.251.13.45:65320 dropped (banned)
2017-09-13 15:34:36 89UpdateTip: new best=d079bac266a649b646a4a39f3c30feb7fbad6cded83bf4f3b19f435f445ab2bb  height=7452  log2_work=48.994311  tx=11464  date=2017-09-13 15:34:39 progress=1.000000  cache=0.0MiB(13tx)
2017-09-13 15:34:36 ProcessNewBlock : ACCEPTED
2017-09-13 15:40:57 socket recv error Connection reset by peer (104)
2017-09-13 15:41:13 connection from 104.196.246.79:33524 dropped (banned)
2017-09-13 15:41:43 ERROR: CheckProofOfWork(): BibleHash does not meet POW level, prevheight 7451.000000 pindexPrev d1d9c86804153d1abff270dbcd9cfe8307f6ecaa3175e4e4451aefcaf7180b52 
2017-09-13 15:41:43 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 15:41:43 Misbehaving: 123.15.163.209:23683 (0 -> 1)
2017-09-13 15:41:43 ERROR: invalid header received 2139234c53129977c6d7d158a57ef82565d4613a3acf2a68cefb66f57e641acf
2017-09-13 15:41:43 ProcessMessages(headers, 82 bytes) FAILED peer=61
2017-09-13 15:48:19 connection from 109.169.86.14:47298 dropped (banned)
2017-09-13 15:49:02 ERROR: CheckProofOfWork(): BibleHash does not meet POW level, prevheight 7253.000000 pindexPrev b37ad1d0edffffb29d1c2c67d0184ea1378042f62ec825096f2dff237def1f96 
2017-09-13 15:49:02 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 15:49:02 Misbehaving: 188.165.245.179:59158 (0 -> 1)
2017-09-13 15:49:02 ERROR: invalid header received 086256ccb0145fcfb63cb70d33980a7f477379cc3b53dd9fd98898b6de303a9f
2017-09-13 15:49:02 ProcessMessages(headers, 40503 bytes) FAILED peer=75
2017-09-13 15:51:01 socket recv error Connection reset by peer (104)
2017-09-13 15:52:15 socket recv error Connection reset by peer (104)
2017-09-13 15:54:32 socket recv error Connection reset by peer (104)
2017-09-13 15:59:06 socket recv error Connection reset by peer (104)
2017-09-13 16:00:05 89ProcessNewBlock : ACCEPTED
2017-09-13 16:00:05 89ProcessNewBlock : ACCEPTED
2017-09-13 16:00:05 89ProcessNewBlock : ACCEPTED
2017-09-13 16:00:05 89ProcessNewBlock : ACCEPTED
2017-09-13 16:00:05 89UpdateTip: new best=ccd605c48407d2a57215c1a057e65613965252860260ea6b77e94f9574dd03d2  height=7451  log2_work=48.988323  tx=11463  date=2017-09-13 15:30:49 progress=0.999823  cache=0.0MiB(19tx)
2017-09-13 16:00:05 UpdateTip: new best=7abd337581727a798e60c50a919c8c3f216e1695f57fce61854d8680354cb612  height=7450  log2_work=48.984157  tx=11462  date=2017-09-13 15:26:37 progress=0.999797  cache=0.0MiB(18tx)
2017-09-13 16:00:05 UpdateTip: new best=b45e9f2c2f000255cafe23c4dd20f259433cb42989c3387e5891b0fd43c4595d  height=7449  log2_work=48.979726  tx=11461  date=2017-09-13 15:20:48 progress=0.999762  cache=0.0MiB(17tx)
2017-09-13 16:00:05 UpdateTip: new best=1306c023eb72cd0c0a62790680248212d02a82f83214145de5259137b2482269  height=7448  log2_work=48.972865  tx=11459  date=2017-09-13 15:07:16 progress=0.999680  cache=0.0MiB(15tx)
2017-09-13 16:00:05 UpdateTip: new best=0e976d8710235bebfb812049db26f53ea21162af1db0842e56a92dbe64f61266  height=7447  log2_work=48.965428  tx=11458  date=2017-09-13 14:48:04 progress=0.999564  cache=0.0MiB(14tx)
2017-09-13 16:00:05 UpdateTip: new best=e758bb73bb98bd533ec5b4f4d7a6a448e9fe48077f38bd96485e0c0207b3cd25  height=7448  log2_work=48.972865  tx=11460  date=2017-09-13 15:15:53 progress=0.999732  cache=0.0MiB(16tx)
2017-09-13 16:00:05 ERROR: CheckProofOfWork(): BibleHash does not meet POW level, prevheight 7448.000000 pindexPrev e758bb73bb98bd533ec5b4f4d7a6a448e9fe48077f38bd96485e0c0207b3cd25 
2017-09-13 16:00:05 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 16:00:05 Misbehaving: 114.41.82.143:40000 (0 -> 1)
2017-09-13 16:00:05 InvalidChainFound: invalid block=2809f4104b07d723c0f40c923b3d0cd30dbf58d520d231ed049f998d2b553f0f  height=7449  log2_work=48.978403  date=2017-09-13 15:30:44
2017-09-13 16:00:05 InvalidChainFound:  current best=e758bb73bb98bd533ec5b4f4d7a6a448e9fe48077f38bd96485e0c0207b3cd25  height=7448  log2_work=48.972865  date=2017-09-13 15:15:53
2017-09-13 16:00:05 ERROR: ConnectTip(): ConnectBlock 2809f4104b07d723c0f40c923b3d0cd30dbf58d520d231ed049f998d2b553f0f failed
2017-09-13 16:00:05 InvalidChainFound: invalid block=e758bb73bb98bd533ec5b4f4d7a6a448e9fe48077f38bd96485e0c0207b3cd25  height=7448  log2_work=48.972865  date=2017-09-13 15:15:53
2017-09-13 16:00:05 InvalidChainFound:  current best=e758bb73bb98bd533ec5b4f4d7a6a448e9fe48077f38bd96485e0c0207b3cd25  height=7448  log2_work=48.972865  date=2017-09-13 15:15:53
2017-09-13 16:00:05 UpdateTip: new best=0e976d8710235bebfb812049db26f53ea21162af1db0842e56a92dbe64f61266  height=7447  log2_work=48.965428  tx=11458  date=2017-09-13 14:48:04 progress=0.999564  cache=0.0MiB(14tx)
2017-09-13 16:00:05 ERROR: CheckProofOfWork(): BibleHash does not meet POW level, prevheight 7447.000000 pindexPrev 0e976d8710235bebfb812049db26f53ea21162af1db0842e56a92dbe64f61266 
2017-09-13 16:00:05 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 16:00:05 InvalidChainFound: invalid block=1306c023eb72cd0c0a62790680248212d02a82f83214145de5259137b2482269  height=7448  log2_work=48.972865  date=2017-09-13 15:07:16
2017-09-13 16:00:05 InvalidChainFound:  current best=0e976d8710235bebfb812049db26f53ea21162af1db0842e56a92dbe64f61266  height=7447  log2_work=48.965428  date=2017-09-13 14:48:04
2017-09-13 16:00:05 ERROR: ConnectTip(): ConnectBlock 1306c023eb72cd0c0a62790680248212d02a82f83214145de5259137b2482269 failed
2017-09-13 16:00:05 InvalidChainFound: invalid block=1306c023eb72cd0c0a62790680248212d02a82f83214145de5259137b2482269  height=7448  log2_work=48.972865  date=2017-09-13 15:07:16
2017-09-13 16:00:05 InvalidChainFound:  current best=0e976d8710235bebfb812049db26f53ea21162af1db0842e56a92dbe64f61266  height=7447  log2_work=48.965428  date=2017-09-13 14:48:04
2017-09-13 16:00:05 ProcessNewBlock : ACCEPTED
2017-09-13 16:00:05 ERROR: AcceptBlockHeader: block is marked invalid
2017-09-13 16:00:05 ERROR: invalid header received b97f89e52b49bc03b21c68937c7259825862846d6a043cb94d5175bcfd999ec0
2017-09-13 16:00:05 ProcessMessages(headers, 82 bytes) FAILED peer=76
2017-09-13 16:00:05 ERROR: AcceptBlockHeader: block is marked invalid
2017-09-13 16:00:05 ERROR: invalid header received b97f89e52b49bc03b21c68937c7259825862846d6a043cb94d5175bcfd999ec0
2017-09-13 16:00:05 ProcessMessages(headers, 82 bytes) FAILED peer=61
2017-09-13 16:00:06 ERROR: AcceptBlockHeader: block is marked invalid
2017-09-13 16:00:06 ERROR: invalid header received b97f89e52b49bc03b21c68937c7259825862846d6a043cb94d5175bcfd999ec0
2017-09-13 16:00:06 ProcessMessages(headers, 82 bytes) FAILED peer=50
2017-09-13 16:00:06 ERROR: AcceptBlockHeader: block is marked invalid
2017-09-13 16:00:06 ERROR: invalid header received b97f89e52b49bc03b21c68937c7259825862846d6a043cb94d5175bcfd999ec0
2017-09-13 16:00:06 ProcessMessages(headers, 82 bytes) FAILED peer=86
2017-09-13 16:00:06 ERROR: AcceptBlockHeader: block is marked invalid
2017-09-13 16:00:06 ERROR: invalid header received b97f89e52b49bc03b21c68937c7259825862846d6a043cb94d5175bcfd999ec0
2017-09-13 16:00:06 ProcessMessages(headers, 82 bytes) FAILED peer=49
2017-09-13 16:00:06 ERROR: AcceptBlockHeader: block is marked invalid
2017-09-13 16:00:06 ERROR: invalid header received b97f89e52b49bc03b21c68937c7259825862846d6a043cb94d5175bcfd999ec0
2017-09-13 16:00:06 ProcessMessages(headers, 82 bytes) FAILED peer=51
2017-09-13 16:00:07 ERROR: AcceptBlockHeader: block is marked invalid
2017-09-13 16:00:07 ERROR: invalid header received b97f89e52b49bc03b21c68937c7259825862846d6a043cb94d5175bcfd999ec0
2017-09-13 16:00:07 ProcessMessages(headers, 82 bytes) FAILED peer=85
2017-09-13 16:00:11 CMasternodeSync::CheckNodeHeight -- skipping peer, who announced more headers than we have blocks currently, nHeight=7448, nSyncHeight=7451, peer=4
2017-09-13 16:00:11 CMasternodeSync::CheckNodeHeight -- skipping peer, who announced more headers than we have blocks currently, nHeight=7448, nSyncHeight=7452, peer=6
2017-09-13 16:00:11 CMasternodeSync::CheckNodeHeight -- skipping peer, who announced more headers than we have blocks currently, nHeight=7448, nSyncHeight=7451, peer=31
2017-09-13 16:00:11 CMasternodeSync::CheckNodeHeight -- skipping peer, who announced more headers than we have blocks currently, nHeight=7448, nSyncHeight=7452, peer=49
2017-09-13 16:00:11 CMasternodeSync::CheckNodeHeight -- skipping peer, who announced more headers than we have blocks currently, nHeight=7448, nSyncHeight=7452, peer=50
2017-09-13 16:00:11 CMasternodeSync::CheckNodeHeight -- skipping peer, who announced more headers than we have blocks currently, nHeight=7448, nSyncHeight=7452, peer=51
2017-09-13 16:00:11 CMasternodeSync::CheckNodeHeight -- skipping peer, who announced more headers than we have blocks currently, nHeight=7448, nSyncHeight=7451, peer=61
2017-09-13 16:00:11 CMasternodeSync::CheckNodeHeight -- skipping peer, who announced more headers than we have blocks currently, nHeight=7448, nSyncHeight=7452, peer=71
2017-09-13 16:00:11 CMasternodeSync::CheckNodeHeight -- skipping peer, who announced more headers than we have blocks currently, nHeight=7448, nSyncHeight=7453, peer=73
2017-09-13 16:00:11 CMasternodeSync::CheckNodeHeight -- skipping peer, who announced more headers than we have blocks currently, nHeight=7448, nSyncHeight=7452, peer=76
2017-09-13 16:00:11 CMasternodeSync::CheckNodeHeight -- skipping peer, who announced more headers than we have blocks currently, nHeight=7448, nSyncHeight=7452, peer=85
2017-09-13 16:00:11 CMasternodeSync::CheckNodeHeight -- skipping peer, who announced more headers than we have blocks currently, nHeight=7448, nSyncHeight=7452, peer=86
2017-09-13 16:01:20 connection from 109.169.86.14:47802 dropped (banned)
2017-09-13 16:03:28 ERROR: AcceptBlockHeader: block is marked invalid
2017-09-13 16:03:28 ERROR: invalid header received 1306c023eb72cd0c0a62790680248212d02a82f83214145de5259137b2482269
2017-09-13 16:03:28 ProcessMessages(headers, 406 bytes) FAILED peer=95
2017-09-13 16:04:13 ERROR: AcceptBlockHeader: block is marked invalid
2017-09-13 16:04:13 ERROR: invalid header received 1306c023eb72cd0c0a62790680248212d02a82f83214145de5259137b2482269
2017-09-13 16:04:13 ProcessMessages(headers, 406 bytes) FAILED peer=96
2017-09-13 16:04:22 ERROR: AcceptBlockHeader: block is marked invalid
2017-09-13 16:04:22 ERROR: invalid header received 1306c023eb72cd0c0a62790680248212d02a82f83214145de5259137b2482269
2017-09-13 16:04:22 ProcessMessages(headers, 406 bytes) FAILED peer=99
2017-09-13 16:04:39 ERROR: AcceptBlockHeader: block is marked invalid
2017-09-13 16:04:39 ERROR: invalid header received 1306c023eb72cd0c0a62790680248212d02a82f83214145de5259137b2482269
2017-09-13 16:04:39 ProcessMessages(headers, 406 bytes) FAILED peer=100
2017-09-13 16:05:08 ERROR: AcceptBlockHeader: block is marked invalid
2017-09-13 16:05:08 ERROR: invalid header received 1306c023eb72cd0c0a62790680248212d02a82f83214145de5259137b2482269
2017-09-13 16:05:08 ProcessMessages(headers, 406 bytes) FAILED peer=103
2017-09-13 16:05:31 connection from 104.196.246.79:34630 dropped (banned)
2017-09-13 16:06:12 ERROR: AcceptBlockHeader: block is marked invalid
2017-09-13 16:06:12 ERROR: invalid header received 1306c023eb72cd0c0a62790680248212d02a82f83214145de5259137b2482269
2017-09-13 16:06:12 ProcessMessages(headers, 406 bytes) FAILED peer=105
2017-09-13 16:06:34 socket recv error Connection reset by peer (104)
2017-09-13 16:07:03 ERROR: AcceptBlockHeader: prev block invalid
2017-09-13 16:07:03 Misbehaving: 50.34.189.12:60877 (0 -> 100) BAN THRESHOLD EXCEEDED
2017-09-13 16:07:03 ERROR: invalid header received 105a39f29dadec9252b35612a8f4a4115c2912c3bd9a05741e956b611d3255d7
2017-09-13 16:07:03 ProcessMessages(headers, 82 bytes) FAILED peer=76
2017-09-13 16:07:03 ERROR: AcceptBlockHeader: prev block invalid
2017-09-13 16:07:03 Misbehaving: 123.15.163.209:23683 (1 -> 101) BAN THRESHOLD EXCEEDED
2017-09-13 16:07:03 ERROR: invalid header received 105a39f29dadec9252b35612a8f4a4115c2912c3bd9a05741e956b611d3255d7
2017-09-13 16:07:03 ProcessMessages(headers, 82 bytes) FAILED peer=61
2017-09-13 16:07:03 ERROR: AcceptBlockHeader: prev block invalid
2017-09-13 16:07:03 Misbehaving: 123.15.163.209:22628 (0 -> 100) BAN THRESHOLD EXCEEDED
2017-09-13 16:07:03 ERROR: invalid header received 105a39f29dadec9252b35612a8f4a4115c2912c3bd9a05741e956b611d3255d7
2017-09-13 16:07:03 ProcessMessages(headers, 82 bytes) FAILED peer=50
2017-09-13 16:07:03 ERROR: AcceptBlockHeader: prev block invalid
2017-09-13 16:07:03 Misbehaving: 114.41.82.143:40000 (1 -> 101) BAN THRESHOLD EXCEEDED
2017-09-13 16:07:03 ERROR: invalid header received 105a39f29dadec9252b35612a8f4a4115c2912c3bd9a05741e956b611d3255d7
2017-09-13 16:07:03 ProcessMessages(headers, 82 bytes) FAILED peer=73
2017-09-13 16:07:03 ERROR: AcceptBlockHeader: prev block invalid
2017-09-13 16:07:03 Misbehaving: 112.248.16.195:60678 (0 -> 100) BAN THRESHOLD EXCEEDED
2017-09-13 16:07:03 ERROR: invalid header received 105a39f29dadec9252b35612a8f4a4115c2912c3bd9a05741e956b611d3255d7
2017-09-13 16:07:03 ProcessMessages(headers, 82 bytes) FAILED peer=85
2017-09-13 16:07:03 ERROR: AcceptBlockHeader: prev block invalid
2017-09-13 16:07:03 Misbehaving: 123.15.163.209:23898 (0 -> 100) BAN THRESHOLD EXCEEDED
2017-09-13 16:07:03 ERROR: invalid header received 105a39f29dadec9252b35612a8f4a4115c2912c3bd9a05741e956b611d3255d7
2017-09-13 16:07:03 ProcessMessages(headers, 82 bytes) FAILED peer=86
2017-09-13 16:07:05 ERROR: AcceptBlockHeader: prev block invalid
2017-09-13 16:07:05 Misbehaving: 123.15.163.209:23966 (0 -> 100) BAN THRESHOLD EXCEEDED
2017-09-13 16:07:05 ERROR: invalid header received 105a39f29dadec9252b35612a8f4a4115c2912c3bd9a05741e956b611d3255d7
2017-09-13 16:07:05 ProcessMessages(headers, 82 bytes) FAILED peer=49
2017-09-13 16:07:34 connection from 123.15.163.209:24017 dropped (banned)
2017-09-13 16:07:37 connection from 123.15.163.209:23633 dropped (banned)
2017-09-13 16:07:43 connection from 112.248.16.195:60921 dropped (banned)
2017-09-13 16:07:45 connection from 123.15.163.209:22984 dropped (banned)
2017-09-13 16:07:51 connection from 50.34.189.12:61368 dropped (banned)
2017-09-13 16:07:57 connection from 123.15.163.209:24071 dropped (banned)
2017-09-13 16:08:54 connection from 114.41.82.143:3130 dropped (banned)
2017-09-13 16:09:34 ERROR: AcceptBlockHeader: block is marked invalid
2017-09-13 16:09:34 ERROR: invalid header received 1306c023eb72cd0c0a62790680248212d02a82f83214145de5259137b2482269
2017-09-13 16:09:34 ProcessMessages(headers, 406 bytes) FAILED peer=109
2017-09-13 16:09:36 connection from 123.15.163.209:22922 dropped (banned)

[Shoko943]

So on the ST13 error, I see we have a line of code for DGW that is strictly used to log to the screen and it could potentially be causing the ST13 error.

I commented that out, and pushed 1.0.3.3 out.  Anyone on Linux that has this ST13 error, please upgrade to 1.0.3.3 and let us know if that fixes the ST13 error.

Ill build a new version of Win just in case.

I have to run a few errands, windows is building now.

Regarding the Ban issue:  This new version will ban 1031 and down, because the subsidy is higher.  We will just have to wait until everyone upgrades to 1033 to test the ban issue to make sure its gone.

Welp, just got the ST13 error too on some of my miners, I'm upgrading now.

How long is the ban supposed to last? I was wondering if I could end up having everyone banned on my miners before they upgrade and have them still banned after they upgrade? and if this happens to everyone upgrading now, could we end up with the same situation that happened with f7000?

[svirusxxx2]

Alrighty a guess and some homework for you is all I can offer on this today:

So the old algorithm had an outer loop of 1000 X11 hashes and an inner loop of one biblepay hash, meaning that if you ran 80 threads on x11-bbp pre F7000, that distributed thread could conduct its hashing without the resources of the full node.  (Whenever the miner needs to access the resources of the full node, for example, asking it for AES/md5/chaining the KJV together) grabbing the pindex bestblockindex map, it is in a way locking the thread for a few milliseconds and grabbing its data and then continuing.  In the NEW world, in F7000, its hashing only one X11 hash (for the blockindex), yet 1000 BibleHashes of work being expended per loop.  So its no longer able to decentralize a thread with just a math problem (IE x11 solution), and come back and join the rest of the threads, instead, its doing a lot of biblehash->askfullnode->biblehash->askfullnode, etc.

So my guess is this: In f7000, there is a strong reliance on the full nodes availablility, and the thread itself can only do so much work before its waiting around for availablility of the data it needs (like a blockindex for example, from the map).  The reason the kernel cant allow two threads to read the same value simultaneously is that would cause a segfault error.  

So what I recommend is this: Find a way to run multiple copies of biblepay on one server, and do a side by side comparison of those specs with the sum of the hash of biblepay instances.  If the hash throughput is higher on the multiple copies, then we know that I said above is true and the only way to consolidate hardware to high power servers is then to run multiple instances per node.

On a side note if we find that to be the case then that is good- as you said earlier -part of the benefit of requiring the full node is to reward the decentralized full node environment (IE not the people with the biggest nodes) as part of the original vision is to not be greed based but to be service oriented.

I just run 8 times biblepayd with genproclimit=1 on my Xeon E3-1245 v5 @ 3.5GHz
and now is 70583.5 hashps
Before with one biblepayd with genproclimit=8 I had about 68000 hashps so it's not big diffrent
I run gentoo linux 4.7.10-hardened with ZFS filesystem.

[maarekelets]

After running a -reindex the core now launches but the debug still shows issues.

Code:

2017-09-13 16:16:27 ProcessNewBlock : ACCEPTED
2017-09-13 16:16:27  7100.000000 189LoadExternalBlockFile: Deserialize or I/O error - tinyformat: Not enough conversion specifiers in format string
2017-09-13 16:16:27 189LoadExternalBlockFile: Deserialize or I/O error - tinyformat: Not enough conversion specifiers in format string
2017-09-13 16:16:27 189LoadExternalBlockFile: Deserialize or I/O error - tinyformat: Not enough conversion specifiers in format string
2017-09-13 16:16:27 189LoadExternalBlockFile: Deserialize or I/O error - tinyformat: Not enough conversion specifiers in format string
2017-09-13 16:16:27 189LoadExternalBlockFile: Deserialize or I/O error - tinyformat: Not enough conversion specifiers in format string
2017-09-13 16:16:27 189LoadExternalBlockFile: Deserialize or I/O error - tinyformat: Not enough conversion specifiers in format string
2017-09-13 16:16:27 189LoadExternalBlockFile: Deserialize or I/O error - tinyformat: Not enough conversion specifiers in format string
2017-09-13 16:16:27 189LoadExternalBlockFile: Deserialize or I/O error - tinyformat: Not enough conversion specifiers in format string
... <this goes on for a few hundred more lines>
2017-09-13 16:16:27 189LoadExternalBlockFile: Deserialize or I/O error - tinyformat: Not enough conversion specifiers in format string
2017-09-13 16:16:27 189LoadExternalBlockFile: Deserialize or I/O error - tinyformat: Not enough conversion specifiers in format string
2017-09-13 16:16:27 189LoadExternalBlockFile: Deserialize or I/O error - tinyformat: Not enough conversion specifiers in format string
2017-09-13 16:16:27 Loaded 7100 blocks from external file in 30127ms
2017-09-13 16:16:27 Reindexing finished
2017-09-13 16:16:28 89

************************
EXCEPTION: St13runtime_error       
tinyformat: Not enough conversion specifiers in format string       
C:\Program Files\BiblepayCore\biblepay-qt.exe in ProcessMessages()       

2017-09-13 16:16:28 ProcessMessages(block, 190 bytes) FAILED peer=5
2017-09-13 16:17:22 89

************************
EXCEPTION: St13runtime_error       
tinyformat: Not enough conversion specifiers in format string       
C:\Program Files\BiblepayCore\biblepay-qt.exe in ProcessMessages()       

2017-09-13 16:17:22 ProcessMessages(block, 190 bytes) FAILED peer=9

It seems to be functioning but stuck on 2 days behind in the reindex report in the gui.

[616westwarmoth]

Biblepay v1.0.3.2 - Mandatory Upgrade
https://www.biblepay.org
https://github.com/biblepay/biblepay

- Fix f7000 Low-Subsidy based on High-Diff calculation
- Fix Pool banning issue
- Fix Read Disk error

Got a Runaway Exception pop up on two of my boxes so far (Win7) on Windows 64bit file.  "A fatal error occurred. Biblepay Core can no longer safely continue and will quit."

Debug file :

EXCEPTION: St13runtime_error      
tinyformat: Not enough conversion specifiers in format string      
C:\Program Files\BiblepayCore\biblepay-qt.exe in Runaway exception      

2017-09-13 15:52:44 CDBEnv::EnvShutdown: Error 22 shutting down database environment: Invalid argument

I believe this happens when you Kill your client without pressing File | Exit.
Try restoring wallet.dat and tell me if it comes up?

EDIT: Also, tell me if your biblepay.conf file is corrupted?

The issue I think was likely related to the box doing a Windows Update and restart (that I could have sworn I told it not to do without asking) and borking the file.  Running the Core with -reindex flag has worked so that's good.

Well the -reindex flag will let it start, but it won't start without it in 1.0.3.2  So that's not a fix after all.

[Shoko943]

So on the ST13 error, I see we have a line of code for DGW that is strictly used to log to the screen and it could potentially be causing the ST13 error.

I commented that out, and pushed 1.0.3.3 out.  Anyone on Linux that has this ST13 error, please upgrade to 1.0.3.3 and let us know if that fixes the ST13 error.

Ill build a new version of Win just in case.

I have to run a few errands, windows is building now.

Regarding the Ban issue:  This new version will ban 1031 and down, because the subsidy is higher.  We will just have to wait until everyone upgrades to 1033 to test the ban issue to make sure its gone.

Welp, just got the ST13 error too on some of my miners, I'm upgrading now.

How long is the ban supposed to last? I was wondering if I could end up having everyone banned on my miners before they upgrade and have them still banned after they upgrade? and if this happens to everyone upgrading now, could we end up with the same situation that happened with f7000?

I just finished upgrading to 1033 and I'm still getting the ST13 error.

************************
EXCEPTION: St13runtime_error      
tinyformat: Not enough conversion specifiers in format string      
biblepay in ProcessMessages()  

[seasonw]

I noticed something weird and maybe it is the cause. Pool's height = 7449, but I have both windows machine with height = 7455. It is more blocks than pool had. And I also notice alot of other 1.0.3.1 node with height = 7455.

[jaapgvk]

I noticed something weird and maybe it is the cause. Pool's height = 7449, but I have both windows machine with height = 7455. It is more blocks than pool had. And I also notice alot of other 1.0.3.1 node with height = 7455.

Dev explained a few pages back that that was 'normal'

I'm also having a few issues after updating, including the hanging on 2 days left with -reindex. One of my miners is working though, and on the pool right now.