BiblePay - New Coin Launch - Official Thread

[emdes]

Pool hash has rised 2x?
Pph has droped to 0.00018
My ryzen 1700x droped from 400000 to 5000.

Sent you a PM 

[1714065475]

1714065475

[1714065475]

1714065475

[1714065475]

1714065475

[inblue]

No, this is with all switches off, the only way to do it is to delete debug.log while client is running.

EDIT: When its deleted while running, it will stop writing log data.

Is there a way to delete the debug.log on Windows when the file is being locked while the wallet is running?

Google "Windows unlocker". I don't know which program is free/best/easiest, but any one should do the trick.

Tried that but they all kill the process associated with the file. In this case the wallet itself. When you start up the wallet again it recreates the debug.log and starts filling it up again. Need to figure out a way to delete the file without killing the wallet process while deleting.

I found a way to open the wallet without writing to the debug.log file! Just add this argument to the target of the biblepay-qt:

-printtoconsole
Send trace/debug info to console instead of debug.log file

But actually it will not send it to console either. And if you delete debug.log before starting the wallet, you will see that debug.log will not even be created at all.

So this seems to alleviate the disk I/O load for now.

[Shoko943]

Well, looks like I spoke too soon. After deleting the debug.log file and waiting for a little bit, it went back to the normal chain.

I'm guessing w/e is supposed to check the blocks was busy doing something else? =D. Maybe something to do with the spam in the debug.log file

EDIT: It's still doing it with the debug.log removed. I have a machine that is 10 blocks ahead Will see if it recovers by itself.

[inblue]

"poolinfo3": "HEALTH_DOWN"

Even though I can access the pool in web browser normally. And the miner doesn't seem to be reverting to solo mining.

[seasonw]

"poolinfo3": "HEALTH_DOWN"

Even though I can access the pool in web browser normally. And the miner doesn't seem to be reverting to solo mining.

Same problem in my mining wallet too with message of "HEALTH_DOWN", I think the pool is having some issue too. I checked with the current block height, and the value is -1 


Is there any cli command to disable pool? I just don't want to restart the wallet daemon as I have to remove the debug.log.

[seasonw]

I have 3 machines and all of them are mining at different blocks 

And I noticed that the machines that mined way behind actual blockchain will quit by itself after some minutes. I guessed there might be a lot of different blockchain node out there. FYI, I actually load all 3 machine with same backup blockchain that start from 7030.

[inblue]

I have 3 machines and all of them are mining at different blocks 

And I noticed that the machines that mined way behind actual blockchain will quit by itself after some minutes. I guessed there might be a lot of different blockchain node out there. FYI, I actually load all 3 machine with same backup blockchain that start from 7030.

The same thing is happening to me. At first I thought there were multiple forks etc, but now I think something else is the problem, because I found a lot of lines in debug.log like this:

Code:

2017-09-11 13:55:33 connection from 104.238.138.111:54286 dropped (banned)

Also, the only machines of mine which are not having problems with banning or anything are the ones at Vultr, where the main node is.

[inblue]

@seasonw: Check with "getinfo" command if you are getting this error:

Code:

"errors": "Warning: We do not appear to fully agree with our peers! You may need to upgrade, or other nodes may need to upgrade."

Then you may be forked, or at least it looks like it. That's what I see on some of my machines, but I don't know how they got into that state, but maybe it has to do with some banning of connections.

What is also happening is the corruption of blocks locally (wallet won't start). Reindexing doesn't do anything, I have to delete all local data, but after that when I start the wallet, I get a lot of these errors:

Code:

2017-09-11 14:08:47 ERROR: ReadBlockFromDisk: OpenBlockFile failed for CBlockDiskPos(nFile=-1, nPos=0)

[seasonw]

@seasonw: Check with "getinfo" command if you are getting this error:

Code:

"errors": "Warning: We do not appear to fully agree with our peers! You may need to upgrade, or other nodes may need to upgrade."

Then you may be forked, or at least it looks like it. That's what I see on some of my machines, but I don't know how they got into that state, but maybe it has to do with some banning of connections.

What is also happening is the corruption of blocks locally (wallet won't start). Reindexing doesn't do anything, I have to delete all local data, but after that when I start the wallet, I get a lot of these errors:

Code:

2017-09-11 14:08:47 ERROR: ReadBlockFromDisk: OpenBlockFile failed for CBlockDiskPos(nFile=-1, nPos=0)

I get the error message "Warning: We do not appear to fully agree with our peers!....", but not in getinfo, in getmininginfo instead. But, when I saw this error, I think basically the blockchain in the machine has broken. So, all I did is to delete local .biblepaycore folder, and reload my backup blockchain from block 7030 again.

Why I wanted to use backup blockchain instead of let wallet to load from block 1, because I faced the "ReadBlockFromDisk" problem that you have, and blockchain stucked on a random height.

[bible_pay]

Just so you all know Im reading all the info on the board and formulating a reaction.

The pool still has a minor issue so that needs to be fixed first, but I think within two hours, I will have a reply addressing all the remaining problems.

The plan is to come up with an OPTIONAL patched client to get us through 7256.  I firmly believe the problems will resolve themselves at 7256, but regardless, Im going to patch the problem and release it asap. Dont hold your breath on the win client as that will take 8 more hours to release.

[inblue]

Now I tried to change the IP on one machine to a brand new IP address to see if it makes any difference. I deleted basically everything from the working folder except wallet.dat (I think the main suspect is peers.dat and maybe banlist.dat, but it's also important to delete all blocks which may be from a fork). Then I started clean, but it was at 0 blocks and didn't want to sync. Then I ran:

Code:

addnode "node.biblepay.org" "onetry"

And it started to sync, then it stopped again after about 100 blocks, and I see that I get this error:

Code:

2017-09-11 14:37:14 socket recv error Connection reset by peer (104)

Now here's the kicker. I re-run the addnode command and it will sync about 100 blocks again. Then I run it again. Every time it drops the connection after a few seconds but that way I seem to force the connection again briefly and receive about a 100 blocks in that short time frame. If I type "add" instead of "onetry" in the command, it tells me that the node has already been added and the command wouldn't do anything, only "onetry" works. And then you need to run the command about 70 times and you'll be synced to the top of the correct blockchain, but that doesn't look like it's good for the main node. But if you're only a few dozen blocks away, maybe try that command.

[inblue]

Wallet crash data:

Code:

Error: Error: A fatal internal error occurred, see debug.log for details
biblepayd: /usr/include/boost/thread/pthread/recursive_mutex.hpp:113: void boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.
biblepayd: /usr/include/boost/thread/pthread/recursive_mutex.hpp:113: void boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.

Code:

2017-09-11 15:46:36 ReadBlockFromDisk: Errors in block header at CBlockDiskPos(nFile=0, nPos=2998058)ERROR: CheckProofOfWork(): BibleHash does not meet POW level, prevheight 6934.000000 pindexPrev 00000051caa15dc6e469f3c0051e0801f37e298ff6d370dc6fc8fce7af214648 
2017-09-11 15:46:36 ReadBlockFromDisk: Errors in block header at CBlockDiskPos(nFile=0, nPos=3022608)Shutdown: done

[PhaseshiftUK]

I get the error message "Warning: We do not appear to fully agree with our peers!....", but not in getinfo, in getmininginfo instead. But, when I saw this error, I think basically the blockchain in the machine has broken. So, all I did is to delete local .biblepaycore folder, and reload my backup blockchain from block 7030 again.

Why I wanted to use backup blockchain instead of let wallet to load from block 1, because I faced the "ReadBlockFromDisk" problem that you have, and blockchain stucked on a random height.

Would you be able to package up your backup blockchain as a bootstrap to get some of us running again?

In theory you are supposed to merge two files (as detailed at http://cryptochainer.com/dir/?page_id=154 from "To create your own bootstrap.dat..." onwards), but renaming a copy of blk0001.dat usually works.  Name the file "bootstrap.dat" and if we download it and delete the existing chain (don't delete the wallet!) then copy this in before starting biblepay it should read the chain from that file instead (and renames it to bootstrap.dat.old).

[bible_pay]

I've been debugging this issue this morning, and have come to the conclusion we need to take one step back.  We took two steps forward with F7000, but I think we bit a little too much off at once.

The issue is in the biblehash suffix, in the txid portion in some cases it is not deterministic.

So what I would like to do is fix the problem, send out a mandatory and halt the exchange.

I instructed c-cex to go ahead and put us in maintenance.

Im compiling a mandatory upgrade, 1.0.3.1 now.  For all you linux folks, go ahead and grab it now, and let us pre-test it in prod.
(I just tested in Testnet, and its passing, but my network is too small to ensure this will be 'the final working' version).

Windows is compiling now.

The plan is we go with 1031, re-enable exchanges, burn this in, start a slack team, and then debug the txid suffix issue in testnet.

So basically, we still go live with F7000 - which eliminates X11, but without the txid lookback suffix.  We will debug that suffix in testnet with the new IT team.

[remtiwk]

I'm running it on 3 different windows machines. Let me know if you want me to test the new Windows Client.

[inblue]

I'm still getting "poolinfo3": "HEALTH_DOWN;" on 1.0.3.1, but syncing blocks seems to be working flawlessly.

Scratch that, I am in the future, currently at block 7157 while 7141 is the latest block on 1.0.2.9! So a fork again? Nobody's here, these blocks are found very fast.

[svirusxxx2]

on new version my miner dont working most time (cpu about 1-2%).
Sometimes is going up to 800% (genproclimit=8) ... but after new block appear it stop do anything.

[calxibe]

Where can i download the binaries for the new version? (or is this 1.0.2.9?)

[tiras]

I've been debugging this issue this morning, and have come to the conclusion we need to take one step back.  We took two steps forward with F7000, but I think we bit a little too much off at once.

The issue is in the biblehash suffix, in the txid portion in some cases it is not deterministic.

So what I would like to do is fix the problem, send out a mandatory and halt the exchange.

I instructed c-cex to go ahead and put us in maintenance.

Im compiling a mandatory upgrade, 1.0.3.1 now.  For all you linux folks, go ahead and grab it now, and let us pre-test it in prod.
(I just tested in Testnet, and its passing, but my network is too small to ensure this will be 'the final working' version).

Windows is compiling now.

The plan is we go with 1031, re-enable exchanges, burn this in, start a slack team, and then debug the txid suffix issue in testnet.

So basically, we still go live with F7000 - which eliminates X11, but without the txid lookback suffix.  We will debug that suffix in testnet with the new IT team.

upgraded 2 linux servers.  performance dropped dramatically :

Code:

{
  "blocks": 7155,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 0.1463756203681782,
  "errors": "",
  "genproclimit": 16,
  "networkhashps": 4939467.266461092,
  "hashps": 5884.401841335667,
  "minerstarttime": "09-11-2017 19:08:06",
  "pooledtx": 0,
  "testnet": false,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "B6jtJfhZzbqiNUXfoQ2LdHVjWVtrHSELMS; B6jtJfhZzbqiNUXfoQ2LdHVjWVtrHSELMS; B6jtJfhZzbqiNUXfoQ2LdHVj
WVtrHSELMS; B6jtJfhZzbqiNUXfoQ2LdHVjWVtrHSELMS; B6jtJfhZzbqiNUXfoQ2LdHVjWVtrHSELMS; B6jtJfhZzbqiNUXfoQ2LdHVjWVtr
HSELMS; B6jtJfhZzbqiNUXfoQ2LdHVjWVtrHSELMS; B6jtJfhZzbqiNUXfoQ2LdHVjWVtrHSELMS; B6jtJfhZzbqiNUXfoQ2LdHVjWVtrHSEL
MS; B6jtJfhZzbqiNUXfoQ2LdHVjWVtrHSELMS; B6jtJfhZzbqiNUXfoQ2LdHVjWVtrHSELMS; B6jtJfhZzbqiNUXfoQ2LdHVjWVtrHSELMS; 
B6jtJfhZzbqiNUXfoQ2LdHVjWVtrHSELMS; B6jtJfhZzbqiNUXfoQ2LdHVjWVtrHSELMS; ",
  "poolinfo2": "Submitting Solution 09-11-2017 19:25:02; RM_09-11-2017 19:22:54; RM_09-11-2017 19:21:43; Submitt
ing Solution 09-11-2017 19:25:07; RM_09-11-2017 19:21:54; RMC_09-11-2017 19:19:22; RM_09-11-2017 19:27:08; RMC_0
9-11-2017 19:25:03; Submitting Solution 09-11-2017 19:22:09; Submitting Solution 09-11-2017 19:22:03; RMC_09-11-
2017 19:25:03; RM_09-11-2017 19:22:06; Submitting Solution 09-11-2017 19:22:56; RMC_09-11-2017 19:25:03; Submitt
ing Solution 09-11-2017 19:22:04; ",
  "poolinfo3": "HEALTH_DOWN; CFW 09-11-2017 19:27:11; HEALTH_DOWN; CFW 09-11-2017 19:28:03; HEALTH_DOWN; CFW 09-
11-2017 19:21:52; HEALTH_DOWN; HEALTH_DOWN; HEALTH_DOWN; HEALTH_DOWN; HEALTH_DOWN; CFW 09-11-2017 19:28:22; HEAL
TH_DOWN; HEALTH_DOWN; HEALTH_DOWN; ",
  "miningpulse": 227,
  "poolmining": true
}

Hashes Per Second       Hashes Per Second2       Shares       Reported
14900.36   4365.44   1   9/11/2017 2:05:42 PM

[inblue]

@tiras: You are ahead of time, check your latest block. I am on 7165 now, so different fork lol. Also, I think those machines you upgraded are now not hitting the pool anymore, check it. My 1.0.3.1 instances are not hitting the pool, and 1.0.2.9 are.