Wallet transaction privacy enhancement

[garyyu]

Currently, we're putting the transparent coin amount, fee, height/lock_height, and so on in the slate, and fully rely / depend on the communication channel to manage / provide the privacy, such as via the Https / Keybase for encrypted communication channel, or via the Http / File which can't provide privacy.

This is a quite reasonable/good design, to provide multiple methods on low level, and the developers / users MUST know what they're doing.

For example, in a safe private network, using Http for internal wallet transaction could not be a bad design.

But I indeed have a little worry that actually we should do a little bit more here to protect our privacy reputation, since privacy is the brand of Mimblewimble protocol.

And a possible worse situation is some people (especially those without much IT knowledge background) could simply use the Http for grin wallet send, since it's much simple than the Https setup. For example, someone send some grin coins to a friend from a company network, and the network admin come to warn him/her don't play crypto in the office and even says "wow you're so rich~ you sent 1 million grin coins! how much coins do you have?" then that someone will be shocked and faint 😸 he/she could have expected privacy cryptocurrency must 100% privacy! in any situation! then the Grin privacy reputation will turn into dusky among persons in the street, by such kind of misuse.

Why not kill this risk at day one of our launching 😄

To give a shot on what these transparent slate looks like:

{
   "num_participants":2,
   "id":"37453d70-85c7-432b-b880-f909b06f4e82”,\
   "tx":{...
      "kernels":[\
         {  "features":{"bits":0},\
            "fee":8000000,\
            "lock_height":89165,\
            "excess":[...],\
            "excess_sig":[...]\
         }]\
      }\
   }
   "amount":1000000000,\
   "fee":8000000,\
   "height":89165,\
   "lock_height":89165,\
   "participant_data":[\
   {  "id":0,\
      "public_blind_excess":[3,241,235,206,70,87,156,16,145,214,145,129,220,233,235,214,243,246,31,66,78,99,34,30,19,216,32,14,202,178,4,205,100],\
      "public_nonce":[2,246,65,150,75,199,223,145,67,54,165,74,244,234,7,129,57,5,9,40,193,125,54,141,50,146,148,177,153,106,214,150,140],\
      "part_sig":null,\
      "message":null,\
      "message_sig":null\
   }\
   ]\
}

So, I propose we do a global transaction data encryption as the grin wallet default implementation, at our low level, and never rely on the communication channel to provide this.

Before go inside the detail design of this (should be easy to implement and can be completed in one/two days), I would like to hear from you if this is really matter and needed.

[yeastplume]

I don't think this will work for us because:

1. In order to have an encrypted exchange, you need either a pre-shared key or a key agreement mechanism. Whatever form this takes would further complicate an already complicated exchange process for everybody (as opposed to just those who need it).

2. Whatever this process is would be vastly more complicated in future cases we'd want to support, like multi-party (i.e. > 2 participants) or multi-sig.

I can see it being beneficial for participants to want conceal the amount during the exchange, but think the details of how that happens are best left outside of the core protocol.

[Erni03]

🤔

[sesam]

We can't realistically do anything about this in time before Mainnet. Then even if we could, and if wallets could implement and iron out any additional bugs, it would still be up to the wallet implementations and users discretion to stay safe, stay private with how they create and publish transactions. But I'm still curious about what @garyyu thought would be a possible approach to get some kind of encryption that's better than the current plain text, and if it might be giving some people a false sense of security and/or run into problems 1. and 2. suggested above.