UIP 8: Transparent addresses

uips/uip-7.md

@@ -0,0 +1,133 @@
+| uip | 007 |
+| - | - |
+| 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 |
+| status | Draft |
+| type | Standards |
+| consensus | Yes |
+| created | 2024-12-10 |
+
+## Abstract
+
+This UIP introduces transparent addresses ("t-addresses"), a 32-byte Bech32 address format designed for maximum compatibility with external systems while maintaining convertability to full Penumbra addresses.
+
+## Motivation
+
+Recent compatibility issues with external systems (e.g., Noble's USDC integration) have highlighted the need for a maximally compatible address format. While the correct long-term solution is full support for Penumbra's native addresses, a shorter address format can serve as an immediate solution and future-proof escape hatch for similar issues. Penumbra's native addresses have two major differences from most other addresses in the Cosmos ecosystem, in that:
+
+1. They are longer: 144 bytes.
+2. They use Bech32m encoding, instead of Bech32.
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+### 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
+decaf377 hash-to-group $H_{\mathbb{G}}^{d}$:
+
+$B_d = H_{\mathbb{G}}^{d}​(d)$
+
+This diversified basepoint is used to to derive the transmission key $pk_d$:
+
+$pk_d = [ivk] B_d$
+
+The new address format, the *transparent address*, consists only of the 32 byte transmission key. It is encoded using the `tpenumbra` human-readable prefix.
+
+The transmission key for the transparent address is derived using the diversifier
+corresponding to all zero bytes. Note that during scanning, the wallet scans
+for incoming messages using the Incoming Viewing Key (IVK), and thus detects
+all messages for all transmission keys corresponding to that IVK.
+
+### Transparent Address Conversion Rules
+
+When converting a transparent address to a 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
+
+The diversifier decryption is modified as follows:
+
+The null ciphertext [0u8; 16] is defined to correspond to the address index
+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 null 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.
+
+### Changes to `Ics20Withdrawal` Action
+
+The `Ics20Withdrawal` action is modified to:
+
+1. Add a new boolean field `use_transparent_address`
+2. Deprecate the existing `use_compat_address` field
+
+When the `use_transparent_address` field is true:
+* The `return_address` field MUST be set to the transparent address.
+* The `use_compat_address` field MUST be set to false.
+
+## Rationale
+
+The design prioritizes:
+1. Maximum external compatibility through fixed-size 32-byte addresses
+2. Seamless conversion to full Penumbra addresses
+3. Minimal changes to the core protocol
+
+The tradeoff of having only one transparent address per wallet is
+accepted as the cost of compatibility with external systems.
+
+## Backwards Compatibility
+
+The modification to diversifier decryption means that if a null diversifier
+happened by chance, it will in the future be interpreted as the address index for the default account.
+This is accepted since the probability is astronomically low, $1/2^{128}$.
+
+## Test Cases
+
+TK
+
+## Security Considerations
+
+TK
+
+All UIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. For example, include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. UIP submissions missing the "Security Considerations" section will be rejected. A UIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.
+
+The current placeholder is acceptable for a draft.
+
+TODO: Remove the previous comments before submitting
+
+## Privacy Considerations
+
+The primary privacy issue is the linkability of transactions when the same wallet
+is used for multiple IBC deposits or withdrawals. This occurs because there is
+only one transparent address per wallet, and so any transactions that use the
+same transparent address are linked. This can be mitigated by transferring funds
+to separate wallets, but this is inconvenient for users. Implementations SHOULD
+provide a warning to users when they are about to use a transparent address for
+an IBC transfer, and clearly communicate the privacy implications of using a
+transparent address. Transparent addresses were named as such to make
+this privacy issue explicit.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://github.com/penumbra-zone/UIPs/blob/main/LICENSE).