mimblewimble team mailing list archive

[Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>]

Hi,

I wanted to pick that back up. I think it comes down to yet another tradeoff between privacy, security and convenience. To give back some context from Andrew's email:

> Basically our outputs should consist of the pair
>   vH + rG, sha256(rJ)
> where J is a new NUMS generator, G the standard generator, and H is our asset
> ID as always. We set this up so that we can softfork a rule that only allows
>outputs to be spent by revealing rJ and an unconditional rangeproof, but prior
> to the softfork we only require ordinary rangeproofs.

I'll let you refer to Andrew's email for a bigger list of benefits [1]. Now the drawbacks: to store the hash, we need an extra 32 bytes field in outputs. We could likely make that even a little smaller but the size isn't my bigger worry. With an additional free-form field people and wallets implementations will:

- Compromise their privacy by inserting data that make their transactions look different from the others.
- Insert hashes of documents, identity, images, etc. and likely never allow pruning of these outputs.
- Use it as plain storage and demand the field to be larger.

So I'd be happy to hear others' arguments. The benefits would be tangible, but so would be the drawbacks.

- Igno

[1] https://lists.launchpad.net/mimblewimble/msg00165.html