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.

[prophet10x]

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//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//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//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.

[prophet10x]

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//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.

[prophet10x]

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//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//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//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?

[prophet10x]

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//issues/5#issuecomment-41433442
.