Make sure that we prefer own blocks over incoming blocks

[edsko]

When an upstream node and we ourselves are both elected leader, in the (admittedly unlikely) scenario that we receive the upstream block before we manage to produce our own, I think the current chain DB does not guarantee that we will prefer our own block -- but it should; this is a clear violation of the Ouroboros spec.

[edsko]

Note that clock skew cannot make this worse: although we might allow for clock skew in the chain sync client, the chain DB will store such "blocks from the future" but not adopt them.

See also #1150, especially #1150 (comment) .

[edsko]

The Praos protocol implementation (OuroborosTag instance) can guarantee this by preferring chains that are signed by itself (after all, it must know its own identity anyway in order to be able to decide if its a leader).

[edsko]

Note that this is not essential for the testnet: if two nodes are both producing a block, a fork is created in the chain, which must later be resolved; one of the two nodes is going to lose anyway and its block will be lost. Not implementing this ticket will mean that the second leader, if it gets the other block before it manages to produce its own (rather unlikely anyway), will just "resolve the fork" of its own accord.

[edsko]

Lowering this to medium priority since the probability of it happening is sufficiently unlikely and it won't break the system if we don't do it.

[mrBliss]

Lowering this to medium priority since the probability of it happening is sufficiently unlikely and it won't break the system if we don't do it.

Raising this to high priority again, because people might intentionally set their clocks ahead to increase the probability of this happening.

The Ouroboros spec stipulates: if there are multiple leaders for any given slot, you should prefer your own block.

We have a good way to handle it: in case of a tie in block numbers during chain selection, when the slots are equal, prefer the block we produced.

[nfrisby]

For future reference, we're not sure the spec specifies you should favor your own (eg the Praos paper does not obviously handle the case where the result of maxvalid includes the current slot). But the observation about accidentally motivating users to set their clock forward is reason enough.

Edit: I found a Slack thread in sl-ouroboros channel from 2020 July 1st in which Alexander Russell confirmed that preferring your own block is not crucial for correctness but it's a reasonable way to balanced the needs of the protocol versus incentivizing rational actors. Quoting, where "current rule" is this issue:

Yes--I think the current rule is a good trade-off. Here's the story we can tell ourselves:

• The rule is one for which we have a proof that the algorithm does the right thing. (In fact, any rule would be fine that first sorts chains according to length.)
• It doesn't conspicuously fly in the face of the incentive mechanism.