4 ms·

"With only two servers, the client can end up with proof that something is wrong, but no idea what the correct time is. But with half a dozen or more independen

by divbit 10y ago

"With only two servers, the client can end up with proof that something is wrong, but no idea what the correct time is. But with half a dozen or more independent servers, the client will end up with a chain of proof of any server's misbehaviour, signed by several others, and (presumably) enough accurate replies to establish what the correct time is." This sounds fairly similar to the 51% attack prevention in Bitcoin, and I think they could perhaps be more precise here. There are several other similarities which stuck out to me (note that bitcoin itself is a timestamp server, see section 3 of the whitepaper). Also they mention "We envision that clients will maintain a rolling window of signature chains and will be able to upload any proofs of misbehaviour," which also sounds bitcoin-ish at least to me.. (maybe my perception is skewed from spending lots of time in the space) I guess the question this leaves me with after reading is: could one get a reliable ~10 second accurate timestamp from the bitcoin blockchain or a modification of it?

Daviey 10y ago
"A man with a watch knows what time it is. A man with two watches is never sure." -- Segal's law
- viraptor 10y ago
  This doesn't seem to apply to time synchronisation really. Here, the more watches you have, the better your idea of what the time is.
wongarsu 10y ago
>This sounds fairly similar to the 51% attack prevention in Bitcoin With the advantage that in this case you can set an arbitrary threshold. You could for example only update your clock if 80% of your time servers agree on a time, or 90%, depending on your risk aversity. >could one get a reliable ~10 second accurate timestamp from the bitcoin blockchain or a modification of it? You are right that Bitcoin is essentially a timestamping system, but it only timestamps every ten minutes (some other cryptocoins go down to one minute). The protocol is also quite forgiving: you can back-date a block by up to rwo hours. There is also no mechanism for figuring out whether you have all the existing blocks, meaning any blockchain based timeserver could still be tricked into reporting an earlier date by preventing him from receiving the newest blocks. In short I think bitcoin (and other blockchain technology) is great for proving that information already existed on a certain day or even in a certain hour, but I don't think you can make a usable time-synchronization system out of them.
- divbit 10y ago
  >There is also no mechanism for figuring out whether you have all the existing blocks, meaning any blockchain based timeserver could still be tricked into reporting an earlier date by preventing him from receiving the newest blocks. I feel like what I was hinting at wouldn't quite work like this, but rather a timeserver in this system would do something like take an average of past block times, compare that with cpu time, and derive a best guess at the current time- obviously there is variance from block to block, but statistically might tend towards an accurate representation of time. Similarly, you could set your client to only update if 80-90% of the blockchain running servers agreed on the time.
  - wongarsu 10y ago
    >take an average of past block times, compare that with cpu time, and derive a best guess at the current time But how does that work if the attacker controls your network and prevents you from receiving any blocks newer than the first of april? He can even send you the next (still ancient) block from the blockchain every ten minutes, making everything look legitimate. If you are cold-starting and have only a vague idea of the date, then you can't defend against this. If you have a sufficiently good idea of the current time that this doesn't impact your threat model, you have already solved your timekeeping problem and don't need the blockchain technique anymore.
    - divbit 10y ago
      Presumably you can corrupt a couple of small networks on which bitcoin nodes are running and that wouldn't disrupt time for the entire chain and clients relying on it...

by divbit 10y ago

Daviey 10y ago

"A man with a watch knows what time it is. A man with two watches is never sure." -- Segal's law

viraptor 10y ago
This doesn't seem to apply to time synchronisation really. Here, the more watches you have, the better your idea of what the time is.

wongarsu 10y ago

>This sounds fairly similar to the 51% attack prevention in Bitcoin With the advantage that in this case you can set an arbitrary threshold. You could for example only update your clock if 80% of your time servers agree on a time, or 90%, depending on your risk aversity. >could one get a reliable ~10 second accurate timestamp from the bitcoin blockchain or a modification of it? You are right that Bitcoin is essentially a timestamping system, but it only timestamps every ten minutes (some other cryptocoins go down to one minute). The protocol is also quite forgiving: you can back-date a block by up to rwo hours. There is also no mechanism for figuring out whether you have all the existing blocks, meaning any blockchain based timeserver could still be tricked into reporting an earlier date by preventing him from receiving the newest blocks. In short I think bitcoin (and other blockchain technology) is great for proving that information already existed on a certain day or even in a certain hour, but I don't think you can make a usable time-synchronization system out of them.

divbit 10y ago
>There is also no mechanism for figuring out whether you have all the existing blocks, meaning any blockchain based timeserver could still be tricked into reporting an earlier date by preventing him from receiving the newest blocks. I feel like what I was hinting at wouldn't quite work like this, but rather a timeserver in this system would do something like take an average of past block times, compare that with cpu time, and derive a best guess at the current time- obviously there is variance from block to block, but statistically might tend towards an accurate representation of time. Similarly, you could set your client to only update if 80-90% of the blockchain running servers agreed on the time.
- wongarsu 10y ago
  >take an average of past block times, compare that with cpu time, and derive a best guess at the current time But how does that work if the attacker controls your network and prevents you from receiving any blocks newer than the first of april? He can even send you the next (still ancient) block from the blockchain every ten minutes, making everything look legitimate. If you are cold-starting and have only a vague idea of the date, then you can't defend against this. If you have a sufficiently good idea of the current time that this doesn't impact your threat model, you have already solved your timekeeping problem and don't need the blockchain technique anymore.
  - divbit 10y ago
    Presumably you can corrupt a couple of small networks on which bitcoin nodes are running and that wouldn't disrupt time for the entire chain and clients relying on it...