Tx-building: Compact slates

[lehnberg]

Description

This issue tracks the effort to redesign slate structure into a new version that minimises the data shared in each trip and tries to reduce slate footprint as much as possible.

Old description

As per Round 2.1 in the transaction building workflow, sender shares change_outputs information with recipient.

This leads to the recipient gaining information of sender's future outputs that can be used to de-anonymize other outputs of the sender. Example: Alice makes a grin deposit to an exchange with KYC requirements, and as part of this creates a change output. This change output is later used as part of spending other outputs that the exchange has never seen. If the exchange monitors the chain or mempool for the particular output being spent, they can begin making assumptions about other outputs that are being spent in the same context. If an exchange sees heavy grin usage, they might be able to deanonymize a great deal of output commitments this way.

It would therefore improve privacy if change outputs were not shared between transacting parties. Are there any immediate negative consequences, beyond the receiver not being able to verify that transaction_fee corresponds to the number of outputs being created?

---

Edit: As per discussion in grincoin#dev:

• A receiver would still be able to learn the change output by monitoring the mempool, assuming tx is not aggregated when it is added there.
• One approach would be for sender not to send inputs or change output, just the kernel, with the receiver trusting that the input exists.
• If this information is passed along to the receiver needlessly, in addition to leaking data too easily, it can also be said to waste bandwidth.

Edit Apr 02: Renaming issue, changing description, adding to 4.0.0 milestone.

[yeastplume]

I'm okay with this functionality in general, a couple of points

• This only works in the single payer->payee->payer workflow, not for the case of multiple parties transacting and not for the invoice workflow. Whoever posts the transaction obviously needs to have a complete awareness of all the outputs involved.
• Slate could be amended to either provide sum or outputs themselves, think that's fine.
• Realistically how difficult is it going to be to narrow down possibilities for the change output(s) anyhow, given they'll all appear in the same block? Are we going to need to see very full blocks on a regular basis before this has any effect?
• Does this need a short RFC?

[quentinlesceller]

Considering that the compact slate RFC has been merged =>mimblewimble/grin-rfcs#49
And that the corresponding code have been also merged => #404

I'm closing this issue. Awesome work @yeastplume ! 🎆