I have lost a lot of time, and I hang your signature last year. I have to post 10 posts a week, which causes my original account to be suspended. Now I have correctly filled out the form and paid attention to the Twitter operation.
Not sure why posting 10 a week would get you banned unless you're spamming or something strange since almost no one gets banned from Bitcointalk. Don't confuse posting on twitter with what you're supposed to do. You're supposed to post on bitcointalk (not twitter). - With twitter, you're only supposed to 'follow' the group. Check back on Sunday/Monday to see if you're on the list. Good luck. |
|
|
|
The name: xiaopihai is not on the sign up list. The address: 0xdd01cf481ccc05032c9360ee4998532dd2ad3151 is not on the sign up list. No idea what your twitter nick is, so I can't check that. Basically, it appears you did NOT complete the google form signup. Take note that if you did, you would also need to post on bitcoin talk at least once a week. On quick check, you posted on July 23rd and then not again until 8/3. 10 days between the posts - this shouldn't have been an issue unless one of your other posts was deleted so that your post count would have actually dropped. All in all, it appears you didn't sign up with the google form or you JUST did it since Sunday. Fill in and submit it according to your Google form. Why didn’t you receive it?And the last time I have reacted to this question, but you have no response. It's not my form. You are not on the list. I can only assume you didn't submit the completed form. Try again. Hell, try many times to ensure it's done. https://goo.gl/forms/39bP7CDRiCg58mgh1Also note that if you submit today, you are not on the list until Sunday. So, the following Sunday is when you are paid. Example.... I joined on Monday July30th. This was After Sunday. So, I didn't get on the list until 8/6. Now, I do not expect to be paid until 8/12. PS. You mentioned that I didn't respond to your question last time. Nope, I didn't. I've never said anything to you. You never asked me anything, so I've never responded to you. Maybe you're confusing me with someone else (like an employee of Semux or something). |
|
|
|
The name: xiaopihai is not on the sign up list. The address: 0xdd01cf481ccc05032c9360ee4998532dd2ad3151 is not on the sign up list. No idea what your twitter nick is, so I can't check that. Basically, it appears you did NOT complete the google form signup. Take note that if you did, you would also need to post on bitcoin talk at least once a week. On quick check, you posted on July 23rd and then not again until 8/3. 10 days between the posts - this shouldn't have been an issue unless one of your other posts was deleted so that your post count would have actually dropped. All in all, it appears you didn't sign up with the google form or you JUST did it since Sunday. |
|
|
|
I didn't get any SEM for week 5. Been in from the start of this round so got the first 4 payouts. Name is still on the list. Plz check.  It might have everything to do with the fact that you posted on July 11th and then July 27th. Nearly 2 weeks apart when the airdrop is for those who post at least once a week. Also, the calculation is done by post count. So, if you posted, but a prior post you made is deleted, then it also appears that you haven't posted anything from one week to the next. Something else to consider if you're only posting one post a week. |
|
|
|
Delegate RENT....
Has anyone burned the 1000 sem to run a Delegate/Validator that they are no longer using?
I am interested in RENTING the Delegate key (so that I don't need to burn 1000 to start a new one).
how much you pay just for curiosity? Haven't really thought about it. Happy to negotiate via DM, but there are variables.... i.e. If I am providing all the votes, private, and the server, then I wouldn't be paying much. About 2% daily. If I don't provide the server, then a little more... 3 or 4% Can't pay too much, else I would just vote up on the public pools. Basically, it was an offer to make the person something daily rather than nothing on their burned sem. If the cost is too much, then I would simply do the burn myself since I would recover the full amount in under 2 weeks. I am simply trying to give an opportunity to someone that has already burned. |
|
|
|
|
There are currently 146 deligates. So, 46 which are not validators.
I am looking to get a key to start a validator.
So, if someone has burned the sem and not using the deligate, I would be willing to 'rent' it (pay from pool profits).
Contact me to see if it's a solution to get something from your defunct deligate.
|
|
|
|
|
Delegate RENT....
Has anyone burned the 1000 sem to run a Delegate/Validator that they are no longer using?
I am interested in RENTING the Delegate key (so that I don't need to burn 1000 to start a new one).
|
|
|
|
I have done everything as it is necessary, but I have a question for you, how many messages per week should I write and in which sections? excuse me ,thank you. It says a minimum of 1 per week. |
|
|
|
https://i.imgur.com/h5BKpqJ.gifvmy supplier just sent this video of the sample protective case designed for the moon bars... production has started and I'll take some better photos soon - happy with the fit and if all goes well I will soon be creating cases for my older work as well  Not taking orders yet, but will post here or send an email when ready. Send me an email. I need a few of them. |
|
|
|
|
It's funny reading all these posts to this thread.
He never claimed to have lost 700BTC. He said the scammer has his BTC in an address that has 700BTC.
Funnier is the number of people that believe 'hacking' a private key from the public address is even possible. If it were, even for a single address, then everyone would be doing it to become instant billionaires. Of course, bitcoin would be worthless instantly.
|
|
|
|
Thanks, but it doesn't work for me. As soon as I try to run the CLAM client I get an error and it quits: 2018-05-25 12:43:59 Clam version v1.4.17-139-gf0707d3 (2017-04-10 17:28:15 +0000)
2018-05-25 12:43:59 Using OpenSSL version OpenSSL 1.0.1f 6 Jan 2014
2018-05-25 12:43:59 Default data directory /home/user/.clam
2018-05-25 12:43:59 Used data directory /home/user/.clam
2018-05-25 12:43:59 init message: Verifying database integrity...
2018-05-25 12:43:59 dbenv.open LogDir=/home/user/.clam/database ErrorFile=/home/user/.clam/db.log
2018-05-25 12:44:00 init message: Loading block index...
2018-05-25 12:44:00 Opening LevelDB in /home/user/.clam/txleveldb
2018-05-25 12:44:00 Transaction index version is 70509
2018-05-25 12:44:00 Opened LevelDB successfully
2018-05-25 12:44:00 ERROR: LoadBlockIndex() : unable to unserialize record : try running with -reindex
2018-05-25 12:44:00 : Error loading block index database : try running with -reindex
2018-05-25 12:44:00 Shutdown : In progress...
2018-05-25 12:44:00 StopNode()
2018-05-25 12:44:00 Shutdown : done
I used my own blk0001.dat, with this sha256sum: 510d0cabb4208d9a545a0e05fab2c0c29c225d699e0601a16b2891facbd2ce98 blk0001.dat I guess it's the same as yours. Other than that I'm guessing we are using incompatible versions of leveldb. Edit: how does the start of your debug.log look when it's failing? Do you see a different "transaction index version" number? Strange.... My file is the same..... BLK0001.DAT CRC32: EDF37145 MD5: D9F206FF08650A0CF5F8DC71735A388D SHA-1: 9897F16A8E6AC09DD0AF41C66A2E2897482399A1 SHA-256: 510D0CABB4208D9A545A0E05FAB2C0C29C225D699E0601A16B2891FACBD2CE98 Clam version v1.4.17 (2015-09-23 21:07:15 -0300)
Using OpenSSL version OpenSSL 1.0.1j 15 Oct 2014
Startup time: 05/21/18 16:59:10
Default data directory C:\Users\Michail\AppData\Roaming\Clam
Used data directory C:\Users\Michail\AppData\Roaming\Clam
init message: Verifying database integrity...
dbenv.open LogDir=C:\Users\Michail\AppData\Roaming\Clam\database ErrorFile=C:\Users\Michail\AppData\Roaming\Clam\db.log
init message: Loading block index...
Opening LevelDB in C:\Users\Michail\AppData\Roaming\Clam\txleveldb
Transaction index version is 70509
Opened LevelDB successfully
Deleted the log file. Did a rescan. Same results. Here is the log file ( https://www.dropbox.com/s/xyc2w3jlklcpuy0/debug.log ) I will try to rerun with a -reindex and bootstrap and connect=0 to see if anything changes tonight. |
|
|
|
ERROR: ProcessBlock() : already have block 1781476 0def539c364181bb509653a291a50783b49d79aa1cf79fc1e4377c963413e1b2
ERROR: CheckBlock() : size limits failed
if (vtx.empty() || vtx.size() > MAX_SIZE || ::GetSerializeSize(*this, SER_DISK) > MAX_SIZE)
return error("CheckBlock() : size limits failed");
Strange, a block with size larger than 1Mb in the bootstrap file? Is there any way to extract a single block from the bootstrap file to verify this? The bootstrap file is fine. I recently imported the whole thing. I suspect it's the "vtx.empty()" condition which is true. It would be interesting to have a copy of the clam folder which reliably causes this error. I don't need the 2GB blk* file - I already have that. And I have the bootstrap.dat too. So just the other files. Here.... https://www.dropbox.com/s/03aqrhnla5sca50/ClamNoDebug.rarThat is the entire directory except for debug.log and the blk0001.dat (2gb file). clam.conf still with connect=0 The log is basically... 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
addcon thread interrupt
net thread interrupt
opencon thread interrupt
dumpaddr thread stop
msghand thread interrupt
Shutdown : In progress...
StopNode()
Shutdown : done
and when rerun, the log does the same, but is: LoadBlockIndex(): hashBestChain=0def539c364181bb509653a291a50783b49d79aa1cf79fc1e4377c963413e1b2 height=1781476 trust=569914012968678030572 date=11/20/17 10:16:00
LoadBlockIndex(): synchronized checkpoint f89eedd61837c581b4b8fcb85782066b04f7266b4bd946b583805d330a0ae0cc
Verifying last 500 blocks at level 1
block index 16855ms
init message: Loading wallet...
nFileVersion = 1041700
Keys: 101 plaintext, 0 encrypted, 101 w/ metadata, 101 total
wallet 135ms
init message: Loading addresses...
Loaded 0 addresses from peers.dat 0ms
mapBlockIndex.size() = 1781477
nBestHeight = 1781476
setKeyPool.size() = 100
mapWallet.size() = 0
mapAddressBook.size() = 1
DNS seeding disabled
net thread start
addcon thread start
opencon thread start
msghand thread start
dumpaddr thread start
init message: Done loading
addcon thread interrupt
opencon thread interrupt
net thread interrupt
dumpaddr thread stop
msghand thread interrupt
Shutdown : In progress...
StopNode()
Shutdown : done
And every time run after that is..... ERROR: ProcessBlock() : already have block 1781473 b18c076bb4e687d959932c85766f0099592f1e4f1995f98d55bc63aa90f23c68
ERROR: ProcessBlock() : already have block 1781474 bb831330ced8366b7095c5a71267b8cd3ef5ef5078ee00aea57fcbde79d21732
ERROR: ProcessBlock() : already have block 1781475 eb4205fb93f5e6c6aeacbff987564f3ec4e1488a6e0c57a000299ab3625741d9
ERROR: ProcessBlock() : already have block 1781476 0def539c364181bb509653a291a50783b49d79aa1cf79fc1e4377c963413e1b2
ERROR: CheckBlock() : size limits failed
ERROR: ProcessBlock() : CheckBlock FAILED
bool LoadExternalBlockFile(FILE*)() : Deserialize or I/O error caught during load
Loaded 0 blocks from external file in 266760ms
opencon thread interrupt
addcon thread interrupt
net thread interrupt
dumpaddr thread stop
msghand thread interrupt
Shutdown : In progress...
StopNode()
Shutdown : done
|
|
|
|
|
#11 please.
PS. Why only 99 winners? What if xxxx.00
|
|
|
|
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 catch (std::exception &e) {
LogPrintf("%s() : Deserialize or I/O error caught during load\n",
__PRETTY_FUNCTION__);
}
and change to catch (std::exception &e) {
std::cerr << e.what();
}
so we can have the exact exception message I doubt it's a problem specific to me. Appears many people are having the problem. The only way to get past this problem is to take out the 'connect=0' in order to sync past this block via internet syncing. Once you get past it, you can then close the client, rename bootstrap, and start up again. People having to close and reopen are getting past the problems by simply closing and restarting the client many times. As long as I keep connect=0, I am able to get stuck on the same block every time. I have saved the block state at this point to be able to easily repeat the problem should another test be requested. I am using the original pre-compiled version on windows. All in all, I can duplicate the problem several others are complaining about and appears to be at 1781476. Also, not a read/write issue. This is on a laptop with an SSD drive when I started the tests. It is now on a Windows Server (Raid 60) with 32GB ram. sha256 checks correctly for both machines. As long as I don't have the connect=0 in clam.conf and I import, and I keep restarting the client (everytime it stops), I can eventually sync up; however, it appears the fail points are the same each time. Leaving 'connect=0', I no longer load blocks from the bootstrap. Now I only see (after restarting the app each time).... .
.
.
ERROR: ProcessBlock() : already have block 1781474 bb831330ced8366b7095c5a71267b8cd3ef5ef5078ee00aea57fcbde79d21732
ERROR: ProcessBlock() : already have block 1781475 eb4205fb93f5e6c6aeacbff987564f3ec4e1488a6e0c57a000299ab3625741d9
ERROR: ProcessBlock() : already have block 1781476 0def539c364181bb509653a291a50783b49d79aa1cf79fc1e4377c963413e1b2
ERROR: CheckBlock() : size limits failed
ERROR: ProcessBlock() : CheckBlock FAILED
bool LoadExternalBlockFile(FILE*)() : Deserialize or I/O error caught during load
Loaded 0 blocks from external file in 266760ms
0 blocks load. Again, if I take out connect=0, then it will error; however, it will start syncing from the internet to get past that point, in which case, I can then stop, rename bootstrap, and continue on again until the next point. |
|
|
|
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 |
|
|
|
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. |
|
|
|
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. |
|
|
|
exactly what I told from beginning...number of attempts not change the outcome.
I am agreeing with you and confirming the same results. Isn't it nice when two people come to the same conclusion? 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. Further issue is that my client must be restarted many times as it simply stops syncing. (Both when trying to rename the bootstrap back or simply to let it run through normal syncing.) I am currently at: Sat Jan 6 20:13:52 2018 1851170 It wouldn't be so bad if the client didn't need to be restarted all the time. |
|
|
|
regarding file size
I see -size 1,95 GB (2 097 155 946 bytes) and size on disk 1,95 GB (2 097 156 096 bytes)
What does the first size refer to, if not size on disk? Where else does the file exist other than "on disk"? I guess the "on disk" figure could be rounded up to the next 4k boundary or something (it's a multiple of 4096). I've no idea why the import isn't working for you. I've not heard of anyone else having that problem. I hope the bootstrap.dat file isn't corrupted. Did anyone else try using it recently? If so, how did it go? My bootstrap matches; however, I am really having a problem syncing via the strap as well. It keeps simply stopping from using the file and goes to live network sync. Keeping a point of the log each point, I am quoting some from the various restarts of the bootstrap... ERROR: ProcessBlock() : already have block 1695630 818e05902dc6d1631c53b6ed37cf4a4a36f6f26921a82073aa24f0b873f395ac
ERROR: ProcessBlock() : already have block 1695631 2a9dc26d49a4f927956fbbf508fd77bc9e8724338db5e8ae5f57930dc4d314d0
ERROR: ProcessBlock() : already have block 1695632 bc80a90f1ed2b7d4b9020bd99d06b213b9a1375d442e58a3c276293eb01e1197
SetBestChain: new best=4e5dd1c04572ad19b3b0b3e9d9d9225e498f04cea3ccfaf8604795dd2c41580b height=1695633 trust=537538944795330309503 blocktrust=357114394999700 date=09/21/17 07:07:12
ProcessBlock: ACCEPTED
SetBestChain: new best=52b54f2cb601d86360cf902603aa96e0612daef58fa0e8759e82f8dc06afa295 height=1695634 trust=537539300820730763241 blocktrust=356025400453738 date=09/21/17 07:07:44
ProcessBlock: ACCEPTED
- Just randomly jumped from bootstrap into life sync. ERROR: ProcessBlock() : already have block 1781475 eb4205fb93f5e6c6aeacbff987564f3ec4e1488a6e0c57a000299ab3625741d9
ERROR: ProcessBlock() : already have block 1781476 0def539c364181bb509653a291a50783b49d79aa1cf79fc1e4377c963413e1b2
ERROR: CheckBlock() : size limits failed
ERROR: ProcessBlock() : CheckBlock FAILED
bool LoadExternalBlockFile(FILE*)() : Deserialize or I/O error caught during load
Loaded 0 blocks from external file in 300112ms
ERROR: FetchInputs() : 15e9801924bd8818ef78d370318f7cf
- Error on block 1781476 and went to live sync. SetBestChain: new best=4d38433ebb5632c96085c1bbb9c82ceee298dde4530cbca2b404073c207b2b22 height=1790583 trust=573894112687463887956 blocktrust=467704776088576 date=11/26/17 19:24:32
SetBestChain: new best=7a1f32f6913c02b4256b55e5df633013abfe7307dc13d802eba38df5583f5a3a height=1790584 trust=573894580155193385676 blocktrust=467467729497720 date=11/26/17 19:25:20
SetBestChain: new best=2154f92eb2acaaf9f006c8903df5b85807364c391ac403ac17b36da4369d8871 height=1790585 trust=573895047386116455242 blocktrust=467230923069566 date=11/26/17 19:26:24
SetBestChain: new best=8a3bb99b7052e96cff12a05b8cbbdafa535ba27f1541b66ab078e1e75bff1864 height=1790586 trust=573895514144145698164 blocktrust=466758029242922 date=11/26/17 19:28:32
SetBestChain: new best=cbeeebb2a4d03eea7a7a8eed4957896ddf9760814b9be4bca3f2359ab381f406 height=1790587 trust=573895979947490824913 blocktrust=465803345126749 date=11/26/17 19:29:36
ProcessBlock: ACCEPTED
ERROR: ProcessBlock() : already have block 1789999 de1ca163b31006e9b88f0d5eb03ccf491533dc8c4f2522a663e370da45ff8395
ERROR: ProcessBlock() : already have block 1790072 e1405e09285a1fd9f51b24084ac7d0162ab921814794006c3283f0c5c2746536
ERROR: ProcessBlock() : already have block 1788071 cc835b93531eb8dc59b02769174a44b0ac448493f320ecefffd031a9b06f92bc
ERROR: ProcessBlock() : already have block 1790000 f15e1180eea622acb4847b182aa082c58c5b1252b272e515f1ddaf060e2aa025
ERROR: ProcessBlock() : already have block 1790073 1d9f5a230187fbbd7b9dc4c23e2522b57fe494d6c471edc4967afc0fa0a382d5
- Uhhh, jumps back nearly 600 blocks. Then out of order and some from bootstrap and some live. So, close the client yet again. ERROR: ProcessBlock() : already have block 1781474 bb831330ced8366b7095c5a71267b8cd3ef5ef5078ee00aea57fcbde79d21732
ERROR: ProcessBlock() : already have block 1781475 eb4205fb93f5e6c6aeacbff987564f3ec4e1488a6e0c57a000299ab3625741d9
ERROR: ProcessBlock() : already have block 1781476 0def539c364181bb509653a291a50783b49d79aa1cf79fc1e4377c963413e1b2
ERROR: CheckBlock() : size limits failed
ERROR: ProcessBlock() : CheckBlock FAILED
bool LoadExternalBlockFile(FILE*)() : Deserialize or I/O error caught during load
Loaded 0 blocks from external file in 283151ms
ProcessBlock: ORPHAN BLOCK 0, prev=7d8a19d3ce662386f98307beb880fcee115bf49f10f4e7063e3ffbe1f614c4ec
ProcessBlock: ORPHAN BLOCK 1, prev=a2eabc9e24d76c160c808ea06dc2300d1a4a56f08f690d8303f68c60ce5cd6da
SetBestChain: new best=2b7307f37ebcc44d96ec7aa889cae28b0035cea5dd28d243780b2e9d4c1187ab height=1795113 trust=575862257978351955123 blocktrust=334131721375698 date=11/29/17 23:44:16
ProcessBlock: ACCEPTED
SetBestChain: new best=00be02ec9ee9165b92f101e9f65abf5906668afdc6e00f82362525896379d583 height=1795114 trust=575862590916013466684 blocktrust=332937661511561 date=11/29/17 23:44:32
ProcessBlock: ACCEPTED
SetBestChain: new best=2479593d7a54855294b05cc0bce9354dfc82e33404ddd6ae0529e63c377823e9 height=1795115 trust=575862922668118957467 blocktrust=331752105490783 date=11/29/17 23:45:20
ProcessBlock: ACCEPTED
SetBestChain: new best=37a37e5175755d02a92778b3188e06e98c5fcccca639627488f391aa8be5a303 height=1795116 trust=575863253575162937475 blocktrust=330907043980008 date=11/29/17 23:47:44
ProcessBlock: ACCEPTED
SetBestChain: new best=70b79ccee5a5ca592f377304c7305ccc931137cfa031b6a25382b182801017a8 height=1795117 trust=575863583978416930947 blocktrust=330403253993472 date=11/29/17 23:49:52
ProcessBlock: ACCEPTED
SetBestChain: new best=69ab3faeeb4310d2048e934763b144ecbf2b1baf74e1e1eab603dc404959289d height=1795118 trust=575863913708403054989 blocktrust=329729986124042 date=11/29/17 23:51:28
It did it again. 1781476 Basically, I can't get it to sync myself. Several attempts and confirmed the sha256 of the bootstrap matches the dooglus post. |
|
|
|
|
Show Posts
