header/p2p: Mainnet nodes getting mocha-4 headers
#3071
Comments
|
note from the person observing this (and he wasnt the only one reporting it, we just figured they misconfigured): it seems that the error above happens only on that specific header |
|
some more logs from other reports:
ill do a test run of the light node on a fresh server following the docs, see if this also happens (though i think JB tried this yday and also ran into it) |
|
ok i did a test, if you go via docs and do: celestia light init you immediately get: |
|
final note: after leaving it running, the invalid header messages are quite frequent in the logs (every 20 or so lines at least) but other than that the node seems to be syncing fine |
renaynay
changed the title
mocha-4 headers
|
here are some more logs from the light node, i also see a lot of stream resets and i left all the logs prior to shutdown too when i clicked ctrl+c |
|
Hey @mindstyle85 don't worry about the stream reset logs on shutdown. They aren't related. I'm going to run a modified version of the node shortly to dump logs of who is sending those headers on mainnet. I have a suspicion it's possibly a few nodes running over incorrect datastore mounts and accidentally running with default settings (as Will report back soon. |
|
Related celestiaorg/go-header#141 |
|
The explanation here is someone is running a The solution is to have the core/listener take a chainID and ensure the blocks it is receiving are for that chainID it receives on start-up, since the current checks we have (1. chainID validation on store Init via |
|
Ok great, ill let you close this whenever you want given that i see you already made a fix :) |
…rect chain (#3086) Right now, it is possible for a **bridge** node that was initialised and started on one chain (e.g. `mocha-4`) to be stopped and restarted on a different chain (e.g. `mainnet`) and propagate headers from the old chain (`mocha-4`) into the different network (`mainnet`). This PR fixes this issue by causing the listener to fatal if the listener recognises it is receiving blocks from a different chain to that which it expects. Error will look like this: ``` 2024-01-10T16:06:22.001+0100 ERROR core core/listener.go:175 listener: received block with unexpected chain ID: expected arabica-11, received mocha-4 2024-01-10T16:06:22.001+0100 INFO core core/listener.go:177 listener: listening stopped 2024-01-10T16:06:22.001+0100 FATAL core core/listener.go:126 listener: invalid subscription ``` Resolves #3071
…rect chain (#3086) Right now, it is possible for a **bridge** node that was initialised and started on one chain (e.g. `mocha-4`) to be stopped and restarted on a different chain (e.g. `mainnet`) and propagate headers from the old chain (`mocha-4`) into the different network (`mainnet`). This PR fixes this issue by causing the listener to fatal if the listener recognises it is receiving blocks from a different chain to that which it expects. Error will look like this: ``` 2024-01-10T16:06:22.001+0100 ERROR core core/listener.go:175 listener: received block with unexpected chain ID: expected arabica-11, received mocha-4 2024-01-10T16:06:22.001+0100 INFO core core/listener.go:177 listener: listening stopped 2024-01-10T16:06:22.001+0100 FATAL core core/listener.go:126 listener: invalid subscription ``` Resolves #3071
Celestia Node version
12.1
OS
ubuntu
Install tools
No response
Others
No response
Steps to reproduce it
install and run light node like in the docs (defaults to mainnet without flags etc)
Expected result
run on mainnet
Actual result
2024-01-07T09:04:19.472-0800 ERROR header/sync sync/sync_head.go:175 invalid network header {"height_of_invalid": 894619, "hash_of_invalid": "9E53A68FAC3C4051046A498E58C1C15E59CF306AAE8CC80D459A83EDF23E3BB4", "height_of_subjective": 503228, "hash_of_subjective": "8AD1E4F9C65A163312F344FDBDD17B71444D0EA42A12240F7401634AA45C6DD9", "reason": "wrong chain id: 'mocha-4' != 'celestia'"}
Relevant log output
No response
Notes
No response
The text was updated successfully, but these errors were encountered: