Spec precise VRF use in EC

actors.md

@@ -1092,6 +1092,45 @@ func ChangeWorker(addr Address) {
 }
 ```
 
+#### `IsLate`
+
+IsLate checks whether the miner has submitted their PoSt on time (i.e. not after ProvingPeriodEnd).
+
+**Parameters**
+
+```sh
+type IsLate struct {
+} representation tuple
+```
+
+**Algorithm**
+
+```go
+func IsLate() (bool) {
+    return self.provingPeriodEnd < VM.CurrentBlockHeight()
+}
+```
+
+#### `IsSlashed`
+
+Checks whether the miner has been slashed and not recovered. Note that if the miner is slashed and recovers, this will return False: it checks current state rather than historical occurence.
+
+**Parameters**
+
+```sh
+type IsSlashed struct {
+} representation tuple
+```
+
+**Algorithm**
+
+```go
+func IsSlashed() (bool) {
+    # SlashedAt is reset on recovery
+    return self.SlashedAt > 0
+}
+```
+
 ### Payment Channel Actor
 
 - **Code Cid:** `<codec:raw><mhType:identity><"paych">`

data-structures.md

@@ -81,35 +81,53 @@ type BlockHeader struct {
 } representation tuple
 ```
 
+## VRF Personalization
+
+We define VDF personalizations as follow, to enable domain separation across operations that make use of the same VRF (e.g. [Ticket](#ticket) and [ElectionProof](#electionproof)).
+
+| Type          | Prefix |
+| ------------- | ------ |
+| Ticket        | `0x01` |
+| ElectionProof | `0x02` |
+
 ## Ticket
 
 A ticket is a shared random value stapled to a particular block in the chain. Every miner must produce a new ticket each time they run a leader election attempt. In that sense, every new block produced will have one or more associated tickets (in the case the block took multiple leader election attempts to produce).
 
-```go
+We use an [EC-VRF per Goldberg et al.](https://tools.ietf.org/html/draft-irtf-cfrg-vrf-04#page-10) with Secp256k1 and sha256 to obtain a deterministic, pseudorandom output.
+
+```sh
 type Ticket struct {
-	// TODO HS
-  // This signature is generated by the miner's keypair run on a past ticket in the ticket chain
-  VRFResult Signature
 
-  // The VRFProof proves that the VRFResult was appropriately generated from a past ticket by the miner generating this ticket.
-  VRFProof BigInteger
+  ## The VRFProof (pi_string in the RFC) is generated by running our VRF on a past ticket in the ticket chain signed with the miner's keypair.
+  ## 97 Bytes long (may be compressible to 80)
+  VRFProof Bytes
 
-  // The VDFResult is derived from the VRFResult of the ticket
-  // It is the value that will be used to generate future tickets or ElectionProofs
-  VDFResult BigInteger
+  ## The VDFResult is derived from the VRFResult of the ticket
+  ## It is the value that will be used to generate future tickets or ElectionProofs
+  VDFResult Bytes
 
-  // The VDF proves a delay between tickets generated
-  VDFProof BigInteger
+  ## The VDF proves a delay between tickets generated
+  VDFProof Bytes
 } representation tuple
 ```
 
+### Min Ticket/Ticket Comparison
+
+The ticket is a struct. Whenever the protocol draws the ticket or in any way uses ticket values (notably in crafting PoSts or running leader election), what is meant is that the Bytes of the `VDFResult` are used.
+
+Ticket comparison is done using the VDFResult as an unsigned integer (little endian).
+
+
 ## ElectionProof
 
 An election proof is generated from a past ticket (chosen based on public network parameters) by a miner during the leader election process. Its output value determines whether the miner is elected leader and may produce a block. Its inclusion in the block allows other network participants to verify that the block was mined by a valid leader.
 
-```go
+```sh
 type ElectionProof struct {
-  // TODO HS
+  ## The VRFProof is generated by running our VRF on a past ticket in the ticket chain signed with the miner's keypair.
+  ## 97 Bytes long (may be compressible to 80)
+  VRFProof Bytes
 }
 ```
 

definitions.md

@@ -161,20 +161,18 @@ A piece is a portion of a file that gets fitted into a sector.
 
 Security Parameter. Polling time is the time between two online PoReps in a PoSt proof.
 
+#### Power
+
+See `Power Fraction`.
+
 #### Power Fraction
 
-A miner's `Power Fraction` is the ratio of their committed storage over Filecoin's committed storage. It is used in leader election.
+A miner's `Power Fraction` or `Power` is the ratio of their committed storage as of their last PoSt submission over Filecoin's total committed storage as of the current block. It is used in leader election.
 
 ####  Power table
 
 The power table is an abstraction provided by the Filecoin storage market that lists the `power` of every miner in the system.
 
-#### Power table lookback
-
-Security parameter. A number of rounds to sample back from when determining miner `power` for use in leader election. A higher number can help secure the system by making potential attacks more costly (as power must be maintained for longer to take effect), but also makes mining more costly for the same reason.
-
-Also referred to as `L` in consensus settings. 
-
 #### Protocol
 
 #### Proving Period
@@ -251,9 +249,11 @@ In the context of:
 
 A `ticket` is used as a source of randomness in EC leader election. Every block depends on an `ElectionProof` derived from a `ticket`. At least one new `ticket` is produced with every new block. Ticket creation is described [here](./expected-consensus.md#Ticket-generation).
 
+Ticket comparison is done by interpreting the tickets' Bytes as unsigned integers (little endian representation).
+
 #### TipSet
 
- A `TipSet` is a set of blocks that have the same parent set and same number of `tickets`, which implies they will have been mined at the same `height`. A `TipSet` can contain multiple blocks if more than one miner successfully mines a block in the same `round` as another miner.
+A `TipSet` is a set of blocks that have the same parent set and same number of `tickets`, which implies they will have been mined at the same `height`. A `TipSet` can contain multiple blocks if more than one miner successfully mines a block in the same `round` as another miner.
 
 #### Verifiable