KIP 6 discussion thread

1

This is the discussion thread for KIP 6

2

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:

  1. Change P to 3F (or the equivalent of 72 hrs)
  2. replacing the field b.pruning_point with b.prev_posterity.
  3. 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.

@missutton @Deshe2

3

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

4

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