[ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin"

[dooglus]

Net results for me...
It works great until block 1781476.  It then runs into an error.
If I had to guess though, I would say this is when the client hits a kind of 2GB windows file limit, an error is flagged and the client then goes into syncing mode instead of importing blocks from the bootstrap.

It could be an issue with 2GB filesize limit I guess, or a signed 32 bit variable in the code perhaps. 2^31 = 2147483648.

I would suggest putting "connect=0" in the clam.conf to stop the client ever going to "live sync".

[Enzo05]

Net results for me...
It works great until block 1781476.  It then runs into an error.
If I had to guess though, I would say this is when the client hits a kind of 2GB windows file limit, an error is flagged and the client then goes into syncing mode instead of importing blocks from the bootstrap.

It could be an issue with 2GB filesize limit I guess, or a signed 32 bit variable in the code perhaps. 2^31 = 2147483648.

I would suggest putting "connect=0" in the clam.conf to stop the client ever going to "live sync".

Hello ! I also have the same issue and supposed to go 2M blocks but I am stack at 1.85 M blocks and its not importing anymore . Where can I find this ( calm.conf ) ?

[dooglus]

Where can I find this ( calm.conf ) ?

clam.conf is a file in the same folder as your wallet.dat. You make it yourself - it's a regular text file.

[dooglus]

It could be an issue with 2GB filesize limit I guess, or a signed 32 bit variable in the code perhaps. 2^31 = 2147483648.

I see a problem when the bootstrap.dat reaches 4 GB, due to the use of an unsigned int, but don't see a 2 GB limit yet:

https://github.com/nochowderforyou/clams/blob/v1.4.17/src/main.cpp#L2870

Code:

unsigned int nPos = 0;
[...]
fseek(blkdat, nPos, SEEK_SET);

Edit: I tried making a bootstrap.dat file which started with 4000 MB of zero bytes and then had the regular block data. The client quickly skipped the first 4000 MB and started complaining:

2018-05-18 12:16:03 ERROR: ProcessBlock() : already have block 0 00000c3ce6b3d823a35224a39798eca9ad889966aeb5a9da7b960ffb9869db35
2018-05-18 12:16:03 ERROR: ProcessBlock() : already have block 1 00000feca63cbde350712358668e0fe90e96c97efab3f0ff5fd9f3147dd2f53e
2018-05-18 12:16:03 ERROR: ProcessBlock() : already have block 2 0000042f7f9811948352d2ecc9215916f2276a5259ca4cdc4ccfb77a72ed8ebc

as expected. But then, after 96 MB of block data it wrapped around:

2018-05-18 12:16:10 ERROR: ProcessBlock() : already have block 8571 000006ff5c3a5829e0da80d9afb609435e887c51123f5afeb5f6afe5da819423
2018-05-18 12:16:10 ERROR: ProcessBlock() : already have block 8572 0000022cc43c5975e8ec01d978179b1fa3b26e9fad73aa2306c85f82854fad35
2018-05-18 12:16:10 ERROR: ProcessBlock() : already have block 8573 00000574ef1a20a79eb9c3525ed69af881e778f2100559d340fbc06ca1252240
2018-05-18 12:16:10 ERROR: ProcessBlock() : already have block 0 00000c3ce6b3d823a35224a39798eca9ad889966aeb5a9da7b960ffb9869db35
2018-05-18 12:16:10 ERROR: ProcessBlock() : already have block 1 00000feca63cbde350712358668e0fe90e96c97efab3f0ff5fd9f3147dd2f53e
2018-05-18 12:16:10 ERROR: ProcessBlock() : already have block 2 0000042f7f9811948352d2ecc9215916f2276a5259ca4cdc4ccfb77a72ed8ebc

So that's the 4 GB bug, but we won't be seeing that yet.

I tried putting 2100 MB of zero bytes before the bootstrap data and it seemed to be able to skip the >2 GB of junk just fine. So I don't know what the problem is yet.

My import that I started earlier is still running. I'll leave it running and see whether it eventually fails or not.

[criptocambio]

Sir I am already done with bootstrap and it makes my wallet sync fast by " importing files " now it's back to "synchronizing with the network and it takes a day now and it is so slow . I thought  bootstrap can go up to 2M blocks now it is just 1.8 M blocks ( approx 19 weeks behind ) is this correct or is there another patch I need to download ?

Well, it's basically the issue being reported.

The client only imports blocks to a certain point and then goes to sync with network.  It's either a 2GB file limit for the error or the public bootstrap is broken.
In any case, I've also encountered that the client keeps stopping and has to be restarted, but no indication on the UI.  Only that the bkl0002 stops changing in size.

I've been trying for 2 days now with no less than 20 restarts.
At block 1853826 now.... 18 weeks behind.

The restarts are needed to remove the orphan blocks that are currently in memory, hardcoded to 99 in earlier versions of bitcoin if i remember correctly. To avoid this, try

Code:

maxorphanblocks=<high number here>

in clam.conf

[dooglus]

The restarts are needed to remove the orphan blocks that are currently in memory, hardcoded to 99 in earlier versions of bitcoin if i remember correctly. To avoid this, try

Code:

maxorphanblocks=<high number here>

in clam.conf

We're talking about importing from a bootstrap.dat file. Bootstrap files don't contain orphans, and no network connections are made until the bootstrap.dat import finishes.

[criptocambio]

The restarts are needed to remove the orphan blocks that are currently in memory, hardcoded to 99 in earlier versions of bitcoin if i remember correctly. To avoid this, try

Code:

maxorphanblocks=<high number here>

in clam.conf

We're talking about importing from a bootstrap.dat file. Bootstrap files don't contain orphans, and no network connections are made until the bootstrap.dat import finishes.

Right, but the use of this config makes the process of syncing a lot faster without the need for a bootstrap as he is only 18 weeks behind. Maybe in the new version this problem with the bootstrap file is corrected, but until there they need to sync as fast as possible.

Talking about bootstrap, what version of windows did you try? I think windows limits memory usage for each process to 2gb in the 32 bits version, maybe this have any correlation

https://en.wikipedia.org/wiki/2_GB_limit

[dooglus]

Talking about bootstrap, what version of windows did you try?

I don't use Windows and haven't for many years. I think the last version I used was XP.

[Enzo05]

Where can I find this ( calm.conf ) ?

clam.conf is a file in the same folder as your wallet.dat. You make it yourself - it's a regular text file.

Sir I am already done with bootstrap and it makes my wallet sync fast by " importing files " now it's back to "synchronizing with the network and it takes a day now and it is so slow . I thought  bootstrap can go up to 2M blocks now it is just 1.8 M blocks ( approx 19 weeks behind ) is this correct or is there another patch I need to download ?

Well, it's basically the issue being reported.

The client only imports blocks to a certain point and then goes to sync with network.  It's either a 2GB file limit for the error or the public bootstrap is broken.
In any case, I've also encountered that the client keeps stopping and has to be restarted, but no indication on the UI.  Only that the bkl0002 stops changing in size.

I've been trying for 2 days now with no less than 20 restarts.
At block 1853826 now.... 18 weeks behind.

The restarts are needed to remove the orphan blocks that are currently in memory, hardcoded to 99 in earlier versions of bitcoin if i remember correctly. To avoid this, try

Code:

maxorphanblocks=<high number here>

in clam.conf

Thanks but I do not think I need to this since I am able to see my clam client is already at 1970000 blocks which is 6 weeks behind and still counting . Is it necessary to do those things you mentioned or I am good to go ?

[criptocambio]

Where can I find this ( calm.conf ) ?

clam.conf is a file in the same folder as your wallet.dat. You make it yourself - it's a regular text file.

Sir I am already done with bootstrap and it makes my wallet sync fast by " importing files " now it's back to "synchronizing with the network and it takes a day now and it is so slow . I thought  bootstrap can go up to 2M blocks now it is just 1.8 M blocks ( approx 19 weeks behind ) is this correct or is there another patch I need to download ?

Well, it's basically the issue being reported.

The client only imports blocks to a certain point and then goes to sync with network.  It's either a 2GB file limit for the error or the public bootstrap is broken.
In any case, I've also encountered that the client keeps stopping and has to be restarted, but no indication on the UI.  Only that the bkl0002 stops changing in size.

I've been trying for 2 days now with no less than 20 restarts.
At block 1853826 now.... 18 weeks behind.

The restarts are needed to remove the orphan blocks that are currently in memory, hardcoded to 99 in earlier versions of bitcoin if i remember correctly. To avoid this, try

Code:

maxorphanblocks=<high number here>

in clam.conf

Thanks but I do not think I need to this since I am able to see my clam client is already at 1970000 blocks which is 6 weeks behind and still counting . Is it necessary to do those things you mentioned or I am good to go ?

Only if you have problems syncing, i think. I use 400 during sync, but remove it completely from config file after that, and it keeps synced without any issues

[Enzo05]

Where can I find this ( calm.conf ) ?

clam.conf is a file in the same folder as your wallet.dat. You make it yourself - it's a regular text file.

Sir I am already done with bootstrap and it makes my wallet sync fast by " importing files " now it's back to "synchronizing with the network and it takes a day now and it is so slow . I thought  bootstrap can go up to 2M blocks now it is just 1.8 M blocks ( approx 19 weeks behind ) is this correct or is there another patch I need to download ?

Well, it's basically the issue being reported.

The client only imports blocks to a certain point and then goes to sync with network.  It's either a 2GB file limit for the error or the public bootstrap is broken.
In any case, I've also encountered that the client keeps stopping and has to be restarted, but no indication on the UI.  Only that the bkl0002 stops changing in size.

I've been trying for 2 days now with no less than 20 restarts.
At block 1853826 now.... 18 weeks behind.

The restarts are needed to remove the orphan blocks that are currently in memory, hardcoded to 99 in earlier versions of bitcoin if i remember correctly. To avoid this, try

Code:

maxorphanblocks=<high number here>

in clam.conf

Thanks but I do not think I need to this since I am able to see my clam client is already at 1970000 blocks which is 6 weeks behind and still counting . Is it necessary to do those things you mentioned or I am good to go ?

Only if you have problems syncing, i think. I use 400 during sync, but remove it completely from config file after that, and it keeps synced without any issues

Apparently I am near to finished it so I guess I do not need to do anything since I'm almost done . It is already @ 2M blocks 3 weeks behind . Yeheey!!! 

[dooglus]

Apparently I am near to finished it so I guess I do not need to do anything since I'm almost done . It is already @ 2M blocks 3 weeks behind . Yeheey!!!  

Yes, so long as it's syncing fast enough for you you don't need the bootstrap.dat file.

My client is still importing the bootstrap.dat I gave it about 24 hours ago. It's at block 1954760 at the moment, which these blk* file sizes:

-rw------- 1 user user 2097155946 May 18 20:10 blk0001.dat
-rw------- 1 user user  304629563 May 19 01:18 blk0002.dat

The sha256 for the first file:

510d0cabb4208d9a545a0e05fab2c0c29c225d699e0601a16b2891facbd2ce98  blk0001.dat

Will report back when the import crashes or finishes.

Edit: it finished:

2018-05-19 03:43:53 ProcessBlock: ACCEPTED
2018-05-19 03:43:53 SetBestChain: new best=fac44401cb18358bb21f44fac9054194b44c610f3c56296e5bdb6eb7c8e2f3fc  height=2027899  trust=678497555062587320383  blocktrust=428714885044844  date=05/12/18 01:36:00
2018-05-19 03:43:53 ProcessBlock: ACCEPTED
2018-05-19 03:43:53 SetBestChain: new best=f09e869c172819e3a57cf7b6e9bf7d30a8278437e46a4404fbbdde3e6fc027e9  height=2027900  trust=678497983558384619095  blocktrust=428495797298712  date=05/12/18 01:37:52
2018-05-19 03:43:53 ProcessBlock: ACCEPTED
2018-05-19 03:43:53 Loaded 73140 blocks from external file in 8423188ms

That's all the blocks:

I made an updated bootstrap.dat file for people having trouble syncing their client.

It goes up to block 2027900 which was staked on Sat May 12 01:37:52 UTC 2018.

I don't know why some people are having trouble importing my bootstrap.dat file. Maybe it doesn't work on Windows? Did anyone try on a proper OS?

[gjhiggins]

I don't know why some people are having trouble importing my bootstrap.dat file. ... Did anyone try on a proper OS?

I will try that with a fresh compilation of master on Ubuntu 17.10 (assuming for the sake of argument that it broadly qualifies as a proper OS)

Cheers

Graham

[dooglus]

I don't know why some people are having trouble importing my bootstrap.dat file. ... Did anyone try on a proper OS?

I will try that with a fresh compilation of master on Ubuntu 17.10 (assuming for the sake of argument that it broadly qualifies as a proper OS)

It's close enough...

I just noticed that the sum of the sizes of my blk* files is *exacly* the size of the bootstrap.dat I imported:


-rw------- 1 user user 2097155946 May 18 20:10 blk0001.dat
-rw------- 1 user user  467920500 May 19 03:43 blk0002.dat
-rw-rw-r-- 1 user user 2565076446 May 18 00:08 bootstrap.dat.old


I still have "connect=0" in the clam.conf, so it hasn't had a chance to find any blocks newer than the ones in the bootstrap.

Edit: it turns out the two blk files put end to end are identical to the bootstrap file:


~/.clam$ head -c 2097155946 bootstrap* | sha256sum
510d0cabb4208d9a545a0e05fab2c0c29c225d699e0601a16b2891facbd2ce98  -
~/.clam$ sha256sum blk*1*
510d0cabb4208d9a545a0e05fab2c0c29c225d699e0601a16b2891facbd2ce98  blk0001.dat
~/.clam$ tail -c 467920500 bootstrap* | sha256sum
a2d30d536d57eab41d930e2f8d753e60d4af83c1d1fe5dad6c7f5c39475b3d42  -
~/.clam$ sha256sum blk*2*
a2d30d536d57eab41d930e2f8d753e60d4af83c1d1fe5dad6c7f5c39475b3d42  blk0002.dat

[Enzo05]

I have a new concern now I can do staking but the thing is it says " Expected time to earn reward is 116 days " then sometimes it says 140 days what I mean its changing and even it doesn't go below 100 days . Can you guys enlighten me how staking is working here in clam client ? what are things I should  know ? Thanks for those who will answer .

[Michail1]

Net results for me...
It works great until block 1781476.  It then runs into an error.
If I had to guess though, I would say this is when the client hits a kind of 2GB windows file limit, an error is flagged and the client then goes into syncing mode instead of importing blocks from the bootstrap.

It could be an issue with 2GB filesize limit I guess, or a signed 32 bit variable in the code perhaps. 2^31 = 2147483648.

I would suggest putting "connect=0" in the clam.conf to stop the client ever going to "live sync".

I eventually synced.   Since I don't use the wallet, I will try a couple of tests.

First, I am using:   v1.4.17

Looking in logs, I see the client reaches 751 Orphan blocks.  It gets a bunch more, but each one is numbered 751.   Basically locks up.

I see others have taken the advice of connect=0      I will run that tonight just as another test / confirmation that it may resolve the issue.  Of course, a client update would be needed to make no connections while it is importing blocks.

[criptocambio]

Since bootstrapping and syncing are really an annoyance right now, is there any chance to make a checkpoint block with all the balances in the non-empty wallets inside the client and start from there in new releases? It wont have any transactions before that, but it can sync the blocks after the checkpoint block faster and enable the person to do transactions, and do the syncing of older blocks after that without hurry

[zazarb]

Finally my wallet synced
But helped only  method, when multiple time I closed client, and after change bootstrap.old to bootstrap , run wallet again.(repeated process 5-8 time per day)

[Michail1]

I eventually synced.   Since I don't use the wallet, I will try a couple of tests.

First, I am using:   v1.4.17

Looking in logs, I see the client reaches 751 Orphan blocks.  It gets a bunch more, but each one is numbered 751.   Basically locks up.

I see others have taken the advice of connect=0      I will run that tonight just as another test / confirmation that it may resolve the issue.  Of course, a client update would be needed to make no connections while it is importing blocks.

Well, again, it stopped automatically for me at block 1775693

bootstrap.dat 2.38 GB (2,565,076,446 bytes) sha256 713B93B7458E88500F1E32557F0BC58B9F05A6B13E1DE31576F25F5300184C96
blk0001.dat   1.95 GB (2,097,155,946 bytes) sha256 510D0CABB4208D9A545A0E05FAB2C0C29C225D699E0601A16B2891FACBD2CE98
blk0002.dat   40.1 MB (   42,074,112 bytes) sha256 4E0425F4E1244A86167460031043C0247B09F5EAEBA6E1BCB4136A91EE0A2394

Here is the snippet from the debug log.

SetBestChain: new best=33282ccb31e0242458ea8cf426cfb05714753604b37c413a8e95486ca81c7191  height=1775690  trust=567448766874838286320  blocktrust=509240947264508  date=11/16/17 09:02:08
ProcessBlock: ACCEPTED
SetBestChain: new best=81963d01eb963e0bc0f323c5252c67eee91c851e6bdc0552ef3ba5877b1bd9f7  height=1775691  trust=567449274043651486296  blocktrust=507168813199976  date=11/16/17 09:03:44
ProcessBlock: ACCEPTED
SetBestChain: new best=4787753ea648205e9f413cea6001eabf92614869318f469a2733bb016f9a1f5c  height=1775692  trust=567449778894470438909  blocktrust=504850818952613  date=11/16/17 09:05:20
ProcessBlock: ACCEPTED
SetBestChain: new best=64aded1cfe3679857107151e22caa8043908fec2229a2e16b9a7046e0985ca23  height=1775693  trust=567450280914992243496  blocktrust=502020521804587  date=11/16/17 09:06:08
ProcessBlock: ACCEPTED
ERROR: CTransaction::ReadFromDisk() : OpenBlockFile failed
ERROR: FetchInputs() : 6d855febfba9794f14995f90993a2c56444a4c7c5ec561030f983c657dc36492 ReadFromDisk prev tx 31cea8afbee32d452f52028ef310b51c749bbaaffd9ecd3df442b6898b4b641a failed
InvalidChainFound: invalid block=fb790923aa509ff87a97287afd0639efa4763023fb6a7f42691837400f949b77  height=1775694  trust=567450780123264426586  blocktrust=499208272183090  date=11/16/17 09:06:56
InvalidChainFound:  current best=64aded1cfe3679857107151e22caa8043908fec2229a2e16b9a7046e0985ca23  height=1775693  trust=567450280914992243496  blocktrust=502020521804587  date=11/16/17 09:06:08
ERROR: SetBestChain() : SetBestChainInner failed
ERROR: AcceptBlock() : AddToBlockIndex failed
ERROR: ProcessBlock() : AcceptBlock FAILED
ERROR: CTransaction::ReadFromDisk() : OpenBlockFile failed
ERROR: CheckProofOfStake() : INFO: read txPrev failed
ProcessBlock: ORPHAN BLOCK 0, prev=5cc7e18e8e8d3a4d11beac2117869739f2185177262e8fb221baede214ebc0df
ProcessBlock: ORPHAN BLOCK 0, prev=e24425383f3707c7f3b23e90d720e4883a98aeca0c1a3777e317efc9539c81ab
ProcessBlock: ORPHAN BLOCK 0, prev=9109b5f5ed6bc67b4669e3d24823e42bf881b3772bf7a9b53ade463a9be95666
ProcessBlock: ORPHAN BLOCK 0, prev=91afe77917861bf006e7ee797fecbb944dd18ae43ceb0c000674c996de88ffbc
ProcessBlock: ORPHAN BLOCK 0, prev=f15bb5e8275a215b1921865dcc16e64aed9af05cdf6166c8dce7210b4f9ee70d
ProcessBlock: ORPHAN BLOCK 0, prev=f5ef33223365fa4cdfc51d8c3c11340b23f7da3f4d5cdb3facd06f5fc008aaf3
ProcessBlock: ORPHAN BLOCK 0, prev=2a576b57412f46383262a66a7ff966626830b9f6aab3d221e55106489d74cbd7
.
.
.

Although orphan stays at block 0, no more bestchains appear to have loaded.  In the end, I see....

ProcessBlock: ORPHAN BLOCK 0, prev=166705ff3f78aeda9251ad3bc79bca5c88f461539987dff0747a0062d885de56
ProcessBlock: ORPHAN BLOCK 0, prev=79241ea0703cebdea6a4a766dfdacea7f23319327034a8db346d0ff95f68e758
ProcessBlock: ORPHAN BLOCK 0, prev=4a398a03270b98afa5e0ba0f9d643533b78b708c7a8fd536144cc6fc72684b65
ProcessBlock: ORPHAN BLOCK 0, prev=b18c076bb4e687d959932c85766f0099592f1e4f1995f98d55bc63aa90f23c68
ProcessBlock: ORPHAN BLOCK 0, prev=bb831330ced8366b7095c5a71267b8cd3ef5ef5078ee00aea57fcbde79d21732
ProcessBlock: ORPHAN BLOCK 0, prev=eb4205fb93f5e6c6aeacbff987564f3ec4e1488a6e0c57a000299ab3625741d9
bool LoadExternalBlockFile(FILE*)() : Deserialize or I/O error caught during load
Loaded 1781474 blocks from external file in 42731538ms
dumpaddr thread stop
addcon thread interrupt
net thread interrupt
msghand thread interrupt
opencon thread interrupt
Shutdown : In progress...
StopNode()
Shutdown : done

So, I made a backup of the debug.log file at this point, renamed the bootstrap.dat.old back and restarted.


Appears to be running like it should......

ERROR: ProcessBlock() : already have block 1775690 33282ccb31e0242458ea8cf426cfb05714753604b37c413a8e95486ca81c7191
ERROR: ProcessBlock() : already have block 1775691 81963d01eb963e0bc0f323c5252c67eee91c851e6bdc0552ef3ba5877b1bd9f7
ERROR: ProcessBlock() : already have block 1775692 4787753ea648205e9f413cea6001eabf92614869318f469a2733bb016f9a1f5c
ERROR: ProcessBlock() : already have block 1775693 64aded1cfe3679857107151e22caa8043908fec2229a2e16b9a7046e0985ca23
ERROR: ProcessBlock() : already have block 1775694 fb790923aa509ff87a97287afd0639efa4763023fb6a7f42691837400f949b77
Postponing 1 reconnects
REORGANIZE
REORGANIZE: Disconnect 0 blocks; 64aded1cfe3679857107151e22caa8043908fec2229a2e16b9a7046e0985ca23..64aded1cfe367 9857107151e22caa8043908fec2229a2e16b9a7046e0985ca23
REORGANIZE: Connect 1 blocks; 64aded1cfe3679857107151e22caa8043908fec2229a2e16b9a7046e0985ca23..fb790923aa509 ff87a97287afd0639efa4763023fb6a7f42691837400f949b77
REORGANIZE: done
SetBestChain: new best=5cc7e18e8e8d3a4d11beac2117869739f2185177262e8fb221baede214ebc0df  height=1775695  trust=567451276791207500535  blocktrust=496667943073949  date=11/16/17 09:07:28
ProcessBlock: ACCEPTED
SetBestChain: new best=e24425383f3707c7f3b23e90d720e4883a98aeca0c1a3777e317efc9539c81ab  height=1775696  trust=567451770931307516863  blocktrust=494140100016328  date=11/16/17 09:07:44
ProcessBlock: ACCEPTED
SetBestChain: new best=9109b5f5ed6bc67b4669e3d24823e42bf881b3772bf7a9b53ade463a9be95666  height=1775697  trust=567452262805132909752  blocktrust=491873825392889  date=11/16/17 09:08:16
.
.
.
.
.

Annnnnddddd, it fails again.

SetBestChain: new best=b18c076bb4e687d959932c85766f0099592f1e4f1995f98d55bc63aa90f23c68  height=1781473  trust=569912537987922081905  blocktrust=490474450244869  date=11/20/17 10:10:56
ProcessBlock: ACCEPTED
SetBestChain: new best=bb831330ced8366b7095c5a71267b8cd3ef5ef5078ee00aea57fcbde79d21732  height=1781474  trust=569913028971501803220  blocktrust=490983579721315  date=11/20/17 10:12:16
ProcessBlock: ACCEPTED
SetBestChain: new best=eb4205fb93f5e6c6aeacbff987564f3ec4e1488a6e0c57a000299ab3625741d9  height=1781475  trust=569913520714206297916  blocktrust=491742704494696  date=11/20/17 10:14:24
ProcessBlock: ACCEPTED
SetBestChain: new best=0def539c364181bb509653a291a50783b49d79aa1cf79fc1e4377c963413e1b2  height=1781476  trust=569914012968678030572  blocktrust=492254471732656  date=11/20/17 10:16:00
ProcessBlock: ACCEPTED
bool LoadExternalBlockFile(FILE*)() : Deserialize or I/O error caught during load
Loaded 5782 blocks from external file in 976515ms

This was a key block number in my prior setup days ago during my posts.   Something is definately wrong.  I could understand the random getting disconnected as maybe internet went down; however, at key block numbers is too coincidental.   This is definately AFTER the 2GB blk file is created.

So, my file is now....
blk0002.dat   47.9 MB (   50,328,045 bytes) sha256 ABFE04484E56047C449E7BB983BF4AFA056195DB623999FFA1955AC697ED6557  at 1781476


Clam version v1.4.17 (2015-09-23 21:07:15 -0300)
Using OpenSSL version OpenSSL 1.0.1j 15 Oct 2014

[criptocambio]

I eventually synced.   Since I don't use the wallet, I will try a couple of tests.

First, I am using:   v1.4.17

Looking in logs, I see the client reaches 751 Orphan blocks.  It gets a bunch more, but each one is numbered 751.   Basically locks up.

I see others have taken the advice of connect=0      I will run that tonight just as another test / confirmation that it may resolve the issue.  Of course, a client update would be needed to make no connections while it is importing blocks.

Well, again, it stopped automatically for me at block 1775693

bootstrap.dat 2.38 GB (2,565,076,446 bytes) sha256 713B93B7458E88500F1E32557F0BC58B9F05A6B13E1DE31576F25F5300184C96
blk0001.dat   1.95 GB (2,097,155,946 bytes) sha256 510D0CABB4208D9A545A0E05FAB2C0C29C225D699E0601A16B2891FACBD2CE98
blk0002.dat   40.1 MB (   42,074,112 bytes) sha256 4E0425F4E1244A86167460031043C0247B09F5EAEBA6E1BCB4136A91EE0A2394

Here is the snippet from the debug log.

SetBestChain: new best=33282ccb31e0242458ea8cf426cfb05714753604b37c413a8e95486ca81c7191  height=1775690  trust=567448766874838286320  blocktrust=509240947264508  date=11/16/17 09:02:08
ProcessBlock: ACCEPTED
SetBestChain: new best=81963d01eb963e0bc0f323c5252c67eee91c851e6bdc0552ef3ba5877b1bd9f7  height=1775691  trust=567449274043651486296  blocktrust=507168813199976  date=11/16/17 09:03:44
ProcessBlock: ACCEPTED
SetBestChain: new best=4787753ea648205e9f413cea6001eabf92614869318f469a2733bb016f9a1f5c  height=1775692  trust=567449778894470438909  blocktrust=504850818952613  date=11/16/17 09:05:20
ProcessBlock: ACCEPTED
SetBestChain: new best=64aded1cfe3679857107151e22caa8043908fec2229a2e16b9a7046e0985ca23  height=1775693  trust=567450280914992243496  blocktrust=502020521804587  date=11/16/17 09:06:08
ProcessBlock: ACCEPTED
ERROR: CTransaction::ReadFromDisk() : OpenBlockFile failed
ERROR: FetchInputs() : 6d855febfba9794f14995f90993a2c56444a4c7c5ec561030f983c657dc36492 ReadFromDisk prev tx 31cea8afbee32d452f52028ef310b51c749bbaaffd9ecd3df442b6898b4b641a failed
InvalidChainFound: invalid block=fb790923aa509ff87a97287afd0639efa4763023fb6a7f42691837400f949b77  height=1775694  trust=567450780123264426586  blocktrust=499208272183090  date=11/16/17 09:06:56
InvalidChainFound:  current best=64aded1cfe3679857107151e22caa8043908fec2229a2e16b9a7046e0985ca23  height=1775693  trust=567450280914992243496  blocktrust=502020521804587  date=11/16/17 09:06:08
ERROR: SetBestChain() : SetBestChainInner failed
ERROR: AcceptBlock() : AddToBlockIndex failed
ERROR: ProcessBlock() : AcceptBlock FAILED
ERROR: CTransaction::ReadFromDisk() : OpenBlockFile failed
ERROR: CheckProofOfStake() : INFO: read txPrev failed
ProcessBlock: ORPHAN BLOCK 0, prev=5cc7e18e8e8d3a4d11beac2117869739f2185177262e8fb221baede214ebc0df
ProcessBlock: ORPHAN BLOCK 0, prev=e24425383f3707c7f3b23e90d720e4883a98aeca0c1a3777e317efc9539c81ab
ProcessBlock: ORPHAN BLOCK 0, prev=9109b5f5ed6bc67b4669e3d24823e42bf881b3772bf7a9b53ade463a9be95666
ProcessBlock: ORPHAN BLOCK 0, prev=91afe77917861bf006e7ee797fecbb944dd18ae43ceb0c000674c996de88ffbc
ProcessBlock: ORPHAN BLOCK 0, prev=f15bb5e8275a215b1921865dcc16e64aed9af05cdf6166c8dce7210b4f9ee70d
ProcessBlock: ORPHAN BLOCK 0, prev=f5ef33223365fa4cdfc51d8c3c11340b23f7da3f4d5cdb3facd06f5fc008aaf3
ProcessBlock: ORPHAN BLOCK 0, prev=2a576b57412f46383262a66a7ff966626830b9f6aab3d221e55106489d74cbd7
.
.
.

Although orphan stays at block 0, no more bestchains appear to have loaded.  In the end, I see....

ProcessBlock: ORPHAN BLOCK 0, prev=166705ff3f78aeda9251ad3bc79bca5c88f461539987dff0747a0062d885de56
ProcessBlock: ORPHAN BLOCK 0, prev=79241ea0703cebdea6a4a766dfdacea7f23319327034a8db346d0ff95f68e758
ProcessBlock: ORPHAN BLOCK 0, prev=4a398a03270b98afa5e0ba0f9d643533b78b708c7a8fd536144cc6fc72684b65
ProcessBlock: ORPHAN BLOCK 0, prev=b18c076bb4e687d959932c85766f0099592f1e4f1995f98d55bc63aa90f23c68
ProcessBlock: ORPHAN BLOCK 0, prev=bb831330ced8366b7095c5a71267b8cd3ef5ef5078ee00aea57fcbde79d21732
ProcessBlock: ORPHAN BLOCK 0, prev=eb4205fb93f5e6c6aeacbff987564f3ec4e1488a6e0c57a000299ab3625741d9
bool LoadExternalBlockFile(FILE*)() : Deserialize or I/O error caught during load
Loaded 1781474 blocks from external file in 42731538ms
dumpaddr thread stop
addcon thread interrupt
net thread interrupt
msghand thread interrupt
opencon thread interrupt
Shutdown : In progress...
StopNode()
Shutdown : done

So, I made a backup of the debug.log file at this point, renamed the bootstrap.dat.old back and restarted.


Appears to be running like it should......

ERROR: ProcessBlock() : already have block 1775690 33282ccb31e0242458ea8cf426cfb05714753604b37c413a8e95486ca81c7191
ERROR: ProcessBlock() : already have block 1775691 81963d01eb963e0bc0f323c5252c67eee91c851e6bdc0552ef3ba5877b1bd9f7
ERROR: ProcessBlock() : already have block 1775692 4787753ea648205e9f413cea6001eabf92614869318f469a2733bb016f9a1f5c
ERROR: ProcessBlock() : already have block 1775693 64aded1cfe3679857107151e22caa8043908fec2229a2e16b9a7046e0985ca23
ERROR: ProcessBlock() : already have block 1775694 fb790923aa509ff87a97287afd0639efa4763023fb6a7f42691837400f949b77
Postponing 1 reconnects
REORGANIZE
REORGANIZE: Disconnect 0 blocks; 64aded1cfe3679857107151e22caa8043908fec2229a2e16b9a7046e0985ca23..64aded1cfe367 9857107151e22caa8043908fec2229a2e16b9a7046e0985ca23
REORGANIZE: Connect 1 blocks; 64aded1cfe3679857107151e22caa8043908fec2229a2e16b9a7046e0985ca23..fb790923aa509 ff87a97287afd0639efa4763023fb6a7f42691837400f949b77
REORGANIZE: done
SetBestChain: new best=5cc7e18e8e8d3a4d11beac2117869739f2185177262e8fb221baede214ebc0df  height=1775695  trust=567451276791207500535  blocktrust=496667943073949  date=11/16/17 09:07:28
ProcessBlock: ACCEPTED
SetBestChain: new best=e24425383f3707c7f3b23e90d720e4883a98aeca0c1a3777e317efc9539c81ab  height=1775696  trust=567451770931307516863  blocktrust=494140100016328  date=11/16/17 09:07:44
ProcessBlock: ACCEPTED
SetBestChain: new best=9109b5f5ed6bc67b4669e3d24823e42bf881b3772bf7a9b53ade463a9be95666  height=1775697  trust=567452262805132909752  blocktrust=491873825392889  date=11/16/17 09:08:16
.
.
.
.
.

Annnnnddddd, it fails again.

SetBestChain: new best=b18c076bb4e687d959932c85766f0099592f1e4f1995f98d55bc63aa90f23c68  height=1781473  trust=569912537987922081905  blocktrust=490474450244869  date=11/20/17 10:10:56
ProcessBlock: ACCEPTED
SetBestChain: new best=bb831330ced8366b7095c5a71267b8cd3ef5ef5078ee00aea57fcbde79d21732  height=1781474  trust=569913028971501803220  blocktrust=490983579721315  date=11/20/17 10:12:16
ProcessBlock: ACCEPTED
SetBestChain: new best=eb4205fb93f5e6c6aeacbff987564f3ec4e1488a6e0c57a000299ab3625741d9  height=1781475  trust=569913520714206297916  blocktrust=491742704494696  date=11/20/17 10:14:24
ProcessBlock: ACCEPTED
SetBestChain: new best=0def539c364181bb509653a291a50783b49d79aa1cf79fc1e4377c963413e1b2  height=1781476  trust=569914012968678030572  blocktrust=492254471732656  date=11/20/17 10:16:00
ProcessBlock: ACCEPTED
bool LoadExternalBlockFile(FILE*)() : Deserialize or I/O error caught during load
Loaded 5782 blocks from external file in 976515ms

This was a key block number in my prior setup days ago during my posts.   Something is definately wrong.  I could understand the random getting disconnected as maybe internet went down; however, at key block numbers is too coincidental.   This is definately AFTER the 2GB blk file is created.

So, my file is now....
blk0002.dat   47.9 MB (   50,328,045 bytes) sha256 ABFE04484E56047C449E7BB983BF4AFA056195DB623999FFA1955AC697ED6557  at 1781476


Clam version v1.4.17 (2015-09-23 21:07:15 -0300)
Using OpenSSL version OpenSSL 1.0.1j 15 Oct 2014

Looks like an read/write error from your disk. The code is not printing the exact exception so it will be difficult to help you, as it looks a hardware failure and probably hard to replicate in another hardware. Are you using the pre-compiled version or are you compiling it yourself? If yes, please find the attached code in main.cpp

Code:

catch (std::exception &e) {
            LogPrintf("%s() : Deserialize or I/O error caught during load\n",
                   __PRETTY_FUNCTION__);
        }

and change to

Code:

catch (std::exception &e) {
             std::cerr << e.what();
        }

so we can have the exact exception message