Syncing badblock with "invalid gas used (remote: 81977 local: 21272)" about go-musicoin HOT 16 CLOSED

fast or full sync?

which exact version are you running?

from go-musicoin.

@5chdn
syncmode full and
linux ubuntu 16.04 (upgrade from 14.04)
commit : 2.1.0-unstable-b0f741e8

my driven issues are all the same env.

from go-musicoin.

Another error :

Number: 331822
Hash: 0x2015977dce4694cc8cf7060ddbcee94f033872e49c39d3a4c995e8105fe4e58f

Error: nonce too high
##############################

WARN [10-22|17:36:34] Synchronisation failed, dropping peer peer=98479ac8ec626dc7 err="retrieved hash chain is invalid"

almost 3 minutes node is idle, not active. and goto next block synching
now 17:45:00
CPU 58.9% , MEM : 6.0% 38:00.75 gmcv3

from go-musicoin.

Excuse me, could you remove your musicoin chaindata, pull the latest source code, and run

make clean
make all

And try a full sync again?

And if there is any error in the log, please upload the full logs somewhere. It's hard to understand what's going on with the snippets only.

from go-musicoin.

I've already clean chaindata, and tested.
and, uploaded all google drive

https://drive.google.com/drive/u/1/folders/0B3k6K-LV7tX6TnF4MWtubkRXZnc

from go-musicoin.

and there's nothing changed your PR. 61.
just license term changed and printing fmt minor touched.
Anyway, In this merge has somethings missing related to gas fee calculation, besides of recent days ETH vizantium fork.
But, in Music that's not related ETH VZ fork.
Anyway, I'll try it.

from go-musicoin.

Is it related go version ? It recommended over go-1.7 is ok.
I used v1.8

musicoin:~/logs$ gmcv3 version
Gmc
Version: 2.1.0-unstable
Git Commit: b0f741e
Architecture: amd64
Protocol Versions: [63 62]
Network Id: 7762959
Go Version: go1.8
Operating System: linux
GOPATH=
GOROOT=/usr/lib/go-1.8

from go-musicoin.

Can you give me your full peer list including enode id and client version?

from go-musicoin.

@5chdn
v3.01 scratch debug logs and peer lists

google drive folder link.
https://drive.google.com/drive/u/1/folders/0B3k6K-LV7tX6TnF4MWtubkRXZnc

https://drive.google.com/open?id=0B3k6K-LV7tX6Z0tjTFJOX09HMVU it's latest version of debug logs

peer list link
https://drive.google.com/open?id=0B3k6K-LV7tX6OUQzT0pNSXMwek0

from go-musicoin.

Can't see any fatalities there. For some reason, you are connected to 8 misbehaving nodes. I'm wondering why they are not banned.

from go-musicoin.

Could you use admin.removePeer() on all GMC 1.x nodes and see if this still persists?

Technically, all nodes GMC < 2.0 are misbehaving and should be removed.

from go-musicoin.

https://drive.google.com/open?id=0B3k6K-LV7tX6Z0tjTFJOX09HMVU it's latest version of debug logs

There is nothing wrong in these logs. Did you reset the data dir?

from go-musicoin.

https://drive.google.com/open?id=0B3k6K-LV7tX6WF95XzVYNHpIaDA
is V3.0 logs.
all is scratch build and scratch data.
it's run on verbosity 3 (info) , v301 is verbosity 4 (debug).
v3 and v301 is no big difference on src code.

"Technically, all nodes GMC < 2.0 are misbehaving and should be removed."
I agree, but user can't remove it by manual. I'm also. just using it.
V3.0 still hang on around 500k block heights.

from go-musicoin.

All right, before proceeding please, tell which of the following applies, A or B:

A) Node receives BAD BLOCK and stalls syncing, restarting does not allow to continue sync.

B) Node receives BAD BLOCK and continues syncing, just prints the warning.

If (A), you have to do the following for me:

1. Get latest source
2. Clear chaindata
3. Run GMC with verbosity >= 4
4. wait for BAD BLOCK
5. give me the full logs please

If (B), a verbosity => 4 would be nice too, but that's correct behavior. Receiving a BAD BLOCK, printing a warning, ignoring it, and continue to sync the good chain.

from go-musicoin.

what's difference with v3 and v3.01 , as my view there's no difference for interfere operations?
is it long story then, join slack and DM to me.
I'll do it your request from scratch.

from go-musicoin.

latest test logs are here :
https://drive.google.com/open?id=0B3k6K-LV7tX6M2EtbUVyUG4wY0U

v3.1 -> v211 : verbosity 4, 3 is looks well.
v3 -> v210 : verbosity 3- badblock issue still growing (now block height 900K).

Now, I think abandon (close) v3 badblock issue here, stop v3 testing and it change to v3.1(v211) to start over existing gmcv2 chaindata , seamless binary update test.

from go-musicoin.