Ok, got it. Won't waste anyone's time on terminology pedantism.
The model that I proposed above is simply what *any* correct timestamping service must do. If OTS does not follow that model, then I suspect whatever OTS is, is provably incorrect or, in this context, unreliable, even when servers and clients are honest. Unreliable might mean different things to different people, I'm happy to detail the types of unreliability issue that arise if you do not conform to the model I presented above (of which, linearizability is one way to address it, there are others that still implement epoch based recommitting that could be conceptually sound without requiring linearizability). Do you have any formal proof of what guarantees OTS provides against which threat model? This is likely difficult to produce without a formal model of what OTS is, but perhaps you can give your best shot at producing one and we can carry the conversation on productively from there.
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
