Additional attributes for SP tokens

[marv-engine]

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.

[ProphetX10]

Marv, can you elaborate on the use case for sharing among multiple addresses?

Are you talking about m of n input? Do we even support that?

Thanks,

Dominik Zynis Head Evangelist Mastercoin Foundation Mastercoin.org http://mastercoin.org/ dom@mastercoin.org +1-415-800-4155 +34-697-41-22-01 dominik.zynis (skype)

Assistant: Joanne joannemtria@gmail.com

On Mon, Apr 21, 2014 at 3:53 PM, Marv Schneider notifications@github.comwrote:

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.

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements/issues/5 .

[dacoinminster]

I am leary of these particular features, but we can do them if that is what the market is demanding.

On Wed, Apr 23, 2014 at 5:08 AM, Dominik notifications@github.com wrote:

Marv, can you elaborate on the use case for sharing among multiple addresses?

Are you talking about m of n input? Do we even support that?

Thanks,

Dominik Zynis Head Evangelist Mastercoin Foundation Mastercoin.org http://mastercoin.org/ dom@mastercoin.org +1-415-800-4155 +34-697-41-22-01 dominik.zynis (skype)

Assistant: Joanne joannemtria@gmail.com

On Mon, Apr 21, 2014 at 3:53 PM, Marv Schneider notifications@github.comwrote:

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.

— Reply to this email directly or view it on GitHub< https://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements/issues/5>

.

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements/issues/5#issuecomment-41153046 .

[marv-engine]

Think of it as a group credential. Use cases for sharing includes:

• group memberships (e.g. members of a family are all entitled to use the same subscription services - based on having the single "member" token for that family)
• any group affiliation, e.g. specifying a role within an organization - manager, administrator, employee, club member

The owner of a shared token keeps the single token when it sends a copy to another address. This is complementary to transferring a token where the token moves from one address to another. The ability to transfer is separate from the ability to share. Permissions could be specified such that only the issuer or specified administrators can transfer or share a token.

Memberships can be granted and revoked - for individuals or for all holders of a particular token.

@dacoinminster what aspects are you concerned about?

[dacoinminster]

I guess I'm mostly reacting to the restriction on transfers. As long as the UI makes it clear when you get the token that it cannot be transferred, I guess that would be ok. I just have a negative reflex to the concept of having a token, but it not really be completely mine.

Also there are weird things like what if I spam the world with tons of non-transferrable tokens that they can never get rid of? That just seems like a strange restriction, and I'm not seeing the use cases for limiting transfers.

On Wed, Apr 23, 2014 at 9:53 AM, Marv Schneider notifications@github.comwrote:

Think of it as a group credential. Use cases for sharing includes:

• group memberships (e.g. members of a family are all entitled to use the same subscription services - based on having the single "member" token for that family)
• any group affiliation, e.g. specifying a role within an organization
• manager, administrator, employee, club member

The owner of a shared token keeps the single token when it sends a copy to another address. This is complementary to transferring a token where the token moves from one address to another. The ability to transfer is separate from the ability to share. Permissions could be specified such that only the issuer or specified administrators can transfer or share a token.

Memberships can be granted and revoked - for individuals or for all holders of a particular token.

@dacoinminster https://github.com/dacoinminster what aspects are you concerned about?

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements/issues/5#issuecomment-41186104 .

[marv-engine]

Good points, which can be addressed in a beneficial way. We need to work thru the use cases. My initial thoughts:

Restricting transfers

Recipients would be able to transfer the token back to the address that sent it. This is in addition to the issuer being able to revoke the token by taking it back, for instance when a membership is canceled or an employee leaves a company or the MVA revokes someone's driver license. These tokens are presented as credentials, not spent, so they can't be passed around without any oversight or control.

Attributes for sharing/transferability might be specified when the SP is created and/or with a new Send transaction for more fine grained control and flexibility.

Token spam

I hadn't thought about that. People need to be able to protect themselves from it, so we should give this serious consideration. As with social media contacts and messages, people could choose to:

1. not accept unsolicited tokens
2. opt-in/opt-out of tokens from particular issuers or of particular types
3. explicitly accept or reject a transaction that attempts to deliver tokens

Wallets should make it easy for a user to apply the same settings to multiple addresses in the wallet.

[ProphetX10]

Basically the issue that comes into play is that some of these guys who have investment funds for investors need to be able to restrict the trading to people they know, or that their partners know. But of course we do not want to expose that data in the blockchain, only that they are part of some group if you will.

So that if some regulator comes to them and say... ahah you have been selling shares to the public, they can say no we haven't our shares only can trade with people who are in our private network, and here is our proof.

Now there actually needs to be 2 types of tokens for this. 1 token (call it ID Token, IDTs) is the no transfer token that Marv mentions, another is a token that gives someone other address the right to issue no transfer tokens (ID Network Token, IDNeTs) that are linked to the originating address. So you get this chain of privilege to issue no transfer tokens. The parent does not necessarily need to accept child issued no transfer tokens, and children can decide how many generations they would go back.

So for example if ACME Investments Group (AIG) has affiliates around the world they can issue IDNeTs to those affiliates, then those affiliates can issue IDTs to their local clients with a setting of 1 for going back one generation to AIG. AIG then issues ACME Fund tokens with a link to the originating IDNeT issuance with a setting of 0 for all generations of IDNeTs. Now any key with an IDT whose ancestral genesis node is AIG will be able to trade into ACME Fund, while identity information is store with the person who has the local relationship and vouches for that address.

I know personally that Judith and I are working on a few opportunities that will need something like this.

Thanks,

Dominik Zynis Skype: dominik.zynis USA: +1-415-800-4155 dominik.zynis@gmail.com

On Fri, Apr 25, 2014 at 4:02 PM, Marv Schneider notifications@github.comwrote:

Good points, which can be addressed in a beneficial way. We need to work thru the use cases. My initial thoughts: Restricting transfers

Recipients would be able to transfer the token back to the address that sent it. This is in addition to the issuer being able to revoke the token by taking it back, for instance when a membership is canceled or an employee leaves a company or the MVA revokes someone's driver license. These tokens are presented as credentials, not spent, so they can't be passed around without any oversight or control.

Attributes for sharing/transferability might be specified when the SP is created and/or with a new Send transaction for more fine grained control and flexibility. Token spam

I hadn't thought about that. People need to be able to protect themselves from it, so we should give this serious consideration. As with social media contacts and messages, people could choose to:

1. not accept unsolicited tokens
2. opt-in/opt-out of tokens from particular issuers or of particular types
3. explicitly accept or reject a transaction that attempts to deliver tokens

Wallets should make it easy for a user to apply the same settings to multiple addresses in the wallet.

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements/issues/5#issuecomment-41395550 .

[dexX7]

Also there are weird things like what if I spam the world with tons of non-transferrable tokens that they can never get rid of?

This really shouldn't be an issue. Wallets will need filters and options to hide tokens permanently or temporarily anyway and a shift from "everything and anything is listed" is likely going to happen once tokens are not only used as form of value transmitter.

[ProphetX10]

one man's spam is another man's survival food

Thanks,

Dominik Zynis Skype: dominik.zynis USA: +1-415-800-4155 dominik.zynis@gmail.com

On Fri, Apr 25, 2014 at 4:58 PM, dexX7 notifications@github.com wrote:

Also there are weird things like what if I spam the world with tons of non-transferrable tokens that they can never get rid of?

This really shouldn't be an issue. Wallets will need filters and options to hide tokens permanently or temporarily anyway and a shift from "everything and anything is listed" is likely going to happen once tokens are not only used as form of value transmitter.

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements/issues/5#issuecomment-41402024 .

[marv-engine]

one man's spam is another man's survival food

Just like the owner of an address can control what goes out from that address, the owner should also have control over what comes in.

[dacoinminster]

I don't think we CAN control what comes in actually. People can already spam addresses with worthless metacoins if they want. It would still be a hassle, even if they were transferable.

I think dexx is right that we just need to have smart UI which can hide stuff users don't want to see.

On Fri, Apr 25, 2014 at 8:20 AM, Marv Schneider notifications@github.comwrote:

one man's spam is another man's survival food

Just like the owner of an address can control what goes out from that address, the owner should also have control over what comes in.

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements/issues/5#issuecomment-41404563 .

[marv-engine]

Transferability has nothing to do with protection from token spam.

I don't understand why it is that users have to accept whatever anyone sends, and then pay to remove it (e.g. send it back or send it anywhere). For instance, adult entertainment and gambling businesses are notoriously early adopters of new technology. It's just a matter of time before they figure out how to make money using SPs. I expect it's a very small percentage of our target end-user community that would want (their family members) to receive unsolicited trial memberships to such enterprises. Then it will spiral out of control as related businesses see who has these trial memberships and send them even more unwanted tokens. Charitable organizations could use the same approach to see who has a lot of wealth in coins and send tokens soliciting donations.

[dacoinminster]

Yup. A UI setting for "Don't show me unsolicited/unexpected payments in currencies I don't care about" would be good for that.

I just don't want to put it in the protocol.

On Fri, Apr 25, 2014 at 12:22 PM, Marv Schneider notifications@github.comwrote:

Transferability has nothing to do with protection from token spam.

I don't understand why it is that users have to accept whatever anyone sends, and then pay to remove it (e.g. send it back or send it anywhere). For instance, adult entertainment and gambling businesses are notoriously early adopters of new technology. It's just a matter of time before they figure out how to make money using SPs. I expect it's a very small percentage of our target end-user community that would want (their family members) to receive unsolicited trial memberships to such enterprises. Then it will spiral out of control as related businesses see who has these trial memberships and send them even more unwanted tokens. Charitable organizations could use the same approach to see who has a lot of wealth in coins and send tokens soliciting donations.

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements/issues/5#issuecomment-41429985 .

[marv-engine]

Setting this option in one UI will have no effect in any other. It has to be an attribute of the address - so maybe the option is itself set with an advisory token that all(?) UI's agree to obey.

What's your objection to a user blocking unwanted tokens?

[ProphetX10]

this is one of those things that something should be developed when the actual problem presents itself.

bitcoin tx are not free, and to date i have never had any address spam me with free btc

we just have to be careful with dividend payments as that is a one to many messaging approach, which is why only the issuer should be able to send them, or create a token to give dividend distro capability to another address

Thanks,

Dominik Zynis Skype: dominik.zynis USA: +1-415-800-4155 dominik.zynis@gmail.com

On Fri, Apr 25, 2014 at 9:59 PM, Marv Schneider notifications@github.comwrote:

Setting this option in one UI will have no effect in any other. It has to be an attribute of the address - so maybe the option is itself set with an advisory token that all(?) UI's agree to obey.

What's your objection to a user blocking unwanted tokens?

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/Master_Protocol_Product_Requirements/issues/5#issuecomment-41433442 .