mimblewimble team mailing list archive

[Andrew Poelstra <apoelstra@xxxxxxxxxxxxxx>]

A week ago I announced "Confidential Assets" [1], an extension of CT to
allow multiple asset types whose identities are non-public to coexist
on one blockchain. (The crypto is essentially the same as Oleg's similar
announcement [2], though we were working entirely independently.) I
posted on Reddit a short summary of how this would interact with MW [3].
Essentially, they are entirely compatible, although multiple assets
introduces the possibility for more elaborate issuance/deissuance rules,
and these cannot be deleted from the chain, so we need to be cautious to
maintain MW's scaling capabilities.

Essentially, CA works by attaching an "asset commitment" to every output
as well as an additional zkp showing that the asset commitment is legit.
The asset commitment is one EC point (two if we want unconditional
soundness, which we do), and the proof is `n_assets + 1` many scalars.
Point are 32 bytes plus a bit, scalars are 32 bytes.

Related to asset commitments are "asset IDs" which are just NUMS points,
and these represent the actual assets. Given an asset id H, you can also
consider 10H (for example) to be an asset id, and assets with this id
will be silently convertible into H's at a 10:1 ratio. This gives rise
to "denominations", which should let us use smaller rangeproofs while
maintaining some privacy.

Here is my proposal for Grin:

TODAY
========

  1. Block headers, in addition to having a merkle root commitment, to
     the set of all kernels and transaction inputs/outputs, may also
     commit to some number of merkle-sum trees of commitments. Each
     tree has a corresponding asset id and describes the issuances and
     deissiances of the asset.

     The leaves of these trees consist of
        - a commitment plus rangeproof, a kernel plus sig, or an explicit amount
        - a negative flag
        - freeform "extra conditions" data

     The rangeproof must use the bare asset id, not an asset commitment.
     Nodes commit to a sum of their children, multiplying them by -1 if
     the negative flag is set, and converting them to commitments if they
     are explicit amounts.

     Explicit amounts are limited to [0, 2^64), and the negative flag
     stretches this to (-2^64, 2^64).

     (This weird structure will become clear, it's to make it possible
     to softfork in additional assets.)


  2. The root sum is subtracted from the running sum-of-all-kernels, so
     corresponding unbalanced transactions need to happen in the main
     block body to keep everything balanced.

  2a. There is one big exception to this: for the tree corresponding to
      the mainchain, all leaf commitments are directly added to the utxo
      set, but are marked so that they cannot be spent until maturity.
      Similarly all kernels are added to the sum-of-all-kernels.

  2b. We could actually require miners to split their subsidy+fees into
      ten and release these after 100, 200, ..., 1000 blocks, which is
      an idea I've heard thrown around to help mining incentives. What
      do people think about this?

      Note that this idea can be softforked in later on, though it would
      require miner cooperation and this could be contentious :)


  3. All block headers must commit to such a tree for every asset. New
     assets can be introduced after a BIP9-style period of miner signalling.
     Presumably during this time there will come to agreement on what the
     rules for the new asset are, since the above conditions allow anybody
     to issue or deissue however much they want.

     Once the new asset comes into being, its asset ID is computed by
     hashing the blockhash at the start of the signalling period.

     (This needs to be tightened up of course, but this is the essense of
     the idea. The point is that new assets can be softforked in, validators
     who don't understand it are able to check its inflation-soundness (and
     in particular, they can check it does not interfere with other assets'
     inflation-soundness), and while in principle arbitrarily many assets
     might exist, miners are limited by this BIP9 thing so they can't easily
     DoS the system though asset proliferance.)


  4. Every output must have a zkp proving that its asset commitment maps to
     one of the assets. Every available asset must be used (to avoid a cost
     privacy tradeoff) thrice: as itself, as 10000 times itself, and as
     10000*10000 times itself. Rangeproofs must cover 20 bits. So we get a
     total of ~47 bits of range, similar to Bitcoin's 51.

     (These numbers are subject to debate and represent a privacy/scalability
     tradeoff.)


  5. Initially there are two asset types: maincoin and testcoin. Their issuance
     trees are subject to the following additional rules. We'll call the maincoin
     asset id M and the testcoin T.

  5a. For the maincoin:
      1. The root sum must be exactly (subsidy + fees) * T.
      2. Explicit amounts are disallowed (because there is no sensible way to
         maturity-delay them that I can see).
      3. The negative flag may not be used.
      4. The "extra conditions data" must be empty. 
      5. There may be at most ten (we can bikeshed this) outputs. It should be
         allowable to split coinbases for privacy but we don't want to
         encourage pools to pay out thousands of members in individual outputs.

  5b. For the testcoin:
      1. The tree must have only one entry, and it must be an explicit amount
      2. It may be negative.
      3. The "extra conditions data" must be empty. 


  6. We also need some cap on the size of each issuance tree, for DoS/resource
     reasons. Open to bikeshedding, but I'll throw out 100.


To create testcoins, transactions on the wire have an extra "testcoin imbalance"
parameter which the miner will sum into this single-entry "tree".


FUTURE
==========

A core goal of this design is to make it possible to later softfork in a
sidechain peg. The restrictions on this would be that the "extra condition"
data would have some sort of SPV proof or whatever. Kernels and commitments
can be used to describe the destination of the coins, and explicit amounts
can be used to give miners fees in the pegged asset.

Another idea is that if in the far future grin's coin issuance schedule
turns out to be economically or incentive-wise bad, we can softfork in
another coin with another schedule. (Of course, the original coin would
remain perfectly intact, for people who don't like this.)


This is a pretty complex proposal, and will need a fair bit of review and maybe
modification, but it gives us an incredible amount of power:

  - Confidential assets :)

  - A test coin that users can mint arbitrarily and which adds to the
    privacy set for the real coins (but whose issuance takes constant space)

  - Ability to soft-fork in pegged (or other) currencies

  - Users who don't follow the soft-fork still get the privacy benefits of
    the new asset type, and can still verify inflation-soundness or the new
    asset and old ones.

  - In fact, we could add a coin whose issuance is based on some new and
    suspicous crypto, or trust assumptions, or whatever, and if this crypto
    fails the fallout is entirely contained to the new asset.

...and we get all this without any new crypto primitives (though who knows what
a peg proof will wind up looking like..).



Cheers!,
Andrew



[1] https://blockstream.com/2017/04/03/blockstream-releases-elements-confidential-assets.html
[2] https://blog.chain.com/hidden-in-plain-sight-transacting-privately-on-a-blockchain-835ab75c01cb
[3] https://www.reddit.com/r/Mimblewimble/comments/63co0u/blockstream_releases_confidential_assets/

-- 
Andrew Poelstra
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

"A goose alone, I suppose, can know the loneliness of geese
 who can never find their peace,
 whether north or south or west or east"
       --Joanna Newsom

Attachment: signature.asc
Description: PGP signature