This is the discussion thread for KIP 6

Right now calculating the pruning point from block b POV is quite annoying: P is

```
Self::finality_depth()
+ Self::merge_depth_bound() * 2
+ 4 * Self::prev_mergeset_size_limit() * Self::ghostdag_k() as u64
+ 2 * Self::ghostdag_k() as u64
+ 2
```

and the difference between two pruning points is at least F, which makes calculations quite annoying.

Also, for KIP6 related calculations, we can’t easily calc `prev_posterity(b)`

because each block points to its pruning point, and `prev_posterity(b)`

is somewhere between `b`

and `b.pruning_point`

.

So I suggest:

- Change P to 3F (or the equivalent of 72 hrs)
- replacing the field
`b.pruning_point`

with`b.prev_posterity`

. - Optional: set the posterity period to 1 hour

This will also simplify the functions `are_pruning_points_in_valid_chain`

, `next_pruning_points_and_candidate_by_ghostdag_data`

and `are_pruning_points_violating_finality`

Another point is that because of the current structure we can’t validate finality violations of less than 2F when replacing a pruning point proof. This will fix it.

And to avoid the ambiguity of the field `b.pruning_point/prev_posterity`

, 72 hours after the HF we’ll hardcode the new pruning point and tell `are_pruning_points_in_valid_chain`

and `are_pruning_points_violating_finality`

to stop the check there

And unrelated suggestion: I suggest to replace the notion of `PoChM Merkle root`

with an MMR (of all blocks until `prev_posterity`

or even of the whole history). This should simplify the design