docs: danda's first read edits

docs/src/consensus.md

@@ -1,10 +1,10 @@
 # Consensus
 
-Neptune achieves succinctness by requiring STARK proofs to certify most of the consensus-critical logic. As a consequence, verifying and even running a full node is cheap. The tradeoff is that someone has to produce these STARK proofs, and this burden ultimately falls on the miner.
+Neptune achieves succinctness by requiring STARK proofs to certify most of the consensus-critical logic. As a consequence, verifying and even running a full node is cheap. The tradeoff is that someone has to produce these STARK proofs, and this burden ultimately falls most heavily on the miner (for aggregated block transactions) and to a lesser extent on the sender (for individual transactions).
 
 The particular proof system that Neptune uses is [Triton VM](https://triton-vm.org/). The particular computations that are proven (and verified) as part of consensus logic are documented here.
 
-Consensus is the feature of a network whose nodes overwhelmingly agree on the current contents of a database, typically a blockchain. This database is append-only. While reorganizations can happen they are expected to be rare and shallow. Every once in a while, a new block is added. The block contains, among other things, a transaction. [Block](./consensus/block.md)s and [Transaction](./consensus/transaction.md)s are the key data objects that consensus pertains to. The *consensus logic* determines which blocks and transactions are *valid* and *confirmable*.
+Consensus is the feature of a network whose nodes overwhelmingly agree on the current contents of a database, typically a blockchain. This database is append-only. While reorganizations can happen they are expected to be rare and shallow. Every once in a while, a new block is added. The block body contains a single transaction that aggregates together all inputs and outputs of individual user transactions since the previous block. [Block](./consensus/block.md)s and [Transaction](./consensus/transaction.md)s are the key data objects that consensus pertains to. The *consensus logic* determines which blocks and transactions are *valid* and *confirmable*.
 
 Note that there is a distinction between *valid* and *confirmable*. Validity refers to the internal consistency of a data object. Confirmable refers to its current relation to the rest of the blockchain. For example, having insufficient proof-of-work or including a double-spending transaction makes a block invalid. But a block can be both valid and unconfirmable, for instance if its timestamp is too far into the future. STARK proofs are capable of establishing validity but not confirmability.
 

docs/src/consensus/transaction.md

@@ -4,7 +4,7 @@ A transaction kernel consists of the following fields:
 
  - `inputs: Vec<RemovalRecord>` The commitments to the UTXOs that are consumed by this transaction.
  - `outputs: Vec<AdditionRecord>` The commitments to the UTXOs that are generated by this transaction.
- - `public_announcements: Vec<PublicAnnouncement>` One or many strings of data to broadcased to the world.
+ - `public_announcements: Vec<PublicAnnouncement>` a list of self-identifying strings broadcasted to the world. These may contain encrypted secrets but only the recipient(s) can ascertain that.
  - `fee: NeptuneCoins` A reward for the miner who includes this transaction in a block.
  - `coinbase: Option<NeptuneCoins>` The miner is allowed to set this field to a mining reward which is determined by various variable network parameters.
  - `timestamp: Timestamp` When the transaction took or takes place.
@@ -15,7 +15,7 @@ A transaction kernel consists of the following fields:
 A transaction is *valid* if (any of):
 
  - ***a)*** it has a valid witness (including spending keys and mutator set membership proofs)
- - ***b)*** it has valid proofs for each subprogram (subprograms establish things like the owners consent to this transaction, there is no inflation, etc.) 
+ - ***b)*** it has valid proofs for each subprogram (subprograms establish things like the owners consent to this transaction, there is no inflation, etc.)
  - ***d)*** it has a single valid proof that the entire witness is valid (so, a multi-claim proof of all claims listed in (b))
  - ***e)*** it has a single valid proof that the transaction originates from merging two valid transactions
  - ***f)*** it has a single valid proof that the transaction belongs to an integral mempool, *i.e.*, one to which only valid transactions were added
@@ -142,7 +142,7 @@ Two transactions can be merged into one. Among other things, this operation repl
 
 ### E: Proof of Integral Mempool Operation
 
-A transaction is valid if it was ever added to an integral mempool. The motivating use case for this feature is that mempool operators can delete transaction proofs as long as they store and routinely update one 
+A transaction is valid if it was ever added to an integral mempool. The motivating use case for this feature is that mempool operators can delete transaction proofs as long as they store and routinely update one
 
 An integral mempool is an MMR containing transactions *kernels*, along with a proof of integral history. The integral mempool can be updated in only one way: by appending a valid transaction.
  - `append : (old_mmr : Mmr<TransactionKernel>) × (old_history_proof: StarkProof) × (tx : Transaction) ⟶ (new_mmr : Mmr<TransactionKernel>) × (new_history_proof : StarkProof)`

docs/src/contributing/git-workflow.md

@@ -7,15 +7,13 @@ We follow a standard [GitHub Flow](https://docs.github.com/en/get-started/using-
 It can be visualized like this:
 
 ```
-master
--------*----------------------*>
- \             --------
-  \  dev      / topic  \
-   ----*----------------------*--------------->
-        \ release              \ release
-        ------------------>    --------->
-        \ hotfix /
-        --------
+            --------
+master     / topic  \
+----*----------------------*--------------->
+    \ release              \ release
+    ------------------>    --------->
+    \ hotfix /
+    --------
 ```
 
 ### master branch (aka trunk)

docs/src/neptune-core/events.md

@@ -1,7 +1,6 @@
 # Events
 
-The Neptune Core client can be seen as an event-driven client. Below is a list of all the events, and the messages that
-these events create.
+neptune-core can be seen as an event-driven program. Below is a list of all the events, and the messages that these events create.
 
 ## Events