ZIP 213: cosmetics.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>

zip-0213.html

@@ -57,7 +57,7 @@ License: MIT</pre>
             <p>The ZIP does not require that all coinbase must be shielded immediately from activation of the network upgrade, so that miners and mining pools may gradually migrate from their existing transparent addresses to Sapling addresses. This also simplifies the consensus rules, because the Founders' Reward targets transparent addresses, and thus it remains necessary for the time being to support them. A future ZIP could require all coinbase to be shielded immediately.</p>
             <p>Enforcing coinbase maturity at the consensus level for Sapling outputs would incur significant complexity in the consensus rules, because it would require special-casing coinbase note commitments in the Sapling commitment tree. The standard recommendation when spending a note is to select an anchor 10 blocks back from the current chain tip, which acts as a de-facto 10-block maturity on all notes, coinbase included. This might be proposed as a consensus rule in future.</p>
             <p>There is another reason for shielded coinbase maturity being unnecessary: shielded coinbase outputs have the same effect on economic activity as regular shielded outputs. When a transparent address receives a coin in some "parent" transaction and later spends it, a tree of "direct child" transactions is created that all require the original parent transaction to be valid. However, most wallets treat unspent transparent outputs as a single "bucket of money", and select coins to spend without direct user input. This can create a disconnect between the economic activity of users (who might be intending to spend funds that they just received, creating "logical child" transactions), and their on-chain transaction graph.</p>
-            <p>&gt; For example, a mining pool that successfully mines a block will receive a coinbase &gt; output, but their subsequent payout to miners might instead spend ZEC that they already &gt; had before the block was mined. If the mining pool pays out for block X, and then a &gt; reorg or rollback occurs that causes the transparent coinbase in block X to become &gt; invalid, the payout transaction might still be mined on the new chain, even though the &gt; funds that the miner was logically spending do not exist there.</p>
+            <p>For example, a mining pool that successfully mines a block will receive a coinbase output, but their subsequent payout to miners might instead spend ZEC that they already had before the block was mined. If the mining pool pays out for block X, and then a reorg or rollback occurs that causes the transparent coinbase in block X to become invalid, the payout transaction might still be mined on the new chain, even though the funds that the miner was logically spending do not exist there.</p>
             <p>By contrast, when a reorg or rollback occurs that would cause a shielded coinbase output to disappear, it will also invalidate every shielded transaction that uses an anchor descending from the tree that the shielded coinbase output had been appended to. That is, all shielded economic activity would be rolled back in addition to the shielded coinbase output disappearing, ensuring that all logical child transactions are invalidated, not just direct child transactions. Therefore, there is no reason to make shielded coinbase a special case when the same behaviour already occurs in regular shielded notes.</p>
             <p>Requiring that note commitments are valid when recovering using a fixed outgoing viewing key implies that target addresses and values for all Sapling outputs within the coinbase are revealed. This would be necessary to correctly enforce shielded Founders' Reward or funding stream outputs, and it is simpler to enforce this on all outputs. Additionally, this maintains the ability for network observers to track miners and mining pools. Meanwhile, the miners and mining pools could put useful or identifying text in the memo fields of the outputs, instead of storing it ad-hoc elsewhere in the coinbase transaction.</p>
         </section>

zip-0213.rst

@@ -134,12 +134,12 @@ create a disconnect between the economic activity of users (who might be intendi
 spend funds that they just received, creating "logical child" transactions), and their
 on-chain transaction graph.
 
-> For example, a mining pool that successfully mines a block will receive a coinbase
-> output, but their subsequent payout to miners might instead spend ZEC that they already
-> had before the block was mined. If the mining pool pays out for block X, and then a
-> reorg or rollback occurs that causes the transparent coinbase in block X to become
-> invalid, the payout transaction might still be mined on the new chain, even though the
-> funds that the miner was logically spending do not exist there.
+For example, a mining pool that successfully mines a block will receive a coinbase
+output, but their subsequent payout to miners might instead spend ZEC that they already
+had before the block was mined. If the mining pool pays out for block X, and then a
+reorg or rollback occurs that causes the transparent coinbase in block X to become
+invalid, the payout transaction might still be mined on the new chain, even though the
+funds that the miner was logically spending do not exist there.
 
 By contrast, when a reorg or rollback occurs that would cause a shielded coinbase output
 to disappear, it will also invalidate every shielded transaction that uses an anchor