search

MinaProtocol / mina

Mina is a cryptocurrency protocol with a constant size blockchain, improving scaling while maintaining decentralization and security.
https://minaprotocol.com
Apache License 2.0
1.99k stars 527 forks source link

Ensure system time is synchronized #1494

Closed enolan closed 3 years ago

enolan commented 5 years ago

We need the system time to be synchronized with reality, so we only accept new blocks when the current time in within some reasonable delay of the claimed slot, so we only propose at the correct times, and so that trust score decay + unbanning is accurate.

We could check on startup that ntpd or something is running, or we could wrap the Time module and run an NTP client in the coda daemon. The former would be a pain for users, the latter is a pain for us. Maybe there's a better solution? I suppose we could ship an ntpd with the coda binary, but the user that runs the daemon won't have permission to change the system time and telling people to run stuff with sudo is dodgy.

enolan commented 5 years ago

Possibly relevant:

https://roughtime.googlesource.com/roughtime https://github.com/ioerror/tlsdate

enolan commented 5 years ago

If we decide to do this in-process, we could use RDTSC, provided we require users' processors are sufficiently recent. Using an offset from the system clock would be unreliable if something outside of Coda modifies it.

jkrauska commented 5 years ago

@enolan I don't think we should include time sync capabilities in our code. It's complicated and tricky. And that's better handled externally by well known tools. It's also super tricky to do this cross platform.

I think we /should/ let the user know when we think their time is off.

eg. WARNING: Received X messages from Y unique hosts with timestamps > Z s different from ours. Please check your local clock and use NTP.

Come up with your own heuristic to try to dismiss attacks... (assuming we already do this in trust)

If you think 'everyone' is attacking you with offset clocks, you might better think about checking your own clock...

enolan commented 5 years ago

The scenario where this is relevant is when the attacker controls the network. In that case she can generate and send transitions that have the "correct", fake, timestamp.

On Fri, May 17, 2019, 10:58 AM Joel Krauska notifications@github.com wrote:

@enolan https://github.com/enolan I don't think we should include time sync capabilities in our code. It's complicated and tricky. And that's better handled externally by well known tools. It's also super tricky to do this cross platform.

I think we /should/ let the user know when we think their time is off.

eg. WARNING: Received X messages from Y unique hosts with timestamps > Z s different from ours. Please check your local clock and use NTP.

Come up with your own heuristic to try to dismiss attacks... (assuming we already do this in trust)

If you think 'everyone' is attacking you with offset clocks, you might better think about checking your own clock...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CodaProtocol/coda/issues/1494?email_source=notifications&email_token=AAAPATJKPUWYLNBRICO4NBLPV3W5JA5CNFSM4GR7DIEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVVOFTA#issuecomment-493544140, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAPATICLZOVZ46QIWZOVPDPV3W5JANCNFSM4GR7DIEA .

enolan commented 4 years ago

This got archived out of the prioritization board for some reason. We need some version of it, along with a decent answer to #3232.

enolan commented 4 years ago

If the attack scenario is the attacker controlling the network, then NTP and rdate are both insufficient since they are unauthenticated and thus vulnerable to MITM. tlsdate or a clone thereof, taking the median of results from a reasonable set of sources would be OK.