Terminology
Detector - a service which wallets rely on to recover Notes from the blockchain. A wallet prefers to use this service because they trade off some privacy or control for lower resource demands.
Wallet - in the context of this ticket only a wallet implies a "light wallet" that wishes to receive and spend JoinSplits but does not accept the full resource cost of downloading and verifying the whole blockchain.
Note - A confidential container of an arbitrary amount of currency value which is either "committed" or "spent" as a unit.
Public Values - The public values of a JoinSplit include: ciphertext (size and any other distinguishers), input nullifiers (x2), output Note commitments (x2), public output value and address.
Input Nullifiers aka Spent Nullifiers - The public nullifiers of a JoinSplit which mark the input Notes as spent.
Output Nullifier - The secret nullifiers of a JoinSplit's output notes. Knowledge of this secret allows to link a subsequent JoinSplit when at least one of the subsequent JoinSplit's input nullfiers matches a known output nullifier
Z-addr - Although a wallet may disclose a Z-addr to arbitrary parties, the spending or recipient addresses involved in a JoinSplit are not publicly known (not part of the public values). The spender's address is never known, so throughout this ticket description, Z-addr refers specifically to recipient addresses.
Detection Identifier - We presume there must be some value shared between the wallet and detector which allows the detector to link multiple JoinSplits as intended-to-be-received by the wallet. (In some cases this may not be distinct from other values, eg: the Z-addr of the wallet.)
Protocol Scope
In all protocol definitions, assume that:
- all extraneous information about a wallet (its IP address, the owner's identity), etc... are unknown to the detector
- a wallet uses only a single address, so this scope excludes a detector attempting to link multiple of its clients (Z-addr, network requests, etc...) to a single wallet
- a wallet uses a single detector for all JoinSplits, so the scope excludes consideration of a network or multi-node attacker attempting to link multiple detector relationships to the same wallet
- a wallet delivers JoinSplits anonymously, so that no detector can determine the origin of any JoinSplits.
Protocol Feature Definitions
Base Case: No protocol change: the detector service has full control over a client's secrets and can see and spend JoinSplits. This is the only case in which the detector service also has the capability to spend JoinSplit output Notes. This is incredibly simplistic: don't change the protocol and wallets just hand over secret keys to the service.
Detector can recover: public values, Detection Identifier, Z-addrs, output Note values, memos, output serials, wallet private keys (spend authority).
Detector cannot recover: (nothing!)
Minimal Confidentiality aka MC: A detector service can recover all information from a JoinSplit, but cannot authorize spending the outputs.
Detector can recover: public values, Detection Identifier, Z-addrs, output Note values, memos, output nullifiers
Detector cannot recover: wallet private keys (spend authority)
Minimal Spend-Unlinkable Confidentiality aka MUC: Like the MC protocol, except the detector cannot recover the output nullifiers, and thus cannot link a wallet's spends.
Detector can recover: public values, Detection Identifier, Z-addrs, output Note values, memos
Detector cannot recover: output nullifiers, wallet private keys (spend authority)
Public-Address-Revealed Confidentiality aka PARC: This protocol improves wallet confidentiality over MUC by protecting all of the JoinSplit cleartext.
Detector can recover: public values, Detection Identifier, Z-addrs
Detector cannot recover: output Note values, memos, output nullifiers, wallet private keys (spend authority)
Public-Address-Linkable Confidentiality aka PALC: As PARC, but Z-addrs are not directly revealed to the detector. However, if the detector has a Z-addr from another source, it can be linked to the Detection Identifier. (This is essentially equivalent to PARC for most purposes, but not for resistance to quantum attacks against the note encryption in the case of Z-addresses that are kept secret, for example.)
Detector can recover: public values, Detection Identifier
Detector can link: known Z-addrs to Detection Identifiers
Detector cannot recover: output Note values, memos, output nullifiers, wallet private keys (spend authority)
Address Confidentiality aka AC: In addition to PARC, the detector does not find out the wallet's Z-addr nor can the Detection Information be linked to any already known Z-addr. The detector can link two received JoinSplits as being to "the same Z-addr", but cannot recover that address.
Detector can recover: public values, Detection Identifier
Detector cannot recover: Z-addrs, output Note values, memos, output nullifiers, wallet private keys (spend authority)
Private Information Retrieval Unicorn aka PIRU: In addition to AC the detector cannot even determine when two JoinSplits are destined for the same wallet, yet somehow the wallet gains some bandwidth or other resource improvement over just being a full node.
Detector can recover: public values
Detector cannot recover: Detection Identifier, Z-addrs, output Note values, memos, output nullifiers, wallet private keys (spend authority)
Full Node: Same confidentiality profile as the ideal PIRU but maybe with different resource requirements.
Detector can recover: public values
Detector cannot recover: Detection Identifier, Z-addrs, output Note values, memos, output nullfiers, wallet private keys (spend authority)
Protocol Considerations
When designing a protocol, we must clarify:
- does it require a circuit change?
- does it require a protocol change, or can it be implemented "transparently" in wallets? (eg: if the outward facing form of a JoinSplit does not change, but clients decide to introduce a new multi-level Z-addr system and use multiple-encryption, this may be possible without protocol change.)
- is there an upgrade path from the current protocol to the new protocol which allows us to deploy the improvement after 1.0 launch? (-without consensus changes? -with a soft/hard fork?)
- if we do implement this in 1.0 but then discover a flaw or potential improvement, is there an upgrade path?
- if this is possible with a "transparent" change, and we wish to upgrade after a 1.0 launch, how does that affect usability?
- how does this interact with a distinct feature of "delegation of audit capability"?
edits
- Added "Protocol Considerations" section after the initial post.
- Take into account Protects as well as Pours.
- Changed title to "Delegated JoinSplit detection protocol for SPV clients." then updated this description to use the newly chosen terminology (Notes, nullifiers, Z-addrs).
[Edited by @daira to remove obsolete terminology, and to add the PALC feature definition.]
Terminology
Detector - a service which wallets rely on to recover Notes from the blockchain. A wallet prefers to use this service because they trade off some privacy or control for lower resource demands.
Wallet - in the context of this ticket only a wallet implies a "light wallet" that wishes to receive and spend JoinSplits but does not accept the full resource cost of downloading and verifying the whole blockchain.
Note - A confidential container of an arbitrary amount of currency value which is either "committed" or "spent" as a unit.
Public Values - The public values of a JoinSplit include: ciphertext (size and any other distinguishers), input nullifiers (x2), output Note commitments (x2), public output value and address.
Input Nullifiers aka Spent Nullifiers - The public nullifiers of a JoinSplit which mark the input Notes as spent.
Output Nullifier - The secret nullifiers of a JoinSplit's output notes. Knowledge of this secret allows to link a subsequent JoinSplit when at least one of the subsequent JoinSplit's input nullfiers matches a known output nullifier
Z-addr - Although a wallet may disclose a Z-addr to arbitrary parties, the spending or recipient addresses involved in a JoinSplit are not publicly known (not part of the public values). The spender's address is never known, so throughout this ticket description, Z-addr refers specifically to recipient addresses.
Detection Identifier - We presume there must be some value shared between the wallet and detector which allows the detector to link multiple JoinSplits as intended-to-be-received by the wallet. (In some cases this may not be distinct from other values, eg: the Z-addr of the wallet.)
Protocol Scope
In all protocol definitions, assume that:
Protocol Feature Definitions
Base Case: No protocol change: the detector service has full control over a client's secrets and can see and spend JoinSplits. This is the only case in which the detector service also has the capability to spend JoinSplit output Notes. This is incredibly simplistic: don't change the protocol and wallets just hand over secret keys to the service.
Detector can recover: public values, Detection Identifier, Z-addrs, output Note values, memos, output serials, wallet private keys (spend authority).
Detector cannot recover: (nothing!)
Minimal Confidentiality aka MC: A detector service can recover all information from a JoinSplit, but cannot authorize spending the outputs.
Detector can recover: public values, Detection Identifier, Z-addrs, output Note values, memos, output nullifiers
Detector cannot recover: wallet private keys (spend authority)
Minimal Spend-Unlinkable Confidentiality aka MUC: Like the MC protocol, except the detector cannot recover the output nullifiers, and thus cannot link a wallet's spends.
Detector can recover: public values, Detection Identifier, Z-addrs, output Note values, memos
Detector cannot recover: output nullifiers, wallet private keys (spend authority)
Public-Address-Revealed Confidentiality aka PARC: This protocol improves wallet confidentiality over MUC by protecting all of the JoinSplit cleartext.
Detector can recover: public values, Detection Identifier, Z-addrs
Detector cannot recover: output Note values, memos, output nullifiers, wallet private keys (spend authority)
Public-Address-Linkable Confidentiality aka PALC: As PARC, but Z-addrs are not directly revealed to the detector. However, if the detector has a Z-addr from another source, it can be linked to the Detection Identifier. (This is essentially equivalent to PARC for most purposes, but not for resistance to quantum attacks against the note encryption in the case of Z-addresses that are kept secret, for example.)
Detector can recover: public values, Detection Identifier
Detector can link: known Z-addrs to Detection Identifiers
Detector cannot recover: output Note values, memos, output nullifiers, wallet private keys (spend authority)
Address Confidentiality aka AC: In addition to PARC, the detector does not find out the wallet's Z-addr nor can the Detection Information be linked to any already known Z-addr. The detector can link two received JoinSplits as being to "the same Z-addr", but cannot recover that address.
Detector can recover: public values, Detection Identifier
Detector cannot recover: Z-addrs, output Note values, memos, output nullifiers, wallet private keys (spend authority)
Private Information Retrieval Unicorn aka PIRU: In addition to AC the detector cannot even determine when two JoinSplits are destined for the same wallet, yet somehow the wallet gains some bandwidth or other resource improvement over just being a full node.
Detector can recover: public values
Detector cannot recover: Detection Identifier, Z-addrs, output Note values, memos, output nullifiers, wallet private keys (spend authority)
Full Node: Same confidentiality profile as the ideal PIRU but maybe with different resource requirements.
Detector can recover: public values
Detector cannot recover: Detection Identifier, Z-addrs, output Note values, memos, output nullfiers, wallet private keys (spend authority)
Protocol Considerations
When designing a protocol, we must clarify:
edits
[Edited by @daira to remove obsolete terminology, and to add the PALC feature definition.]