add intro

NetRNGs.md

@@ -183,6 +183,11 @@ fishermen, which sounds problematic.
 # Timing
 
 TODO: Comment on relative block time vs. more absolute synced clock times.
+  ability to have timeout that depend on network activity?  (relative absolute time??)
+  but think about the network conditions
+
+We seemingly need a bound on clock skew between validators, which
+we must enforce using the peer-to-peer network.
 
 ### RANDAO
 
@@ -199,3 +204,10 @@ slower than the overall network, but as their stake increases this
 rate goes up.  Ouroboros wants to prevent this initial slow start,
 but this requires 
 
+
+
+### Ideas
+
+Unavailability game
+Time or relative time signing
+

Polkadot_Finality_Gadget_v9000.md

@@ -279,7 +279,7 @@ In exchange for this, we get the property that we do not need to pay attention t
 
 ### Why have a primary?
 
-We only need the primary for liveness. We need some form of coordination to defeat the repeated vote splitting attack. The idea behind that attack is that if we are in a situation where almost 2/3 of voters vote for something an the rest vote for another, then the Byzantine voters can control when we see a supermajority for something. If they can carefully time this, they may be able to split the next vote. Without the primary, they could do this for prevotes, getting a supermajority for a block $B$ late, then split precommits so we don't see that it is impossible fo thre to be a supermajority for $B$ until late. If $B$ is not the best block given the last finalised block but $B'$  with the same block number, they could stop either from being finalised like this even if the (unknown) fraction of Byzantine players is small.
+We only need the primary for liveness. We need some form of coordination to defeat the repeated vote splitting attack. The idea behind that attack is that if we are in a situation where almost 2/3 of voters vote for something and the rest vote for another, then the Byzantine voters can control when we see a supermajority for something. If they can carefully time this, they may be able to split the next vote. Without the primary, they could do this for prevotes, getting a supermajority for a block $B$ late, then split precommits so we don't see that it is impossible fo thre to be a supermajority for $B$ until late. If $B$ is not the best block given the last finalised block but $B'$  with the same block number, they could stop either from being finalised like this even if the (unknown) fraction of Byzantine players is small.
 
 When the network is well-behaved, an honest primary can defeat this attack by deciding how much we should agree on. We could also use a common coin for the same thing, where poeple would prevote for either the best chain containing $E_{r-1,v}​$ or $g(V_{r-1,v})​$ depending on the common coin. With on-chain voting, it is possible that we could use probabilistic finality of the block production mechanism - that if we don't finalise a block and always build on the best hain containing the last finalised block then not only will the best chain eventually converge, but if a block is behind the head of the best chain, then with positive probability, it will eventually be in the best chain everyone sees.