uip 7: clarify FMD implications for transparent addresses

uips/uip-7.md

@@ -3,7 +3,7 @@
 | title | Transparent Addresses for External Compatibility |
 | description | A 32-byte address format for improved interoperability with external systems |
 | author | Jennifer Helsby ([@redshiftzero](https://github.com/redshiftzero)), Henry de Valence ([@hdevalence](https://github.com/hdevalence)), Lúcás Meier ([@cronokirby](https://github.com/cronokirby)) |
-| discussions-to | https://forum.penumbra.zone/t/pre-uip-transparent-addresses/140 |
+| discussions-to | <https://forum.penumbra.zone/t/pre-uip-transparent-addresses/140> |
 | status | Draft |
 | type | Standards |
 | consensus | Yes |
@@ -27,13 +27,18 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 ### Address Format
 
 The current Penumbra address format consists of a:
+
 * 16-byte diversifier $d$,
+
 * 32-byte transmission key $pk_d$, and
+
 * 32-byte clue key $ck_d$.
 
 The diversifier is generated by encrypting a 16-byte _address index_ which
 consists of:
+
 * 4 byte account index, the default account index being 0,
+
 * 12 byte randomizer
 
 The diversifier $d$ is then used to derive the diversified basepoint $B_d$ using
@@ -55,8 +60,11 @@ all messages for all transmission keys corresponding to that IVK.
 ### Transparent Address Decoding Rules
 
 When decoding a transparent address to its full Penumbra address:
+
 1. The diversifier MUST be set to 16 zero bytes
+
 2. The transmission key MUST be set to the transmission key of the transparent address
+
 3. The clue key MUST be set to the identity element
 
 ### Diversifier Decryption
@@ -68,12 +76,14 @@ corresponding to the default account index 0, with no randomizer.
 
 The implications of this are that there are two valid diversifiers for the
 default account:
+
 * The zero ciphertext (`[0u8; 16]`)
+
 * The ciphertext of the 0 address index
 
 ### Fuzzy Message Detection (FMD)
 
-Transparent addresses are incompatible with the FMD feature of the Penumbra protocol, which enables a user to delegate a probabalistic detection capability to a third party. This is considered acceptable since other scanning improvements such as Spend Backreferences will make FMD less important for efficient transaction detection.
+Transparent addresses are incompatible with the FMD feature of the Penumbra protocol, which enables a user to delegate a probabalistic detection capability to a third party. This is considered acceptable since other scanning improvements such as Spend Backreferences result in clients not needing to detect every transaction. Using Spend Backreferences, clients can efficiently reconstruct their entire transaction history from a single transaction, and are expected primarily to be using shielded Penumbra addresses instead of transparent addresses.
 
 ### Changes to `Ics20Withdrawal` Action
 
@@ -85,7 +95,7 @@ The `Ics20Withdrawal` action is modified to:
 
 When the `use_transparent_address` field is true:
 
-* The `return_address` field MUST be set to the transparent address.
+* Clients MUST set the `return_address` field to the transparent address.
 
 ## Rationale