Update public/content/developers/docs/consensus-mechanisms/pos/index.md

Co-authored-by: Paul Wackerow <[email protected]>

Author: corwintines

public/content/developers/docs/consensus-mechanisms/pos/index.md

@@ -54,6 +54,7 @@ When the network performs optimally and honestly, there is only ever one new blo
 The threat of a [51% attack](https://www.investopedia.com/terms/1/51-attack.asp) still exists on proof-of-stake as it does on proof-of-work, but it's even riskier for the attackers. An attacker would need 51% of the staked ETH. They could then use their own attestations to ensure their preferred fork was the one with the most accumulated attestations. The 'weight' of accumulated attestations is what consensus clients use to determine the correct chain, so this attacker would be able to make their fork the canonical one. However, a strength of proof-of-stake over proof-of-work is that the community has flexibility in mounting a counter-attack. For example, the honest validators could decide to keep building on the minority chain and ignore the attacker's fork while encouraging apps, exchanges, and pools to do the same. They could also decide to forcibly remove the attacker from the network and destroy their staked ETH. These are strong economic defenses against a 51% attack.
 
 Beyond 51% attacks, bad actors might also attempt other types of malicious activities, such as:
+
 - long-range attacks (although the finality gadget neutralizes this attack vector)
 - short range 'reorgs' (although proposer boosting and attestation deadlines mitigate this)
 - bouncing and balancing attacks (also mitigated by proposer boosting, and these attacks have anyway only been demonstrated under idealized network conditions)