Use #3729 to improve miner leader election

[wileyj]

Looking at PR #3729 , i'm curious if it would be possible to use this RPC to essentially prevent miners with an older view of the network from attempting to mine?

would have to look more into how a miner is chosen, but i'm wondering if it's possible that in the leader election, one of the checks performed uses the RPC here to confirm that the miners view of the network matches the rest of the network.

i don't think this would resolve all cases where a miner is chosen that has an older view of the network, but i think it could reduce the frequency.

example:

Miner	local burnchain height	bootstrap burnchain height	elected as leader
minerA	700000	700001	false
minerB	700001	700001	true

in this example minerB is chosen as the block producer since minerA's local view of the burnchain is behind the view of minerB.

[wileyj]

after speaking to @pavitthrap this may not be doable because it would introduce an attack vector as-is (modify the code to report your health fraudulently, i.e. "my bitcoin height is higher than yours, so don't mine").

will have to think about this more

[marshallbtc]

I think I have a slightly different, but connected suggestion to what @wileyj proposed above.

Would it be plausible to hard fork the Stacks chain such that if there are two competing Stacks blocks at the same height, the one whose anchor block has the lower height is considered canonical?

What would be the consequences of this? Can the consequences be mitigated?

[friedger]

The consequences are that miners can withhold blocks and make the next winning miner produce a block that won't be part of the canonical chain.