*glm 5.3*
1. Weak subjectivity: your correction is basically right
Your understanding matches the spec: it's not that others need to be "online as often as you," but that you must sync at least on...
This generally makes sense to me, except I don't think that glm 5.3 quite captured the sense in which I meant to anchor Ethereum to Bitcoin through OTS.
First, I agree beacon block roots are the right thing to timestamp. So suppose I've been timestamping beacon block roots from the real Ethereum chain on Bitcoin via OTS weekly, and I've been doing that for 20 years.
So 20 years later, I now want to hand someone the real chain plus evidence that it's the real one. I give them the chain as a candidate, together with the OTS proofs I've produced. Their client then checks two things: (i) the candidate chain verifies internally, with all signatures and protocol rules etc; and (ii) each beacon block root in the candidate comes with a valid OTS timestamp (which their client verifies against bitcoin) falling shortly after that root's claimed time. Their client accepts the history only if both tests pass.
So then an attacker can present a fake history, but the client will demand to also see the 20 years of OTS proofs for that fake chain's own beacon block roots. And the attacker cannot create these after the fact. For example, a timestamp from 2029 can only exist if the root existed in 2029. So the only type of attacker who can pass both tests is one who has been building and timestamping the fake chain in real time for the past 20 years. So fabricating a fake chain retroactively, in an instant, can no longer be done, the attacker must have been working on it for 20 years.
That was the point.
First, I agree beacon block roots are the right thing to timestamp. So suppose I've been timestamping beacon block roots from the real Ethereum chain on Bitcoin via OTS weekly, and I've been doing that for 20 years.
So 20 years later, I now want to hand someone the real chain plus evidence that it's the real one. I give them the chain as a candidate, together with the OTS proofs I've produced. Their client then checks two things: (i) the candidate chain verifies internally, with all signatures and protocol rules etc; and (ii) each beacon block root in the candidate comes with a valid OTS timestamp (which their client verifies against bitcoin) falling shortly after that root's claimed time. Their client accepts the history only if both tests pass.
So then an attacker can present a fake history, but the client will demand to also see the 20 years of OTS proofs for that fake chain's own beacon block roots. And the attacker cannot create these after the fact. For example, a timestamp from 2029 can only exist if the root existed in 2029. So the only type of attacker who can pass both tests is one who has been building and timestamping the fake chain in real time for the past 20 years. So fabricating a fake chain retroactively, in an instant, can no longer be done, the attacker must have been working on it for 20 years.
That was the point.
1
