Keys, proofs and the inbox

A confidential balance needs a second key. Your normal account key signs transactions. The new one is an encryption key. It locks and unlocks the numbers.

Opting in. You register your encryption key by converting some of your public balance to confidential form. The amount can be zero, so you can register without moving anything. Until you register, nobody can send you a confidential transfer.

Three locked copies. Each confidential balance is stored as several locked copies of the same number:

• One only you can open. This copy is what you spend from.
• One the issuer can open.
• One an auditor can open, if the issuer named an auditor.

Proof without showing. When you send, you attach a mathematical proof. It shows that you have enough, that the amount is not negative, and that all locked copies hold the same number. Validators check the proof. They never see the number.

The inbox. A proof is built against your balance at one moment. If someone paid you a second later, your balance would change and your proof would break. So incoming funds go to a separate inbox. Your spending balance changes only when you act. To spend what you received, you merge the inbox first.

No reset. If you lose the private encryption key, your confidential funds are gone. No one can recover them for you.

Confidential fields on the holder's MPToken entry:

Registration. The first ConfidentialMPTConvert carries HolderEncryptionKey and a 64-byte Schnorr proof of knowledge in ZKProof. Sending a key when one is already registered fails with tecDUPLICATE. Converted funds are credited to the inbox.

Sending. ConfidentialMPTSend carries a ciphertext for each party: SenderEncryptedAmount, DestinationEncryptedAmount, IssuerEncryptedAmount and, if an auditor is set, AuditorEncryptedAmount. Its ZKProof is a 946-byte bundle: a compact sigma proof plus an aggregated Bulletproof range proof. The sigma proof ties the ciphertexts together. The range proof shows the amount and the remaining balance are not negative.

A send follows the same authorization rules as a normal MPT payment, including Deposit Authorization and credentials. A locked token fails with tecLOCKED.

Merging. ConfidentialMPTMergeInbox takes only MPTokenIssuanceID. It moves the whole inbox into the spending balance and resets the inbox to the canonical encrypted zero. It succeeds even when the inbox is empty.

Version counter. ConfidentialBalanceVersion goes up by 1 on every change to the spending balance: a send, a merge, a convert back or a clawback. A proof made against an older version fails with tecBAD_PROOF. This blocks replays.

Keys are generated off the ledger. Wallet software has to create the ElGamal key pair and build the proofs.