Various small modifications to ZIP 222

- Narrow requirements for prefix-free encodings.
- Clarify that TZEs need to define the four properties for each mode.
- Allow for potential future relaxation of cross-TZE restrictions.
- Expand some explanations.

Co-authored-by: Daira Hopwood <[email protected]>

zip-0222.rst

@@ -86,18 +86,18 @@ within the extension's overall protocol.
 A transparent extension mode is defined by four properties (in addition to ``type``):
 
 - A numeric ``mode``.
-- A byte sequence ``predicate`` containing a prefix-free encoding describing the
-  predicate.
-- A non-malleable byte sequence ``witness`` containing a prefix-free encoding of evidence
-  satisfying the predicate.
+- A byte sequence ``predicate`` containing an encoding of the predicate that is
+  prefix-free within this ``(type, mode)``.
+- A non-malleable byte sequence ``witness`` containing an encoding of evidence
+  satisfying the predicate that is prefix-free within this ``(type, mode)``.
 - A deterministic verification algorithm ``tze_verify`` that takes as arguments ``mode``,
   ``predicate``, ``witness``, and a context object providing deterministic public
   information about the transaction as well as the block chain (up to and including the
   block that the transaction is mined in). It returns ``true`` if the predicate is
   satisfied, and ``false`` otherwise.
 
 ZIPs that define a new transparent extension must completely specify all four of these
-properties.
+properties for each defined mode.
 
 The lengths of ``predicate`` and ``witness`` are not required to be constant length, but
 MUST be solely determined by the pair ``(type, mode)``.
@@ -139,16 +139,20 @@ Rationale
 =========
 
 Transactions that have both TZE inputs and outputs are required to use a single extension
-type, in order to prevent cross-protocol attacks. This prevents TZE-encumbered value from
-being spent directly into a different TZE type; the value needs to go through a regular
-address in between.
+type, in order to prevent cross-protocol attacks. The downside is that this prevents all
+TZE-encumbered value from being spent directly into a different TZE type; the value needs
+to go through a regular address in between. This restriction might be relaxed in future
+ZIPs for specific combinations of ``(type, mode)`` pairs that have been analyzed for
+cross-protocol attacks, but we opt here for a fail-safe default behaviour.
 
 - TODO: Maybe also disallow regular (transparent, Sprout, and Sapling) spends/outputs in
   transactions that have TZE inputs and outputs?
 
 An earlier draft version of this ZIP stored the payloads inside transparent inputs and
-outputs. This coupled the extension logic too tightly to the transparent address logic,
-and was replaced with dedicated transaction fields.
+outputs. Although this had the advantage of not requiring a transaction format change,
+the consensus rules were significantly more complicated, and the design coupled the
+extension logic too tightly to the transparent address logic. Instead, this ZIP uses
+dedicated transaction fields.
 
 
 Security and Privacy Considerations