Additional attributes for SP tokens

[marv-engine]

Originally posted as mastercoin-MSC/Master_Protocol_Product_Requirements#5

[dacoinminster]

The original description was:

The following attributes should be added to SP tokens:

1. activation date
2. expiration date
3. can/cannot be transferred
4. can/cannot be shared

Activation and expiration dates can be used to implement membership. An address that owns a membership token can present it to get access to certain privileges/functions. An issuer can administer membership for an address by updating the activation/expiration dates, e.g. based on the user paying for a subscription. Membership may also be count-based, so an address would spend a membership token for each use (while the membership is active).

Issuers may want to restrict tokens that are issued so they can't be transferred to another address or so that they can be shared equally among multiple addresses.

[dacoinminster]

I prefer to put activation date and expiration date in the property description, not the protocol.

The previous conversation about this (linked above) included some worry about whether spammers might send people non-transferable tokens, but I see no problem with letting people PURCHASE non-transferrable tokens. However, I would only want to do this if people demand it.

I'm marking this low priority / far future for now. If somebody revisits this in a year and there has been no push for this, feel free to close.

[zathras-crypto]

Just wanted to add this is a substantial engineering change.

At the moment attributes are assigned to properties the collective, not
property tokens the individual token.

There is currently no model for storing attributes for each individual
token which is being discussed here.

MP is a state balance based system. You can have 10 Marv (#5) tokens
sure. But each individual Marv (#5) token is not a unique entity on its
own to which we can apply unique attributes such as expiry date.

TL:DR we keep state of the attributes for a given property and each address
can hold a balance of that property. It would be a huge shift to start
tracking every individual token as a unique object with its own attributes
and state would become unmanageable very quickly.

Thanks
Zathras
On May 10, 2014 3:28 AM, "dacoinminster" notifications@github.com wrote:

I prefer to put activation date and expiration date in the property
description, not the protocol.

The previous conversation about this (linked above) included some worry
about whether spammers might send people non-transferable tokens, but I see
no problem with letting people PURCHASE non-transferrable tokens. However,
I would only want to do this if people demand it.

I'm marking this low priority / far future for now. If somebody revisits
this in a year and there has been no push for this, feel free to close.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/152#issuecomment-42691883
.

[marv-engine]

@zathras-crypto I'm not thinking of assigning values for these attributes to individual tokens. These would be like the other attributes that are assigned when the token collection is created.

Such tokens could be used, for instance, as a credential provided to a particular address by an issuing authority under controlled circumstances. That address could then present that credential to another party and that party would know that the address had received the token directly from the issuer.

[zathras-crypto]

Ah OK thanks Marv, perhaps a context thing - I had read it as assigning
attributes to a specific token (a la colored coins if you will) which isn't
really a feasible prospect for MP right now, so just wanted to make sure
that was clear - seems like my point is moot :P

Thanks
Zathras

On Tue, May 13, 2014 at 3:26 AM, Marv Schneider notifications@github.comwrote:

@zathras-crypto https://github.com/zathras-crypto I'm not thinking of
assigning values for these attributes to individual tokens. These would be
like the other attributes that are assigned when the token collection is
created.

Such tokens could be used, for instance, as a credential provided to a
particular address by an issuing authority under controlled circumstances.
That address could then present that credential to another party and that
party would know that the address had received the token directly from the
issuer.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/152#issuecomment-42861766
.

[dexX7]

I'd like to give this topic a push. It's sort of related but also slightly different from "tokens-to-represent-some-right-or-policy" of #257 (comment) and this tackles the base layer of building blocks.

I believe for some time: if a base set of token classes and properties is available, then almost everything we try to do could be derived and build. Whether that are options, futures, maybe crowdsales, autonomous agents etc.

For example: Tx 54: New Property with Managed Number of Tokens would basically make Tx 50: New Property Creation with Fixed number of Tokens obsolete and redundant, if there were a property-flag "issuance-of-new-units: allowed" and "issuance-of-new-units: locked".

@genecyber's "generate tokens on demand" generator scheme as described in #230 (comment) is also a nice example and removes the need for Tx 56: Granting Tokens for a Managed Property. I'm not talking about efficiency or actually proposing the a removal of tx 56, but I want to raise awareness for the general idea.

I propose to brainstorm, collect ideas and list potential properties, then optimize and see where this is going.

Let's get this started:

1. tokens may have an activation date (use case: membership)*
2. tokens may have an expiration date (use case: membership, futures)
3. tokens may be transferred only a limited number of times (use case: identity, vote tokens)
4. tokens may be revoked by an user or issuer (use case: options, handy for whitelist/blacklist tokens)
5. tokens may be removed by an action (use case: redeemable coupons)
6. issuance of new token units may not be restricted (managed tokens) (use case: dynamic supply)
7. token's manager ("right to issue" etc.) may change (use case: new company owner)

Point 1 seems unnecessary, because this could be achieved passively, e.g. by issuing tokens at activation date and not earlier.

[genecyber]

I like this, it sounds similar to how I've steuctured the API I'm building to work with SP.

In the end you can end up with the ability to define all new tx types by adjusting properties on the coin, issuance, address, issuer etc.

[dexX7]

Yeah, that's basically the idea. Advanced transaction types should be expressed by combining a few base operations, e.g.:

Tx 50: create new property + issue n units + "restrict issuance of new units"
Tx 51: create new property + X*
Tx 54: create new property

*What is X? I have a very, very difficult time to break this down.

[dacoinminster]

I agree the features proposed would be cool and potentially useful, but given coding bandwidth restrictions, and how many features projects are desperately clamoring for, I tend to deprioritize the features which I'm not hearing from projects that they need.

[dexX7]

A discussion about this doesn't equal the demand of a high priorization or alike. I'd be very happy, if there were a place for those things which is not necessarily the issue section of the spec.

Finding a good model to describe the whole system and it's state has actually also a relation to the current developement, because persistence of information requires data structures that accurately represent every aspect of the system's state and breaking things down potentially allows more efficient code. :)

[marv-engine]

Several months ago, Dom created https://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements as a place to capture and discuss these topics.

Optimally, all proposed changes to the spec would be referenced to items and decisions in the Product Reqs repo.

I agree that a system-wide longterm view of the architecture/functionality/features is the place to start. Then it's primarily a matter of making sure each step we take keeps us on the right path. This could be a regularly scheduled topic for the weekly Thursday dev group discussions.

[dexX7]

Thanks Marv, I actually assumed this is a place where companies should post their wishes, so to speak and I'm aware of this repo, but it's inactive and let me put it this way: even if the spec isn't the appropriate place, it's one of the not-so-many active MSC spaces. Might be worth to reconsider #228 - using /spec for "real issues" and some other place for "proposals and discussion about close-to-be-implemented features".