docs: rename bitvectors.md -> bitfields.md (#778)

Author: MegaRedHand

Diff for: docs/bitvectors.md renamed to docs/bitfields.md

@@ -119,7 +119,7 @@ There's a trick here: SSZ doesn't specify how to store a `bitvector` in memory a
 
 For this reason, we represent bitvectors in our node as big-endian binaries. That means that we reverse the bytes (a relatively cheap operation) and, for bit addressing, we just use the complementary index. An example:
 
-If we are still representing the number 259 (validators with index 0, 1, and 8 attested) we'll have the two following representations (note, elixir has a `bitstring` type that lets you address bit by bit and store several bits that's not a multiple of 8):
+If we are still representing the number 259 (validators with index 0, 1, and 8 attested) we'll have the two following representations (note, elixir has a `bitstring` type that lets you address bit by bit and store a number of bits that's not a multiple of 8):
 
 ```
 110000001 -> little-endian bit order

Diff for: docs/fork_choice.md

@@ -57,7 +57,7 @@ $$W_N = B_N + \sum_i^{i \in \text{children}[N]}W_i$$
 
 In the previous scheme, there are two rewards:
 
-- Proposer rewards, are given to a proposer when their block is included in the chain. This also adds an incentive for them to try to predict the most likely branch to be the canonical one.
+- Proposer rewards are given to a proposer when their block is included in the chain. This also adds an incentive for them to try to predict the most likely branch to be the canonical one.
 - Attester rewards, given if the blocks they attest to are included. They are smaller than proposer rewards.
 
 These incentives, however, are not enough. To maximize their likelihood of getting rewards, they may misbehave: