New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User Issued Tokens (UIT) #830

Open
daira opened this Issue Apr 5, 2016 · 13 comments

Comments

@daira
Contributor

daira commented Apr 5, 2016

"Coloured coins" are a commonly proposed feature for electronic currencies. Basically they allow supporting multiple currencies in a single system, each of which balance individually. For Zcash, they could all share the same note anonymity set. We rejected this from 1.0 on grounds of complexity, but it deserves an issue ticket even if only to be able to refer to the idea.

@jackgavigan

This comment has been minimized.

Show comment
Hide comment
@jackgavigan

jackgavigan Jan 31, 2017

Contributor

In recent months, we have using the term "user-defined assets" (UDA) to refer to this concept.

To my mind, the goal should be to allow users to issue "native" assets - i.e. the new assets are effectively identical to ZEC in terms of functionality (including the ability to shield and unshield), they'll just have a different identifier. Note that this approach is very different to coloured coins, which effectively allows a user to "paint" a pre-existing, native coin instead of creating a new asset. This would allow anyone to create and transact new assets on the Zcash platform. Transaction fees would continue to be denominated in ZEC.

Questions to be explored include:

  • How to identify/differentiate user-defined assets? (e.g. an asset identifier based on a public key)
  • How to control issuance? (e.g. with the corresponding private key?)
  • What issuance models should be supported? Supply defined and fixed at the time of creation? Ongoing issuance - either unlimited or with a maximum supply set at the time of creation?
  • Should it be possible to issue assets privately or should all issuance happen transparently?
  • Should it be possible to redeem/withdraw assets from circulation (thereby formally reducing the total supply)?
  • Should there be multisig-style support for issuance?
  • Should it be possible to define an asset whose issuance is triggered from another blockchain (e.g. by depositing the other blockchain's asset into an escrow address/contract), and which can be redeemed/withdrawn back to the other blockchain? (This would effectively allow the Zcash network to be used as a payment channel).
  • Should there be a fee for creating a new asset type? (e.g. Payable to the Zcash Foundation?)

Once support for UDA is in place, the logical next step is to add support for what I'm dubbing "intra-chain atomic trades" (ICAT) - i.e. the ability to atomically swap different assets on the same blockchain. I've created a separate issue for that feature: #2053

Contributor

jackgavigan commented Jan 31, 2017

In recent months, we have using the term "user-defined assets" (UDA) to refer to this concept.

To my mind, the goal should be to allow users to issue "native" assets - i.e. the new assets are effectively identical to ZEC in terms of functionality (including the ability to shield and unshield), they'll just have a different identifier. Note that this approach is very different to coloured coins, which effectively allows a user to "paint" a pre-existing, native coin instead of creating a new asset. This would allow anyone to create and transact new assets on the Zcash platform. Transaction fees would continue to be denominated in ZEC.

Questions to be explored include:

  • How to identify/differentiate user-defined assets? (e.g. an asset identifier based on a public key)
  • How to control issuance? (e.g. with the corresponding private key?)
  • What issuance models should be supported? Supply defined and fixed at the time of creation? Ongoing issuance - either unlimited or with a maximum supply set at the time of creation?
  • Should it be possible to issue assets privately or should all issuance happen transparently?
  • Should it be possible to redeem/withdraw assets from circulation (thereby formally reducing the total supply)?
  • Should there be multisig-style support for issuance?
  • Should it be possible to define an asset whose issuance is triggered from another blockchain (e.g. by depositing the other blockchain's asset into an escrow address/contract), and which can be redeemed/withdrawn back to the other blockchain? (This would effectively allow the Zcash network to be used as a payment channel).
  • Should there be a fee for creating a new asset type? (e.g. Payable to the Zcash Foundation?)

Once support for UDA is in place, the logical next step is to add support for what I'm dubbing "intra-chain atomic trades" (ICAT) - i.e. the ability to atomically swap different assets on the same blockchain. I've created a separate issue for that feature: #2053

@jackgavigan jackgavigan changed the title from coloured notes to User-Defined Assets (UDA) Jan 31, 2017

@nathan-at-least

This comment has been minimized.

Show comment
Hide comment
@nathan-at-least

nathan-at-least Feb 20, 2017

Contributor

Here are some design constraints in the form of 'features we wish to avoid precluding':

  • Various simple UIT-based voting protocols. See zcash/zips#102 and the related but different voting-protocols work in #1112.
  • ICAT: indistinguishable multi-party-opt-in asset trades (see #2053).
Contributor

nathan-at-least commented Feb 20, 2017

Here are some design constraints in the form of 'features we wish to avoid precluding':

  • Various simple UIT-based voting protocols. See zcash/zips#102 and the related but different voting-protocols work in #1112.
  • ICAT: indistinguishable multi-party-opt-in asset trades (see #2053).

@nathan-at-least nathan-at-least changed the title from User-Defined Assets (UDA) to User Issued Tokens (UIT) Feb 23, 2017

@nathan-at-least

This comment has been minimized.

Show comment
Hide comment
@nathan-at-least

nathan-at-least Feb 23, 2017

Contributor

BTW- we've renamed this feature from "User-Defined Assets" to "User Issued Tokens".

Contributor

nathan-at-least commented Feb 23, 2017

BTW- we've renamed this feature from "User-Defined Assets" to "User Issued Tokens".

@Pratyush

This comment has been minimized.

Show comment
Hide comment
@Pratyush

Pratyush Mar 15, 2017

Our paper has some ideas on how such an updated interface might look:

https://eprint.iacr.org/2016/1033

It uses terminology from ZeroCash, but that shouldn't be too difficult to work around.

Pratyush commented Mar 15, 2017

Our paper has some ideas on how such an updated interface might look:

https://eprint.iacr.org/2016/1033

It uses terminology from ZeroCash, but that shouldn't be too difficult to work around.

@daira daira added this to Discussion in Sapling Protocol Upgrade Apr 20, 2017

@daira daira marked this as a duplicate of #2424 Jul 14, 2017

@daira

This comment has been minimized.

Show comment
Hide comment
@daira

daira Jul 14, 2017

Contributor

^ more precisely, I marked #2424 as a duplicate of this. (Grr, Github.)

Contributor

daira commented Jul 14, 2017

^ more precisely, I marked #2424 as a duplicate of this. (Grr, Github.)

@daira

This comment has been minimized.

Show comment
Hide comment
@daira

daira Oct 16, 2017

Contributor

There's a proposal for one way to do UIT at #2277 (comment) .

Contributor

daira commented Oct 16, 2017

There's a proposal for one way to do UIT at #2277 (comment) .

@gojomo

This comment has been minimized.

Show comment
Hide comment
@gojomo

gojomo Oct 24, 2017

To extend @jackgavigan's questions:

  • Could an issuer have an option as to whether the total initial issuance is public to any blockchain observer, or semi-private where they can create a private proof that exactly N have been issued? (Both seem useful even if holders' addresses & holders' balances are totally private.)
  • Can UIT holder prove their exclusive holdings as of a certain block, for example to qualify (in some external offchain system) to collect some benefit that is intended for holders-at-certain-levels? (For example: "everyone with at least 1 zNOM at block Y gets a commemorative t-shirt".)
  • Can the issuer 'airdrop" an on-chain amount (of ZEC or other UIT) to all UIT holders in proportion to their ownership – without in fact knowing the holder addresses/amounts, or forcing those to be revealed when the airdrop is collected? (If so, can another entity beside the issuer also do the same?) (If a precise proportionate allocation is impractical, might a probabilistic allocation, where holders' expected value matches their proportionate holdings, work?)

gojomo commented Oct 24, 2017

To extend @jackgavigan's questions:

  • Could an issuer have an option as to whether the total initial issuance is public to any blockchain observer, or semi-private where they can create a private proof that exactly N have been issued? (Both seem useful even if holders' addresses & holders' balances are totally private.)
  • Can UIT holder prove their exclusive holdings as of a certain block, for example to qualify (in some external offchain system) to collect some benefit that is intended for holders-at-certain-levels? (For example: "everyone with at least 1 zNOM at block Y gets a commemorative t-shirt".)
  • Can the issuer 'airdrop" an on-chain amount (of ZEC or other UIT) to all UIT holders in proportion to their ownership – without in fact knowing the holder addresses/amounts, or forcing those to be revealed when the airdrop is collected? (If so, can another entity beside the issuer also do the same?) (If a precise proportionate allocation is impractical, might a probabilistic allocation, where holders' expected value matches their proportionate holdings, work?)
@tromer

This comment has been minimized.

Show comment
Hide comment
@tromer

tromer Oct 24, 2017

Contributor

@gojomo Yes, our zkSNARK-based approach is flexible enough for supporting everything you described (with straightforward protocol extensions). We'll need to decide what to actually support, to keep complexity at bay, so can you suggest motivating use cases?

Contributor

tromer commented Oct 24, 2017

@gojomo Yes, our zkSNARK-based approach is flexible enough for supporting everything you described (with straightforward protocol extensions). We'll need to decide what to actually support, to keep complexity at bay, so can you suggest motivating use cases?

@gojomo

This comment has been minimized.

Show comment
Hide comment
@gojomo

gojomo Oct 24, 2017

I like Kickstarter-like projects as a model, but with added censorship-resistance & anonymity. So a blended use-case, here contrived but hopefully representative of possibilities, might be:

A team wants to execute some bit of art with a controversial political edge. (Maybe it's a monumental sculpture, maybe it's a documentary, maybe it's a computer game.) It might eventually generate recurring revenue, or be salable as a unit, when completed. They need help covering initial costs of $X00,000, and would like to offer patron's tokens with downstream benefits to those who can help supply the funds.

They'd want the system to help them irrevocably commit to some issuance plan (fixed or a range/schedule), then atomically exchange tokens for bona fide ZEC payments. The team will want to be able to prove the total number of tokens in existence, and perhaps reveal for some or all of the initial transfers how much ZEC were received. Some buyers will want to be able to prove their participation & at what cost, while others will want to remain anonymous.

To make the tokens attractive, a number of Kickstarter-like rewards would be offered. Say there's an opportunity for the work to include some messaging (such as a plaque of 'dedications' or list of credits/patron's-statements), to be determined not at initial-offering but some later date just before launch, available to any patron with more than X tokens. There'll be a launch party or other showings to which patrons with more than Y tokens get a free ticket. Some limited-edition branded-memento of the full work will be available after completion to all patrons with more Z tokens. Collecting these off-chain benefits would require a token-holder to prove their unique holding proportion, as of certain varying deadlines, together with a signed-request-for-delivery-of-the-benefit.

The completed work might generate recurring revenues, for example exhibition fees or licensed use in other commercial venues. The team may pledge that J% of such revenues are converted to ZEC and distributed to token-holders proportionately. Ideally receiving and then spending these ZEC would require no loss of privacy by token-holders. (That is, unlike claiming offline rewards above, there'd be no necessary interaction with other unshielded value-delivery systems.) Further, receiving such benefits should not consume the underlying tokens.

The completed work might have some terminal liquidation value, for example upon sale to a collector/distributor/exhibitor, of which the team has pledged that K% of such value be proportionately distributed to token-holders. This could be effected like the other distribution above – non-consumptive of the tokens – even though the intent of the team is that there be no further value to the tokens. Or it could be offered in a fashion that consumes the tokens: claiming a proportionate amount of this terminal value, in other ZEC/token-balances, necessarily retires (or sells) the corresponding tokens. (Even short of liquidation, this sort of standing 'open tender' might have interesting uses, if it could live on the blockchain for either a fixed-period, indefinitely, or until-cancelled. Perhaps hard to do in a shielded non-interactive fashion, though.)

In terms of priorities, a publicly-observable/enforced cap on issuance and ICAT #2053 seem foundational. An externalizable-proof-of-exclusive-holdings-as-of-date would enable allocating off-chain (and thus perhaps privacy-compromising) benefit-delivery. Proportionate on-chain airdrops of shielded value to holders would enable perpetual shielded revenue/profit-sharing.

gojomo commented Oct 24, 2017

I like Kickstarter-like projects as a model, but with added censorship-resistance & anonymity. So a blended use-case, here contrived but hopefully representative of possibilities, might be:

A team wants to execute some bit of art with a controversial political edge. (Maybe it's a monumental sculpture, maybe it's a documentary, maybe it's a computer game.) It might eventually generate recurring revenue, or be salable as a unit, when completed. They need help covering initial costs of $X00,000, and would like to offer patron's tokens with downstream benefits to those who can help supply the funds.

They'd want the system to help them irrevocably commit to some issuance plan (fixed or a range/schedule), then atomically exchange tokens for bona fide ZEC payments. The team will want to be able to prove the total number of tokens in existence, and perhaps reveal for some or all of the initial transfers how much ZEC were received. Some buyers will want to be able to prove their participation & at what cost, while others will want to remain anonymous.

To make the tokens attractive, a number of Kickstarter-like rewards would be offered. Say there's an opportunity for the work to include some messaging (such as a plaque of 'dedications' or list of credits/patron's-statements), to be determined not at initial-offering but some later date just before launch, available to any patron with more than X tokens. There'll be a launch party or other showings to which patrons with more than Y tokens get a free ticket. Some limited-edition branded-memento of the full work will be available after completion to all patrons with more Z tokens. Collecting these off-chain benefits would require a token-holder to prove their unique holding proportion, as of certain varying deadlines, together with a signed-request-for-delivery-of-the-benefit.

The completed work might generate recurring revenues, for example exhibition fees or licensed use in other commercial venues. The team may pledge that J% of such revenues are converted to ZEC and distributed to token-holders proportionately. Ideally receiving and then spending these ZEC would require no loss of privacy by token-holders. (That is, unlike claiming offline rewards above, there'd be no necessary interaction with other unshielded value-delivery systems.) Further, receiving such benefits should not consume the underlying tokens.

The completed work might have some terminal liquidation value, for example upon sale to a collector/distributor/exhibitor, of which the team has pledged that K% of such value be proportionately distributed to token-holders. This could be effected like the other distribution above – non-consumptive of the tokens – even though the intent of the team is that there be no further value to the tokens. Or it could be offered in a fashion that consumes the tokens: claiming a proportionate amount of this terminal value, in other ZEC/token-balances, necessarily retires (or sells) the corresponding tokens. (Even short of liquidation, this sort of standing 'open tender' might have interesting uses, if it could live on the blockchain for either a fixed-period, indefinitely, or until-cancelled. Perhaps hard to do in a shielded non-interactive fashion, though.)

In terms of priorities, a publicly-observable/enforced cap on issuance and ICAT #2053 seem foundational. An externalizable-proof-of-exclusive-holdings-as-of-date would enable allocating off-chain (and thus perhaps privacy-compromising) benefit-delivery. Proportionate on-chain airdrops of shielded value to holders would enable perpetual shielded revenue/profit-sharing.

@daira

This comment has been minimized.

Show comment
Hide comment
@daira

daira Nov 21, 2017

Contributor

@jackgavigan wrote:

To my mind, the goal should be to allow users to issue "native" assets - i.e. the new assets are effectively identical to ZEC in terms of functionality (including the ability to shield and unshield), they'll just have a different identifier.

I had been assuming that UITs would be shielded-only. Assuming we have full selective disclosure and the performance improvements from Sapling, is there any compelling use case for unshielded UITs?

Contributor

daira commented Nov 21, 2017

@jackgavigan wrote:

To my mind, the goal should be to allow users to issue "native" assets - i.e. the new assets are effectively identical to ZEC in terms of functionality (including the ability to shield and unshield), they'll just have a different identifier.

I had been assuming that UITs would be shielded-only. Assuming we have full selective disclosure and the performance improvements from Sapling, is there any compelling use case for unshielded UITs?

@jackgavigan

This comment has been minimized.

Show comment
Hide comment
@jackgavigan

jackgavigan Nov 28, 2017

Contributor

If it's shielded-only, how would a publicly-observable/enforced cap on issuance work?

Also, there may be use cases where transparency is desirable (e.g. public voting, distributing funds for aid or grants).

Contributor

jackgavigan commented Nov 28, 2017

If it's shielded-only, how would a publicly-observable/enforced cap on issuance work?

Also, there may be use cases where transparency is desirable (e.g. public voting, distributing funds for aid or grants).

@RiganoESQ

This comment has been minimized.

Show comment
Hide comment
@RiganoESQ

RiganoESQ May 20, 2018

will coloured coins be supported on sapling? will sapling support smart contracts?

RiganoESQ commented May 20, 2018

will coloured coins be supported on sapling? will sapling support smart contracts?

@daira

This comment has been minimized.

Show comment
Hide comment
@daira

daira May 29, 2018

Contributor

@archmaester: no and no. Sapling is already a very ambitious upgrade without either of those features.

There is however a proposal for how to do UITs building on Sapling: #2277 (comment)

(Edit: unfortunately that link doesn't go to the specific comment because it is hidden by default. Expand the hidden comments and then reload to see it.)

Contributor

daira commented May 29, 2018

@archmaester: no and no. Sapling is already a very ambitious upgrade without either of those features.

There is however a proposal for how to do UITs building on Sapling: #2277 (comment)

(Edit: unfortunately that link doesn't go to the specific comment because it is hidden by default. Expand the hidden comments and then reload to see it.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment