New Address Type: TraceableChange

[aszepieniec]

Introduce a new address type TraceableChange which is the default type used for change UTXOs. The defining feature is that the pubscript input is a symmetrically-encrypted ciphertext under the user's own secret key. The data payload of this ciphertext is the UTXO data, such as amount and whatever else the user needs to be able to spend this UTXO.

With this construction in place, a generation address paper wallet can recover any number of change UTXOs after being used for spending multiple times, just by scanning the history of blocks.

[dan-da]

iiuc, this would be "traceable" by the wallet owner, but not by anyone else. correct?

If that's right, then I think TraceableChange perhaps conveys the wrong idea, and bad for branding because the name immediately makes me worry that somehow NeptuneCash is compromising on privacy when it comes to receiving change.

And this is not "traceable" in the sense of walking backward from one linkable (u)txo to another, but only in the sense of finding "mine" from the pool of all (unlinkable) utxo.

If my above analysis is correct, perhaps SearchableChange might be a better fit?

I'm also unclear what happens with regular (non-change) incoming utxo. ie, how does the wallet find those when first syncing? I suppose I need to read the white paper again. Anyway, it's unclear to me why change utxo are special in this regard.

[aszepieniec]

iiuc, this would be "traceable" by the wallet owner, but not by anyone else. correct?

Absolutely correct. And I agree that Traceable is probably the wrong word, although I'm not sure Searchable is the right one. The key feature that distinguishes (what is now called) TraceableChange from alternative change UTXOs is that you can recover all transaction data from your seed phrase just by scanning the blocks and decrypting messages for you. The alternatives are a) naïve change, in which case you would need to back up data separately; b) reuse a GenerationAddress, but then you are using a public key cryptosystem to send a message to your future self when a symmetric key cryptosystem would suffice and would incur less transaction fees.

what happens with regular (non-change) incoming utxo. ie, how does the wallet find those when first syncing?

I don't think this information is present in the whitepaper, because we came up with the GenerationAddress construction after writing that. I apologize for the poor documentation and promise to resolve that situation in the not too distant future.

The cheeky response is that I don't know what you mean by "regular" incoming UTXO. But in addition to cheeky, that response is false because right now there only one address type that you could be referring to: GenerationAddresses. In the future we will have more address types, each with unique tradeoffs.

When you ask a wallet to generate a GenerationAddress, it generates a key pair under a lattice-based public key encryption scheme. The hash of this public key is included in transactions (not UTXOs) that spend coins to this address, along with a ciphertext that includes information like amount and sender randomness. When syncing to the blockchain, your client scans for transactions containing this hash, and decrypts the ciphertext when it finds a match. Of course, one transaction might contain multiple UTXOs destined for distinct recipients, and in this case your client trial-decrypts all of them, and retains only the successfully decrypted plaintexts. (Here it helps that decryption in this lattice-based cryptosystem is blazing fast.)

The downside of this approach is that multiple donations to the same GenerationAddress contain the same hash, and so external observers can tell how often a given GenerationAddress was donated to. The sender cannot tell when the sent funds were spent or, except for edge cases having to do with the mutator set, whether they were spent. The upside of this approach is a) the user can ignore all transactions that do not contain his hash; and b) the user can receive and recover all funds just by keeping track of their mnemonic seed phrase.

[dan-da]

I believe this can be closed now that #171 is merged. @aszepieniec do you agree?

We called it SymmetricKey rather than TraceableChange, but I think otherwise it satisfies the requirements here.

[aszepieniec]

Agreed. The honor of closing is yours ;-)

[dan-da]

closed by #171.