Typos and clarifications

zip-0317.rst

@@ -36,14 +36,14 @@ Abstract
 ========
 
 The goal of this ZIP is to change the conventional fees for transactions
-and get buy-in from wallet developers, miners and Zcash users.
+and get buy-in from wallet developers, miners, and Zcash users.
 
 
 Motivation
 ==========
 
-In light of recent network activity, it is time to review and update the
-standard 1,000 zatoshi transaction fee set in ZIP 313 [#zip-0313]_.
+In light of recent Mainnet network activity, it is time to review and update
+the standard 1,000 zatoshi transaction fee set in ZIP 313 [#zip-0313]_.
 
 The conventional transaction fee presently is 0.00001 ZEC or 1,000 zatoshis, as
 specified in ZIP 313. This allowed exploration of novel use cases of the Zcash
@@ -51,13 +51,13 @@ blockchain. The Zcash network has operated for almost 2 years at a conventional
 transaction fee of 1,000 zatoshis, without consideration for the total number
 of inputs and outputs in each transaction. Under this conventional fee, some
 usage of the chain has been characterized by high-output transactions with
-1,100 outputs paying the same conventional fee as a transaction with 2 outputs.
+1,100 outputs, paying the same conventional fee as a transaction with 2 outputs.
 
 The objective of the new fee policy, once it is enforced, is for fees paid by
-transactions to fairly reflect the processing costs that they impose on various
-participants in the network. This will tend to discourage usage patterns that
-cause either intentional or unintentional denial of service, while still
-allowing low fees for regular transaction use cases.
+transactions to fairly reflect the processing costs that their inputs and outputs
+impose on various participants in the network. This will tend to discourage
+usage patterns that cause either intentional or unintentional denial of service,
+while still allowing low fees for regular transaction use cases.
 
 
 Requirements
@@ -70,7 +70,7 @@ Requirements
 * Users should not be penalised for sending transactions constructed
   with padding of inputs and outputs to reduce information leakage.
   (The default policy employed by zcashd and the mobile SDKs pads to
-  two inputs and outputs for each shielded pool used by the transaction).
+  two inputs and two outputs for each shielded pool used by the transaction).
 * Users should be able to spend a small number of UTXOs or notes with value
   below the marginal fee per input.
 
@@ -122,7 +122,7 @@ impact on the network, without discriminating between different protocols
 the numbers of inputs and outputs.
 
 A previous proposal used :math:`inputs + outputs` instead of logical actions.
-This would have disadvantages Orchard transactions, as a result of an
+This would have disadvantaged Orchard transactions, as a result of an
 Orchard Action combining an input and an output. The effect of this
 combining is that Orchard requires padding of either inputs or outputs
 to ensure that the number of inputs and outputs are the same. Usage of
@@ -162,13 +162,15 @@ produce change. Due to the aforementioned padding, :math:`min\_actions = 2`.
 
 Having a grace window size greater than :math:`min\_actions` would
 increase the cost to create such a minimal transaction. If the
-cost for a minimal transaction is bounded above by :math:`B`, then
-possible choices of :math:`marginal\_fee` are bounded above by
-:math:`B / max(min\_actions, grace\_actions)`. Therefore, the
-optimal choice of :math:`grace\_actions` to maximize the cost of
-denial-of-service attacks that use many logical actions, without
-imposing an undue penalty on minimal transactions, is
-:math:`grace\_actions = min\_actions = 2`.
+cost we believe that users will tolerate for a minimal transaction
+is :math:`B`, then possible choices of :math:`marginal\_fee` are
+bounded above by :math:`B / \max(min\_actions, grace\_actions)`.
+Therefore, the optimal choice of :math:`grace\_actions` to maximize
+the per-logical-action cost of denial-of-service attacks for a given
+:math:`B`, is :math:`grace\_actions = min\_actions = 2`. This also
+ensures that a denial-of-service adversary does not gain a
+significant per-logical-action cost advantage by using transactions
+with a smaller or larger number of logical actions.
 
 Marginal Fee
 ~~~~~~~~~~~~
@@ -210,7 +212,7 @@ Security and Privacy considerations
 
 Non-standard transaction fees may reveal specific users or wallets or wallet
 versions, which would reduce privacy for those specific users and the rest
-of the network. However, the advantage of faster deployment argued against
+of the network. However, the advantage of faster deployment weighed against
 synchronizing the change in wallet behaviour at a specific block height.
 
 Long term, the issue of fees needs to be revisited in separate future