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
--
Mailing list: https://launchpad.net/~mimblewimble
Post to : mimblewimble@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mimblewimble
More help : https://help.launchpad.net/ListHelp
