Discussion: Soft block delay enforcement

[whyrusleeping]

Even if its susceptible to miners colluding to circumvent it, we should consider adding in block delay enforcement to the protocol. How this roughly works is each miner includes a timestamp in their block, and upon receiving blocks from other miners checks two things:

• the timestamp on the block is not in the future
• the timestamp on the block is at least 30 seconds higher than the latest of its parents

If the received block does not meet both conditions, it should be thrown away.

Pros:

• Enforces block time as long as miners don't collude and agree to ignore the rule
• Works even without VDFs
  Cons:
• Can be circumvented by rational miners who collude and agree to ignore the rule
• Requires miners have very well synchronized clocks

The alternative (or complementary) option is to have a 'good' VDF help enforce the delay.

[sternhenri]

Is this meant to be a fallback or "optimistic" solution to VDFs getting broken, or is this meant to replace VDFs altogether in the construction?

Registering some concern around the clock synchrony assumption: it's a pretty huge one, and it's hard to see how it's enforceable (in fact that's Fantomette's sole premise for using the VDF, and not "waiting is not rational" -> ie there is no block delay enforcement in fantomette, simply a VDF to ensure liveness, insofar as I have Sarah's model cached).

[whyrusleeping]

Yeah, the clock synchrony assumption sucks. Its the one many systems seem to be making (snow white, eth2.0, even eth1.0 for block time adjustment), and i'm uncomfortable with it. But without VDFs we can really rely on, it seems like a not-unreasonable fallback...

My intention would be to have it as a fallback, so we would also have a VDF.

[sternhenri]

I understand, but in that case do we even want the timestamp given it's exactly zero work to fake? Let's just rely on network delay in that case and we can allow folks to rush the chain if the VDF is not reliable... I just worry about adding security components we know don't hold up.

[whyrusleeping]

@sternhenri its not about faking it. Given the two rules I mentioned, faking it either means youre putting it in the future, or your setting it to less than 30 seconds, in both cases the block would be rejected by honest miners.

The primary worry with this approach is that other 'rational' miners would ignore the rules, and accept a block from the future (blocks with a timestamp delta of less than 30 seconds are always invalid)

[sternhenri]

Actually understood now, thank you. Maybe we can try to motivate this based on certain amounts of network compositions, see how much it helps with potentially realistic amounts of honest miners...

[sternhenri]

We should do this!

[whyrusleeping]

@sternhenri yes, we should. Even with a VDF, this provides us decent base level security (especially with a weak vdf that may be broken easily).

Not super applicable here, but heres how bitcoin uses timestamps: https://medium.com/@lopp/bitcoin-timestamp-security-8dcfc3914da6

[pooja]

Closed via #191