It's not possible to efficiently assert anything among "all agents of your system" if "your system" permits open membership.

In particular, distributed systems cannot efficiently assert objective/wallclock timestamps by definition.

opentimestamps.org is comically naïve.

Yes, I'm definitely talking about databases with close memberships, but keep in mind that some seemingly "open membership" apps can still be implemented, some social networks come to mind, like chat apps, where each chat is a database, and all its participants are the agents. Maybe more sophisticated social networks like twitter could be implemented too, something like each post may be a database with it's own permissions and encrypted to for a group of accounts

Regarding the timestamps, I didn't give it much thought, I think there's room to complicate and solve some edge cases, but my main point was that it's ok to allow agents to manually solve conflicts.

> opentimestamps.org is comically naïve.

Can you elaborate?, I'm very interested, I have high regards with the idea of the project

> Every Bitcoin block header has a field in it called nTime. For a Bitcoin block to be accepted by the network the Bitcoin protocol requires that field to be set to approximately the time the block was created. Exactly how accurate that field must be for a block to be valid is a complex topic, but for our purposes it’s fair to say it’ll very likely be accurate to within two or three hours - even if a sizable minority of Bitcoin miners are trying to create invalid timestamps - and almost certainly within a day.

Distributed systems cannot make reliable assertions about wall-clock timestamps of operations by definition. Even BFT consensus on a given timestamp does not change this fact. This is the whole rationale behind things like Lamport and vector clocks! Anything building on the assertion quoted above is invalid.

> Thus we can say Bitcoin is a notary, and we can use Bitcoin block headers as time attestations: proof that a notary that we trust attested to the fact that some data existed at some point in time.

You can use headers as evidence that supports a time attestation, yes. But that evidence does not in any sense _prove_ the time is accurate! It's easy to construct a pathological condition -- not necessarily malicious, either! -- which breaks these assumptions.

In a distributed system there is no notion of "a point in [wall clock] time" by definition. Timestamps can be attached to events but they cannot be taken as authoritative.

Yeah agree, time is far from precise, and maybe not much useful for the use-case I mentioned

Tough I still think it is a really cool project, to me is the coolest use-case of blockchains beyond money (maybe the only one?)

If you don't want to trust anybody, you can ignore all time references, and just look at the proof of work on top of the attestation.

If you estimate the world's ability to generate proof of work, you can get a lower bound of how much time must have been passed in order to produce that proof, or estimate how much it cost, and you can be as conservative as you'd like, you'll still get a meaningful lower bound of time. Your only assumption is your own estimate

And from the proof of work point of view, it scales infinitely, you can put as many attestation as you can fit in a merkel tree into a single bitcoin transaction

> If you estimate the world's ability to generate proof of work, you can get a lower bound of how much time must have been passed in order to produce that proof, or estimate how much it cost, and you can be as conservative as you'd like, you'll still get a meaningful lower bound of time. Your only assumption is your own estimate

You literally can't! All you can get from this is a lower bound on the _reported_ amount of time. But there's no way, definitionally, to assert any constraint on the _actual_ time. This is my point.

I don't follow, why do you say "reported amount of time"?

You can ignore any time anybody ever reported, the only thing you need reported from others are the proof of work accumulated from the attestation block to the latest block

I think terminology might have gotten mixed up. Maybe my mistake. You can approximate duration, but wall-clock time is unknowable, is my point.

Is there a simple anything with distributed systems?

Only sometimes, and databases are notoriously picky because when something unexpected happens it can cause innumerable problems and pain.

Well, If you try to almost completely solve the consensus problem in the most intuitive way, you arrive to a blockchain level of complexity fast. So I think in this context "simple" seems reasonable