Closed manihagh closed 5 years ago
I have seen that this Parity PR: https://github.com/paritytech/parity-ethereum/commit/037fd1b309d7769e8eb9f5d8dc54978c158c4fdb
introduced a bug that has been fixed 6 days ago: https://github.com/paritytech/parity-ethereum/pull/10587
probably will disappear in the next release, let's wait and see.
Happens quite frequent another evidence below (parity 2.3.9 stable):
Imported #35794 0x665b…b53b (0 txs, 0.00 Mgas, 4 ms, 0.55 KiB)
2019-04-17 23:33:15 Imported #35795 0x40cf…3922 (0 txs, 0.00 Mgas, 4 ms, 0.55 KiB)
2019-04-17 23:33:20 Imported #35796 0xe7a1…d138 (0 txs, 0.00 Mgas, 2 ms, 0.55 KiB)
2019-04-17 23:33:20 4/25 peers 6 MiB chain 25 MiB db 0 bytes queue 271 KiB sync RPC: 0 conn, 1 req/s, 25 µs
2019-04-17 23:33:24 Stage 1 block verification failed for 0x748b…cebc: Error(Block(TimestampOverflow), State { next_error: None, backtrace: InternalBacktrace { backtrace: None } })
2019-04-17 23:33:24
Bad block detected: TimestampOverflow
RLP: f9022cf90227a0e7a1054e62c3de73c66ff04bd9f143e1d5f9b084f48c1edcc8bba659685cd138a01dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d4934794dae561c716f9ea58e32e37d9ae95465eca286012a0489040630bfb6da5d3bb1552455a6377a01725083955e87432b47287f13707b4a056e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421a056e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421b901000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090fffffffffffffffffffffffffffffffe828bd5837a120080845cb79ba58367737984128b1f21b8413e27700d8c8aa3bbf266899099942fe2d2a87d160ed0b18795a86fd1dc2b6579032267050ddeab64975f2b082b7716903f78790a70affef17ff727ee6a5e23a500c0c0
Header: Header { parent_hash: 0xe7a1054e62c3de73c66ff04bd9f143e1d5f9b084f48c1edcc8bba659685cd138, timestamp: 1555536805, number: 35797, author: 0xdae561c716f9ea58e32e37d9ae95465eca286012, transactions_root: 0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421, uncles_hash: 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347, extra_data: [103, 115, 121], state_root: 0x489040630bfb6da5d3bb1552455a6377a01725083955e87432b47287f13707b4, receipts_root: 0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421, log_bloom: 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, gas_used: 0, gas_limit: 8000000, difficulty: 340282366920938463463374607431768211454, seal: [[132, 18, 139, 31, 33], [184, 65, 62, 39, 112, 13, 140, 138, 163, 187, 242, 102, 137, 144, 153, 148, 47, 226, 210, 168, 125, 22, 14, 208, 177, 135, 149, 168, 111, 209, 220, 43, 101, 121, 3, 34, 103, 5, 13, 222, 171, 100, 151, 95, 43, 8, 43, 119, 22, 144, 63, 120, 121, 10, 112, 175, 254, 241, 127, 247, 39, 238, 106, 94, 35, 165, 0]], hash: Some(0x748b407501ddfee8a7471ca17183799aed0ce8045618a81e7d8fc5be3701cebc) }
Uncles:
Transactions:
2019-04-17 23:33:50 0/25 peers 6 MiB chain 25 MiB db 0 bytes queue 271 KiB sync RPC: 0 conn, 1 req/s, 27 µs 2019-04-17 23:34:20 0/25 peers 6 MiB chain 25 MiB db 0 bytes queue 271 KiB sync RPC: 0 conn, 1 req/s, 28 µs 2019-04-17 23:34:50 0/25 peers 6 MiB chain 25 MiB db 0 bytes queue 271 KiB sync RPC: 0 conn, 1 req/s, 28 µs 2019-04-17 23:35:20 0/25 peers 6 MiB chain 25 MiB db 0 bytes queue 271 KiB sync RPC: 0 conn, 1 req/s, 27 µs 2019-04-17 23:35:50 0/25 peers 6 MiB chain 25 MiB db 0 bytes queue 271 KiB sync RPC: 0 conn, 1 req/s, 27 µs 2019-04-17 23:36:20 0/25 peers 6 MiB chain 25 MiB db 0 bytes queue 271 KiB sync RPC: 0 conn, 1 req/s, 24 µs
Related to #10
I had the same problems with a global poa network with nodes in aws and azure. The network uses dynamic validators over a validator contract. Every node on the cloud worked without problems. My local parity node on mac runs very instable. After I install chronyd on my mac and synchronize the time not over the apple time server, everything works fine.
The error messages did depend on the parity version I used. If I use the last stable, I did get “Bad block detected: TimestampOverflow with a blocktrace”. If I used v2.3.3 I did get “Bad block detected: TemporarilyInvalid(OutOfBounds”.
With v2.4.5 I lost also every time that happened the peers.
I hope this info’s are use full.
We (@marcelorocha-e) are testing this possible fix: https://github.com/paritytech/parity-ethereum/pull/10720
Solved in Parity v2.4.8
Starting parity clean with no db and get this after a while: