Just an FYI to all...

if you were caught off chain, and now you're back on... make sure you run checkwallet and repairwallet from debug window.

Well, during this whole time fixing wallets, I managed to get 20 blocks to myself...

ah, you're the other one ...yup, pretty low dif atm

again moved to be visible - you might also briefly check the recent pages as currently there's a lot of movement here.


however, repost:



I'm with it and after doing a full resync starting with your last checkpoint bootstrap upload and with just the connect to the main node, old peers.dat removed it synced ok after all... took some time, but went perfectly ok and it turned out that I've been on the right chain the whole time ...however, as by coincidence, I captured the updated blockchain files up to 599568 ...and put them in a zip archive, uploading them to zippyshare atm.
there's a md5 checksum inside that reflects the file state in the archive. I'll update this post as soon as upload is available

right now, avoiding every other client than the one at: 108.61.173.201 = ambercoin01.mooo.com  
seems to be the best solution to stay on the right chain until all clients that went away are as well back on the right chain again... anything else could feed this loop again and again whenever the network becomes thin at some end.

so, if you're not seeing the above proofhash @ getblockbynumber 599568, there's one thing to do to get back to the right blockchain:

- backup your wallet.dat (always do!)
- keep in mind, the archive as well has an ambercoin.conf so if yours is custom, rename it and make changes according the contained one
  if you don't have a ambercoin.conf, just ignore this line
- remove (or backup) 'database' and 'txleveldb' folders, 'blk0001.dat' and 'peers.dat' (to be on the safe side)
- get either the official bootstrap file from here: https://bt.irlbtc.com/view/944408.msg13087230#msg13087230
      OR
- you can download a more recent version I captured @ block 599568 here:
  part1: http://www31.zippyshare.com/v/ej88U1BI/file.html
  part2: http://www31.zippyshare.com/v/iyia6kXg/file.html
- now unpack whichever of the archive versions you've got (either one version will do, the first might only take a bit longer) inside your datafolder, file structure of both versions are the same.
- start your wallet
- wait...
- it will hopefully connect sooner or later and eventually start syncing... first contact might take some time, but once this is through, it should sync ok.
- if syncing seems to be stuck (after having connected propperly and already received some blocks), a brief restart of the wallet
  should make it start receiving blocks again directly. and once you've had a successful connection with ambercoin01.mooo.com, the
  wallet should have no problems becomming reconnected immediately.

edit: 599444 confirming as well ok
edit: 599640 also ok (but that's not covered with my upload anymore)




I think it's not undue to stress this once more:


and I suspect that as well... (yet, the -listen option is only used by the rpcserver, nothing to do with p2p which is the one needed for database syncing and stuff)

so the dev advising ONLY to use -connect is to be taken rather serious, as a startup option or in the conf file.
using addnode instead of connect immediately provided me with other nodes and some ot them were waaay behind.
there seem to be no other peers appearing with -connect, tho. ...which is what should be considered GOOD for the moment.
for now I'd absolutely support using only the main node as a reference to sort out that mess once and for all.


...can be done at anytime anyway without harm, but if you suspect your ballance might show some odd values, this will most likely fix the messed up display:

certainly all blocks being minted or mined AFTER tripping on a fork will of course stay on that fork... so, rolling back and resyncing to the main blockchain shows, they never existed in the first place. facing that case also means it would be a good time for the 'repairwallet' tip after syncing completed.

I would not be able to do this, unless someone with the issue provided their debug log file

certainly not too much into deep, and with only one side able to being inspected it might end up as well in guesswork...

...however I became aware that it might take some time, even if ALL steps to avoid hints of other clients than ambercoin01.mooo.com have been done, which are
  - removing peers.dat
  - no addnode at all in config, just connect=ambercoin01.mooo.com (or 108.61.173.201 if you will)
  - all old blockchain data being removed (database & txleveldb folders, blk0001.dat file)

sometimes I had the notion of that node simply dropping the connection over and over.... but after a while, might take half n hour or so, it got bound. it then lasted available since and used to become available immediately after a wallet restart, even with removing peers.dat. so, it might really be that node having too much to handle so it doesn't accept connections for that time... but, guesswork... yet, the above mentioned preparation eventually IS MANDATORY to let your wallet start receiving and accepting further blocks.

edit: one post above - which appeared while writing this - are some more comprehensive answers
thanx for the input! and well for the heads-up according to miniupnp!

Here is the relevant section of the debug log file:

ThreadSocketHandler started
ThreadStakeMiner started
trying connection ambercoin01.mooo.com lastseen=0.0hrs
Flushed 0 addresses to peers.dat  18ms
refreshWallet
connected ambercoin01.mooo.com
send version message: version 90001, blocks=594334, us=0.0.0.0:0, them=108.61.173.201:31982, peer=108.61.173.201:31982
trying connection 108.61.173.201 lastseen=0.0hrs
socket closed
disconnecting node ambercoin01.mooo.com
connected 108.61.173.201
send version message: version 90001, blocks=594334, us=0.0.0.0:0, them=108.61.173.201:31982, peer=108.61.173.201:31982
trying connection 188.163.90.183 lastseen=0.0hrs
socket closed
disconnecting node 108.61.173.201

I took this section right after the point where the wallet synchronizes.  This is repeated throughout the log file.

I suspected that, too... no signs of rejection or whatever and then, after some time it became responsive again.

lol, training camp for the aspiring protocol-whisperer 

Last DEBUG info from ambercoin01.mooo.com.
Maybe would be helpful.

getblocks stopping at limit 319039 000000001e9e81e56405
accepted connection 81.88.143.194:58254
getblocks 13920 to 000000002177ca4f7aa4 limit 500
  getblocks stopping at limit 14419 0000000000e17c6c14e5
partner 81.88.143.194:58254 using obsolete version 90000; disconnecting
ProcessMessage(version, 112 bytes) FAILED
disconnecting node 81.88.143.194:58254
connection from 113.161.128.181:64841 dropped (banned)
getblocks 318540 to c184b39662b4c2b46b3b limit 500
  getblocks stopping at 318975 c184b39662b4c2b46b3b
connection from 71.187.62.42:56790 dropped (banned)
connection timeout
accepted connection 176.107.192.2:61021
partner 176.107.192.2:61021 using obsolete version 90000; disconnecting
ProcessMessage(version, 112 bytes) FAILED
disconnecting node 176.107.192.2:61021
trying connection 108.61.174.143:31982 lastseen=1.2hrs
connection from 85.214.23.49:38378 dropped (banned)
connection from 213.180.26.45:53289 dropped (banned)
connection from 212.83.176.222:50699 dropped (banned)
connection from 213.180.26.34:54001 dropped (banned)
getblocks 598600 to 00000000ec75c4beed3d limit 500
  getblocks stopping at limit 599099 53c6a89261562977f215
getblocks 598600 to 00000000059cd7afbae2 limit 500
  getblocks stopping at limit 599099 53c6a89261562977f215
received getdata (12 invsz)
connection from 113.161.128.181:64842 dropped (banned)