parent-grinding fault overcheck

[llifezou]

Checklist

• This is not a security-related bug/issue. If it is, please follow please follow the security policy.
• This is not a question or a support request. If you have any lotus related questions, please ask in the lotus forum.
• This is not a new feature request. If it is, please file a feature request instead.
• This is not an enhancement request. If it is, please file a improvement suggestion instead.
• I have searched on the issue tracker and the lotus forum, and there is no existing related issue or discussion.
• I am running the Latest release, or the most recent RC(release canadiate) for the upcoming release or the dev branch(master), or have an issue updating to any of these.
• I did not make any code changes to lotus.

Lotus component

• lotus daemon - chain sync
• lotus miner - mining and block production
• lotus miner/worker - sealing
• lotus miner - proving(WindowPoSt)
• lotus miner/market - storage deal
• lotus miner/market - retrieval deal
• lotus miner/market - data transfer
• lotus client
• lotus JSON-RPC API
• lotus message management (mpool)
• Other

Lotus Version

lotus version 1.13.3-dev+mainnet+git.89912598a.dirty
lotus-miner version 1.13.3-dev+mainnet+git.89912598a.dirty

Describe the Bug

Continuously generate blocks, the first block is invalid (including the wrong parent block), causing the second block to fail.

Logging Information

block 1371234 daemon info:

2021-12-14T00:57:00.000Z	WARN	chain	chain/sync.go:851	(fork detected) synced header chain ([bafy2bzacebfgqbzoeybjseiedqckxizb64oqtp5rht3zbz75z2vmckkx5p3ek] - 1371234) does not link to our best block ([bafy2bzacedjff7pulrabv3e67l7ghnqk27bmt4jxizo2ba4oxacci2woaqtrg bafy2bzaced423wkmticxeqyo7sq4mql5hojix544azokt2fs2t6ozyv3hjelw bafy2bzaceayuutfrhlr2iho7mizjjp7xeye7z5rucmhzea3ja3ada3vb4vdkw bafy2bzaced6nr2rymejjko5fwaehhol6iqbd2qlinmobtie7qyrr3zxy4bpi4] - 1371233)

2021-12-14T00:57:00.291Z	INFO	chain	chain/sync_manager.go:232	selected sync target: [bafy2bzacedy5z2zeumlj7qaw4umvqht2yczuhoao4aout3hjeko5uyuxe3qwc]

2021-12-14T00:57:00.291Z	INFO	chain	chain/sync_manager.go:314	worker 824254 syncing in [bafy2bzacedy5z2zeumlj7qaw4umvqht2yczuhoao4aout3hjeko5uyuxe3qwc]

2021-12-14T00:57:00.331Z	INFO	chain	chain/sync_manager.go:232	selected sync target: [bafy2bzacedmeufhg4rdf3d63znvfnuykkjn2qudgrs7zgddx4ufamaspbqnfe]

2021-12-14T00:57:00.331Z	INFO	chain	chain/sync_manager.go:314	worker 824255 syncing in [bafy2bzacedmeufhg4rdf3d63znvfnuykkjn2qudgrs7zgddx4ufamaspbqnfe]

2021-12-14T00:57:00.528Z	INFO	chain	chain/sync.go:624	block validation	{"took": 0.232163025, "height": "1371234", "age": 0.528918813}

2021-12-14T00:57:00.529Z	INFO	chainstore	store/store.go:646	New heaviest tipset! [bafy2bzacedy5z2zeumlj7qaw4umvqht2yczuhoao4aout3hjeko5uyuxe3qwc] (height=1371234)

2021-12-14T00:57:00.529Z	INFO	chain	chain/sync_manager.go:322	worker 824254 done; took 237.874245ms

2021-12-14T00:57:00.594Z	INFO	chain	chain/sync.go:624	block validation	{"took": 0.260048234, "height": "1371234", "age": 0.594833268}
 
2021-12-14T00:57:00.595Z	INFO	chainstore	store/store.go:646	New heaviest tipset! [bafy2bzacedy5z2zeumlj7qaw4umvqht2yczuhoao4aout3hjeko5uyuxe3qwc bafy2bzacedmeufhg4rdf3d63znvfnuykkjn2qudgrs7zgddx4ufamaspbqnfe] (height=1371234)

2021-12-14T00:57:00.595Z	INFO	chain	chain/sync_manager.go:322	worker 824255 done; took 263.965282ms

2021-12-14T00:57:01.214Z	INFO	chain	chain/sync.go:624	block validation	{"took": 0.218540832, "height": "1371234", "age": 1.21495859}


block 1371234 miner info:
2021-12-14T08:56:52.646+0800	INFO	miner	miner/miner.go:604	mined new block	{"cid": "bafy2bzacebfgqbzoeybjseiedqckxizb64oqtp5rht3zbz75z2vmckkx5p3ek", "height": 1371234, "miner": "f0154335", "parents": ["f024563","f0694928","f0520520"], "parentTipset": "{bafy2bzaced423wkmticxeqyo7sq4mql5hojix544azokt2fs2t6ozyv3hjelw,bafy2bzaceayuutfrhlr2iho7mizjjp7xeye7z5rucmhzea3ja3ada3vb4vdkw,bafy2bzaced6nr2rymejjko5fwaehhol6iqbd2qlinmobtie7qyrr3zxy4bpi4}", "took": 2.382620039}


block 1371235 miner info:
2021-12-14T08:57:22.223+0800	INFO	miner	miner/miner.go:604	mined new block	{"cid": "bafy2bzaced5lrztrwr4yxuhhkpsyswgb3aiowp4ssvj45c2rm57vqgm6mubgw", "height": 1371235, "miner": "f0154335", "parents": ["f02303","f02420"], "parentTipset": "{bafy2bzacedy5z2zeumlj7qaw4umvqht2yczuhoao4aout3hjeko5uyuxe3qwc,bafy2bzacedmeufhg4rdf3d63znvfnuykkjn2qudgrs7zgddx4ufamaspbqnfe}", "took": 2.364427597}

2021-12-14T08:57:30.001+0800	ERROR	miner	miner/miner.go:341	<!!> SLASH FILTER ERROR: produced block would trigger 'parent-grinding fault' consensus fault; miner: f0154335; bh: bafy2bzaced5lrztrwr4yxuhhkpsyswgb3aiowp4ssvj45c2rm57vqgm6mubgw, expected parent: bafy2bzacebfgqbzoeybjseiedqckxizb64oqtp5rht3zbz75z2vmckkx5p3ek

The block 1371234 is not recognized by the network, this block is invalid (less parent block is included), so, when mine 1371235 block, the `parent-grinding fault` should not be checked

Repo Steps

1.Continuously generate blocks
2.the first block is invalid (including the wrong parent block), causing the second block to fail.

[jennijuju]

@llifezou We havent seen any other similar reports with the lotus release. seems like you are running a custom lotus version, could you please tell us what exactly did you change before we take a deeper look here?

[github-actions]

Oops, seems like we needed more information for this issue, please comment with more details or this issue will be closed in 24 hours.

[github-actions]

This issue was closed because it is missing author input.

[llifezou]

I didn't make any factual changes to the mining module, I just added some logs to give me more clarity on the running status

[llifezou]

The situation is as follows: two blocks are mined in a row, the first block contains one less parent block because my daemon is not completely synchronized, and then, my second block must contain My first block, which will cause me to lose the second block (the first block contains less of the parent block, it is invalid, but the second block has to contain this invalid block, otherwise Can't commit, it's overchecked)

[llifezou]

@jennijuju

[llifezou]

The relevant code is as follows:：

miner/miner.go

https://github.com/filecoin-project/lotus/blob/master/miner/miner.go#L328

// Check here whether the mined blocks meet the consensus requirements
if err := m.sf.MinedBlock(ctx, b.Header, base.TipSet.Height()+base.NullRounds); err != nil {
				log.Errorf("<!!> SLASH FILTER ERROR: %s", err)
				if os.Getenv("LOTUS_MINER_NO_SLASHFILTER") != "_yes_i_know_i_can_and_probably_will_lose_all_my_fil_and_power_" {
					continue
				}
			}

chain/gen/slashfilter/slashfilter.go

https://github.com/filecoin-project/lotus/blob/master/chain/gen/slashfilter/slashfilter.go#L64

func (f *SlashFilter) MinedBlock(bh *types.BlockHeader, parentEpoch abi.ChainEpoch) error {
	// ...
	{
		// parent-grinding fault (didn't mine on top of our own block)

		// First check if we have mined a block on the parent epoch
		parentEpochKey := ds.NewKey(fmt.Sprintf("/%s/%d", bh.Miner, parentEpoch))
		have, err := f.byEpoch.Has(parentEpochKey)
		if err != nil {
			return err
		}

		if have {
			// If we had, make sure it's in our parent tipset
			cidb, err := f.byEpoch.Get(parentEpochKey)
			if err != nil {
				return xerrors.Errorf("getting other block cid: %w", err)
			}

			_, parent, err := cid.CidFromBytes(cidb)
			if err != nil {
				return err
			}

			var found bool
			for _, c := range bh.Parents {
				if c.Equals(parent) {
					found = true
				}
			}

			if !found {
				return xerrors.Errorf("produced block would trigger 'parent-grinding fault' consensus fault; miner: %s; bh: %s, expected parent: %s", bh.Miner, bh.Cid(), parent)
			}
		}
	}
	// ...
	return nil
}

The scenario is as follows: I mine two blocks in a row, the first block is finally rejected by the network due to the lack of a parent block, but it is recorded in func (f *SlashFilter) MinedBlock , when checking the second block, the second block is correct (not including mine to invalid parent block), but was rejected here

[github-actions]

Oops, seems like we needed more information for this issue, please comment with more details or this issue will be closed in 24 hours.

[llifezou]

Oops, seems like we needed more information for this issue, please comment with more details or this issue will be closed in 24 hours.

If any data is needed, I'm willing to help

[github-actions]

Oops, seems like we needed more information for this issue, please comment with more details or this issue will be closed in 24 hours.

[github-actions]

This issue was closed because it is missing author input.

[ZenGround0]

The situation is as follows: two blocks are mined in a row

Are they mined in the same epoch or in subsequent epochs n and n+1?

the first block contains one less parent block because my daemon is not completely synchronized

What has not yet been fully synchronized? The parents of the first block? Is it common for block mining to begin without fully synchronizing an epoch?

my second block must contain My first block, which will cause me to lose the second block (the first block contains less of the parent block, it is invalid, but the second block has to contain this invalid block

I'm confused about this situation. If you could use "is the parent" of instead of "contain" it would probably help. If you could sketch a diagram of what's happening it would also help.

[ZenGround0]

I think what you are describing is the following. There is an incomplete base tipset P at epoch i. A miner wins a block A on top of P at epoch i+1 and releases it. However the full tipset at i is agreed upon by the rest of the network to be P' which is all of the blocks in P along with some other blocks not in P. The same miner then wins a block B at epoch i+2 and the block has grandparent P'. This appears to be exactly the situation parent grinding consensus faults exist to prevent, so I believe lotus's current behavior is as specified by the protocol.

[llifezou]

Are they mined in the same epoch or in subsequent epochs n and n+1?

subsequent epochs n and n+1

What has not yet been fully synchronized? The parents of the first block? Is it common for block mining to begin without fully synchronizing an epoch?

not common, but occasionally

I'm confused about this situation. If you could use "is the parent" of instead of "contain" it would probably help. If you could sketch a diagram of what's happening it would also help.

I use epoch example with height 100 and 101:
My miner got block rights at both 100 epoch and 101 epoch, but my 100 epoch calculated block was not accepted by the network because a parent was missing; when calculating the 101 epoch block, I correctly pointed to all parent, but did not pass the parent grinding consensus check, because the parent grinding consensus requires that my 100epoch must be the parent of 101 epoch, but my block of 100 epoch is an orphan block，so 101 epoch will also be lost

[ZenGround0]

Moving discussion to fips discussion