Investigate mitigation of late publishing attacks

[m0ar]

Sidetree implementations are susceptible to late publishing attacks, which traditionally isn't a big issue if the only vector is changing the user's own keys. But here, having an old, anchored, and unpublished fork acts as a publish undo button.

Is there a way for the ceramic client to save old forks, and can a new client request full fork history from the network? Can we build some other transparent index allowing deterministic resolution in these cases?

[m0ar]

In parallel with some direct discussions with the Ceramic team, I created a forum thread in the protocol section around network communication of "archived tips": https://forum.ceramic.network/t/trace-verifiability-of-the-late-publishing-attacks/1392

[m0ar]

The planned multi-prev consensus change will make this much less impactful, potentially zero so:
CIP: https://cips.ceramic.network/CIPs/cip-145
Discussion: https://forum.ceramic.network/t/cip-145-multiple-previous-multi-prev/1277