08:30:52 > <@ofrnxmr> So, in practice, 5/7 have to match 08:30:52 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 https://mrelay.p2pool.observer/e/iP_djL0KdWtKbWVl ] 08:36:14 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? 08:38:47 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. 12:04:33 5/7 is needed due to dns latency 12:05:04 Right now checkpoints are issued at depth 2, at most eve try five minutes 13:14:34 DataHoarder: okay so there is no need to reorg in between checkpoints 13:15:14 due to delays in DNS there might be reorgs 13:15:35 say checkpoint at 100 is published, then 102 (when checkpointer is at 104) 13:15:55 while 102 becomes consistent on DNS servers and caches a reorg can happen 13:16:09 when 102 becomes valid for each specific node, they'd reorg back 13:17:09 to be more specific: to reorg according to longest chain rule in between checkpoints 13:17:29 between checkpoints the source / targets are fixed 13:17:38 genesis block is a checkpoint 13:18:27 target checkpoint may be in an altchain or threshold of 13:23:28 okay great. So the ambiguity is removed. Who is currently working on this ? it is just mentioned in the PR as a separate issue