Hrm.... the network is somehow fucked or forked or something....
Half the pools I go to are stuck on block 793 and not finding anymore blocks, while other pools I go to are working on block 802 and seem to be finding blocks fine....
all my 3 wallets on 3 machines, 1.2.1 are having problems with a block, however it seems like they are only printing out an exception and then continuing to work. the printout :
2015-01-25 19:43:08 INFO: get timestamp for tx with id -4762078490203704075 found
nxt.at.AT_Exception: Calculated md5 and recieved md5 are not matching
at nxt.at.AT_Controller.validateATs(AT_Controller.java:404)
at nxt.BlockchainProcessorImpl.accept(BlockchainProcessorImpl.java:682)
at nxt.BlockchainProcessorImpl.pushBlock(BlockchainProcessorImpl.java:647)
at nxt.BlockchainProcessorImpl.access$400(BlockchainProcessorImpl.java:51)
at nxt.BlockchainProcessorImpl$1.processFork(BlockchainProcessorImpl.java:323)
at nxt.BlockchainProcessorImpl$1.run(BlockchainProcessorImpl.java:191)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
2015-01-25 19:43:09 INFO: tx with id -4762078490203704075 found
2015-01-25 19:43:09 INFO: get timestamp for tx with id -4762078490203704075 found
it seems the problem started somewhere between block 59761 and 59771
all 3 wallets on all 3 different machines give the same error. i would assume something got in via the network, that the software stumbles upon.
That error was caused from a miner that had outdated version. If you restart the wallets you probably will be good
but do you mean there are somebody who is mining in solo with old wallet?
and this cause the fork?
This is very risky
i hope dev can implement a petch to avoid this in futures...
The "INFO: tx with id" messages are debugging info that didn't get removed.
As for the exception, a simpler message would have probably been better than dumping the stack trace, but it's just rejecting a block(most likely created by 1.2.0 in this case) it received as invalid.
I'm a bit surprised the 1.2.0 chain is still running since it tended to get stuck under the current situation(block generation wouldn't pass verification so it would loop failing to create a block), not continue on wrong.
The 1.2.1 chain is longer and has a higher cumulative difficulty, so 1.2.1 clients should all eventually end up there.
