All,
The windows version of 1.0.3.1 has just been released.
(Someone asked about the cutover height. I left the height as-is at 7000 while we check to see if our checkblock errors are alleviated). If this fixes the problem, the chain will roll back to the highest block with the most work that satisfies the bible hash after 7000.
Please upgrade from :
www.biblepay.org
Topic: BiblePay - New Coin Launch - Official Thread - page 91. (Read 119850 times)
@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.
@inblue , yes, my both upgraded servers are not hitting the pool too atm and there was no credit @ 1:53:01 PM :
MINING_CREDIT 7220f5c6-c983-4d70-a4ba-42279bf3fd8d 0.0000 33028.5011 9/11/2017 1:53:01 PM 7143
Meanwhile, pool gave everyone 0 credit for block 7143.
I'am too not sure
now I have my 10 computers upgraded to new version and one server.
my main node is open
I can't connect to node.biblepay.org :/
now I have my 10 computers upgraded to new version and one server.
my main node is open
Code:
addnode "vrs2.hostv.pl" "onetry"
I can't connect to node.biblepay.org :/
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.
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.
How does that new mandatory work? Does it get activated after a certain block height? I just upgraded to 1.0.3.1 but I'm not sure if I'm on the right chain or not.
@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.
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.
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"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
}
14900.36 4365.44 1 9/11/2017 2:05:42 PM
Where can i download the binaries for the new version? (or is this 1.0.2.9?)
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.
Sometimes is going up to 800% (genproclimit=8) ... but after new block appear it stop do anything.
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.
I'm running it on 3 different windows machines. Let me know if you want me to test the new Windows Client.
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.
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.
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.
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).
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.
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
2017-09-11 15:46:36 ReadBlockFromDisk: Errors in block header at CBlockDiskPos(nFile=0, nPos=3022608)Shutdown: done
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:
And it started to sync, then it stopped again after about 100 blocks, and I see that I get this error:
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.
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.
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.
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.
@seasonw: Check with "getinfo" command if you are getting this error:
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:
"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.
@seasonw: Check with "getinfo" command if you are getting this error:
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:
"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 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.
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.
Jump to: