The "BAD BLOCK" log is output every few minutes.

[fatminer]

System information

Geth version: geth version

Geth
Version: 1.4.8
Git Commit: f5ba30e
Architecture: amd64
Go Version: go1.21.9
Operating System: linux
GOPATH=
GOROOT=/usr/local/go

OS & Version: Windows/Linux/OSX

Linux 5.15.0-1036-aws #40~20.04.1-Ubuntu SMP Mon Apr 24 00:21:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Expected behaviour

Do not output logs indicating bad blocks if the blocks are valid.

Actual behaviour

The "BAD BLOCK" log is output every few minutes.
However, when I make a "getBlockByNumber" request for the corresponding block, the response comes back without any problems.

For example, the bad blocks in the following log can be seen in Explorer.
I'm confused because they are bad block but also valid block.

t=2024-06-20T08:13:45+0000 lvl=error msg="\n########## BAD BLOCK #########\nBlock: 39772307 (0x24f665aefa6a7266438a4a51a2ef56c95b0801a20931572e47f66a55ba70fae5)\nMiner: 0x75B851a27D7101438F45fce31816501193239A83\nError: missing withdrawals in block body\nPlatform: geth (devel) go1.21.9 amd64 linux\nVCS: f5ba30e-\nChain config: &params.ChainConfig{ChainID:56, HomesteadBlock:0, DAOForkBlock:, DAOForkSupport:false, EIP150Block:0, EIP155Block:0, EIP158Block:0, ByzantiumBlock:0, ConstantinopleBlock:0, PetersburgBlock:0, IstanbulBlock:0, MuirGlacierBlock:0, BerlinBlock:31302048, YoloV3Block:, CatalystBlock:, LondonBlock:31302048, ArrowGlacierBlock:, GrayGlacierBlock:, MergeNetsplitBlock:, ShanghaiTime:(*uint64)(0xc000131f28), KeplerTime:(*uint64)(0xc000131f30), FeynmanTime:(*uint64)(0xc000131f38), FeynmanFixTime:(*uint64)(0xc000131f40), CancunTime:(*uint64)(0xc000131f48), HaberTime:(*uint64)(0xc000131f50), PragueTime:(*uint64)(nil), VerkleTime:(*uint64)(nil), TerminalTotalDifficulty:, TerminalTotalDifficultyPassed:false, RamanujanBlock:0, NielsBlock:0, MirrorSyncBlock:5184000, BrunoBlock:13082000, EulerBlock:18907621, GibbsBlock:23846001, NanoBlock:21962149, MoranBlock:22107423, PlanckBlock:27281024, LubanBlock:29020050, PlatoBlock:30720096, HertzBlock:31302048, HertzfixBlock:34140700, Ethash:(*params.EthashConfig)(nil), Clique:(*params.CliqueConfig)(nil), Parlia:(*params.ParliaConfig)(0x46fbd30)}\nReceipts: \n##############################\n"

This seems to happen every time this validator generates a block.
0x75B851a27D7101438F45fce31816501193239A83

Steps to reproduce the behaviour

Occurs if it is running

[madhan5447]

Hi Team,
Am also facing same issue am using same version, i have checked,1.4.7,1.4.8 and 1.4.9 all the version same issue occur
Kindly share the solution for this issue

[AlexKNM]

Same here. The last versions are buggy like a hell.
t=2024-06-20T12:16:27+0000 lvl=error msg="Propagating invalid block" number=39777069 hash=0xc6552eb32f832af1394d5262411e33bc80f333af3415a9de3df9b79c1b2d3cfa err="miss
ing withdrawals in block body"
t=2024-06-20T12:16:27+0000 lvl=error msg="\n########## BAD BLOCK #########\nBlock: 39777069 (0xc6552eb32f832af1394d5262411e33bc80f333af3415a9de3df9b79c1b2d3cfa)\nMine
r: 0x5009317FD4F6F8FeEa9dAe41E5F0a4737BB7A7D5\nError: missing withdrawals in block body\nPlatform: geth (devel) go1.22.1 amd64 linux\nVCS: 4566ac7-20240611\nChain co
nfig: &params.ChainConfig{ChainID:56, HomesteadBlock:0, DAOForkBlock:, DAOForkSupport:false, EIP150Block:0, EIP155Block:0, EIP158Block:0, ByzantiumBlock:0, Const
antinopleBlock:0, PetersburgBlock:0, IstanbulBlock:0, MuirGlacierBlock:0, BerlinBlock:31302048, YoloV3Block:, CatalystBlock:, LondonBlock:31302048, ArrowGla
cierBlock:, GrayGlacierBlock:, MergeNetsplitBlock:, ShanghaiTime:(*uint64)(0xc0004e08e8), KeplerTime:(*uint64)(0xc0004e08f0), FeynmanTime:(*uint64)(0xc
0004e08f8), FeynmanFixTime:(*uint64)(0xc0004e0900), CancunTime:(*uint64)(0xc0004e0908), HaberTime:(*uint64)(0xc0004e0910), BohrTime:(*uint64)(nil), PragueTime:(*uint6
4)(nil), VerkleTime:(*uint64)(nil), TerminalTotalDifficulty:, TerminalTotalDifficultyPassed:false, RamanujanBlock:0, NielsBlock:0, MirrorSyncBlock:5184000, Bruno
Block:13082000, EulerBlock:18907621, GibbsBlock:23846001, NanoBlock:21962149, MoranBlock:22107423, PlanckBlock:27281024, LubanBlock:29020050, PlatoBlock:30720096, Her
tzBlock:31302048, HertzfixBlock:34140700, Ethash:(*params.EthashConfig)(nil), Clique:(*params.CliqueConfig)(nil), Parlia:(*params.ParliaConfig)(0x47616d0)}\nReceipts:
\n##############################\n"

[AlexKNM]

t=2024-06-20T12:39:42+0000 lvl=warn msg="Inserted known block" number=39777496 hash=0x90ddb49a6c82cc2cdac268b1753fd3dac692ac19cd4379c1fd5f4646abb0eb3d uncles=0 txs=18
4 gas=25521021 root=0x9d18da8c9c84ca5b3903e80f75226ea264e906de98d7248d24e4abf41c4f2e00
t=2024-06-20T12:39:42+0000 lvl=error msg="Please file an issue, skip known block execution without receipt" hash=0x90ddb49a6c82cc2cdac268b1753fd3dac692ac19cd4379c1fd5
f4646abb0eb3d number=39777496

[zzzckck]

It is caused by bad Erigon clients, many Erigon nodes have not upgraded to the latest release yet and they forwarded these bad blocks, try the following steps may help(PeerFilterPatterns is to filter out nodes based on their name):
// update 06-21:
// many BSC geth clients have not upgraded yet, v1.4.0 -> v1.4.4 has known issue, which will generate "BAD BLOCK".
// filter v1.4.4 may help

1.update your config.toml to add this option:

[Node.P2P]
PeerFilterPatterns = ["^erigon/v1.2.5.*|^Geth/v1.4.4.*"]

2.restart your node, then your nodes will reject connections from nodes named with "erigon/v1.2.5*"

[fatminer]

For example, this BAD BLOCK has the same block hash as the block information on BSCScan.

########## BAD BLOCK #########
Block: 39772307 (0x24f665aefa6a7266438a4a51a2ef56c95b0801a20931572e47f66a55ba70fae5)

https://bscscan.com/block/39772307

Does this mean that BSCScan is correct in BAD BLOCK?
or maybe Erigon clients are transferring the correct block as BAD BLOCK?

[ngotchac]

It is caused by bad Erigon clients

Why is the block with a given hash considered bad, but successfully imported right after?

[zzzckck]

For example, this BAD BLOCK has the same block hash as the block information on BSCScan.

########## BAD BLOCK #########
Block: 39772307 (0x24f665aefa6a7266438a4a51a2ef56c95b0801a20931572e47f66a55ba70fae5)

https://bscscan.com/block/39772307

Does this mean that BSCScan is correct in BAD BLOCK? or maybe Erigon clients are transferring the correct block as BAD BLOCK?

@fatminer @ngotchac well, the block hash is ok, but the block body has been polluted...
Validator generated good blocks with Empty withdraws in BlockBody, but after the block was processed by old Geth client(v1.4.0 -> v1.4.4), it changed the block body, set the WithDraws to nil. You "EmptyArray != nil", so check failed and report the BAD BLOCK error.
It is a known bug, fixed in v1.4.5, but there are still many BSC client not upgrade yet.

[madhan5447]

PeerFilterPatterns = ["^erigon/v1.2.5.|^Geth/v1.4.4."]

I tried this but didn't help for me kindly give the solution

[zzzckck]

PeerFilterPatterns = ["^erigon/v1.2.5.|^Geth/v1.4.4."]

I tried this but didn't help for me kindly give the solution

we have a hot fix PR: #2525, you may try the latest develop.
And we will release v1.4.10 for it, or you may wait for it, expected today.

[fatminer]

thanks!