4 ms·
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 all
by madacol 4y ago
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
- preseinger 4y ago> 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.
- madacol 4y agoYeah 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
- preseinger 4y ago> 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.
- madacol 4y agoI 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
- preseinger 4y agoI think terminology might have gotten mixed up. Maybe my mistake. You can approximate duration, but wall-clock time is unknowable, is my point.