Am I right that the goals of this protocol are primarily to reduce the finality time in comparison to Bitcoin as well as reduce the cost of running the system?

The image of how blocks are set up (https://cdn-images-1.medium.com/max/1000/1*fPsB4-t6J_1u1UpF37dYHw.png) reminds me strongly of the way blocks are chained in the "two-hop blockchain" (https://eprint.iacr.org/2016/716.pdf). I would like to see more in-depth comparisons to other consensus protocols, especially DPoS which seems particularly close in mechanism to Proof-of-Approval.

Your comparison table claims Proof-of-Approval is fully finalized after a single block,  however, you also talk about how there may be multiple top-level blocks where the "preferred" chain is unresolved. Doesn't this imply that your transaction being inside a valid block doesn't mean its been fully finalized? How do you reconcile that?

Since any node can produce a candidate block, this seems like it would potentially cause unbounded network traffic with everyone and their mother suggesting blocks to vote on. How is this resolved in the case of, say, an adversarial ddos attack? But I have the same question as monsterer2, why would anyone with stake approve the block of anyone without stake? In fact, why would anyone with stake approve *anyone* else's blocks? It seems there's no incentive to mine on top of someone else's blocks. This could manifest in more subtle attacks where you have stakeholders who refuse to mint on top of a competitor. It could also manifest in deadlock as nodes try to maximize their probability of winning the minted block.

I have a hard time seeing the purpose of having nodes pay attention to timestamps and comparing them to their receive-time. At its core, the mechanism is just voting, right? I don't see why the protocol doesn't just let nodes vote for whatever blocks they want. I see the appeal of a simple stake-voting process for block creation (similar to DPoS), but the Proof of Approval method seems like rational profit-seeking minters would make things devolve into the top 50% stakeholders passing around permission to mine the blocks, completely excluding the other 50%.

Also, could you provide a glossary of variables you use in this paper? Its hard for me to keep track of which variables mean what and find their definition in the prose when I need to refer to what they mean later.

@monsterer2 Are you suggesting that greater permissionlessness is desriable? Also, I've come to the conclusion that bootstrap poisoning can be entirely solved by blockchain checkpoints hardcoded into whatever software you use - since the software should be audited, and malicious software can make your client choose whatever chain it wants, hardcoded checkpoints don't reduce security in any meaningful way and yet completely remove the possibility of long range attacks including bootstrap poisoning.

Also @monsterer2 I would actually call your most recent proposed attack a 51% attack, since you *did* own a majority stake, and are using that fact to attack the network. I'd say its just an interesting twist on a 51% attack.