<spirobel:kernal.eu> > <@ofrnxmr> So, in practice, 5/7 have to match

<spirobel:kernal.eu> might as well make it 7/7 as there is most likely something bad happening in the case of a disagreement. If not fall back to longest chain. If checkpointing is active, the longest chain rule is superseded by the chain with the last checkpoint. If the majority of hashrate is connected to nodes with checkpointing active it is ce [... too long, see mrelay.p2pool.observer/e/iP_djL0KdWtKbWVl ]

<spirobel:kernal.eu> To fix this copy the function, delete the reorg on longest chain in one copy. In the other, delete the application of the checkpointing. Then add logic according to if the checkpointing flag is active. What about reorgs on longest chain rule between checkpoints? When checkpointing is active, we still want to reorg in between checkpoints, right?

<spirobel:kernal.eu> How often do we checkpoint? if we checkpoint every block, this ambiguity is resolved, somehow I had in my mind we would only checkpoint every 10th block for some reason. No idea why.

5/7 is needed due to dns latency

Right now checkpoints are issued at depth 2, at most eve try five minutes

<spirobel:kernal.eu> DataHoarder: okay so there is no need to reorg in between checkpoints

due to delays in DNS there might be reorgs

say checkpoint at 100 is published, then 102 (when checkpointer is at 104)

while 102 becomes consistent on DNS servers and caches a reorg can happen

when 102 becomes valid for each specific node, they'd reorg back

<spirobel:kernal.eu> to be more specific: to reorg according to longest chain rule in between checkpoints

between checkpoints the source / targets are fixed

genesis block is a checkpoint

target checkpoint may be in an altchain or threshold of

<spirobel:kernal.eu> okay great. So the ambiguity is removed. Who is currently working on this ? it is just mentioned in the PR as a separate issue