Jude Nelson

This is _NOT_ done. Nakamoto still uses `BURNCHAIN_TX_SEARCH_WINDOW` to find a limited number of prior burnchain blocks.

> Important note here: this logic can't apply to would-be PoX anchor blocks. If the signer set approves a block which would become an anchor block, they must force subsequent...

No, #4390 uses the stacks tip now in `load_nakamoto_reward_set()`. The test battery in #4390 create multiple PoX anchor blocks as part of the new systemic block malleablization in `TestPeer` and...

Right -- in #4390, the PoX reward set is chosen by whatever happens to be the canonical Stacks tip at the start of the reward phase. Assuming that at least...

Elaborating and simplifying this more -- it's sufficient to only require that `remote_tip_block_id` be the sighash _OR_ block ID. This is because the block identified by `remote_tip_block_id` already commits to...

This will be closed by #4930

Thanks for gathering these all together. I'll annotate these functions in a follow-on PR. From a cursory read, I think most if not all of these can be skipped since...

There is one consideration I've thought of. A malicious node could serve multiple different (and ultimately not confirmed) siblings of the chain tip to a victim node, and thus prevent...

Hmm, there might be something here. If there's N signers, and (for simplicity) suppose K < N of them are sufficient to sign the block, then a malicious node might...

I think the fix for this would be to only accept a sibling block that was otherwise identical if it had _more_ signatures than the last-accepted sibling. Then, an honest...