Manually issued Smart Property Tokens

[wanderingbort]

This is a proposed addition to the spec to cover Smart Properties whose tokens are perpetually being created and destroyed to fulfill some application level purpose. For these properties, the protocol is only used to issue, transact and burn tokens. All logic concerning when the actions that affect the token pool are appropriate is left up to the discretion of address that broadcast the original smart property definition.

There are a few obvious use cases at this time:

1. Grants/Revocations of tokens based things the protocol can not verify directly (non-digital asset trades, loyalty and rewards programs)
2. Grants/Revocations of tokens which are authoritatively controlled by a central body (eg private/public equity stock)

Most notably is the project that @CraigSellars is involved in which requires the ability to grant and revoke tokens at will.

Some Notes:

• Grants/Revokes include memo field meant to allow the application/human level logic that drives these protocl messages a black space to put data in for itself. The protocol does nothing but store this information under the assumption that it is application/human relevant.
• There was some discussion with @marv-engine on whether a (proposed)TX-55 should be a combo "Grant/Send" such that the new tokens are sent to the address that is the destination for the master protocol transaction rather than the wallet that broadcasts the SP transactions. For now, it is just a "Grant" and the newly granted tokens must be sent explicitly with a simple send. Certainly willing to entertain the other way.

[dacoinminster]

This is an excellent pull request. The added functionality is elegant, and will have lots of uses.

I have reviewed the changes, and I approve this pull request. I think Marv should take a look before merging, as he may have questions. Once he is satisfied, I think we can merge this right away.

Thanks!

[dexX7]

Awesome, I'd really like to see such a feature. I have a bit of feedback:

Tx 54: reorder the meta-data fields and place the name field at the very beginning. It's the most important piece of information and in the case where category and sub-category are ignored or become optional in general (future, in theory), then no change is required. Say I want to create token X with [ecosystem: 2] [type: 1] [previous: 0] [category: blank] [subcategory: blank] [name: some-name] [...] - seems out of order, no? This also provides a benefit for services and clients which only fetch the name, but ignore the rest.

Tx 54: probably a much broader question: why enforce a name at all? The name and category system provides no critical information of any kind and the only important piece of data is a property id. All the meta-data can range from being useless for an application, over scamish-name-squatting at worst to some-human-readable-information at best. Furthermore not every property might be created with the intention to be used outside of a very limited scope. More thoughts about this at the end.

Tx 55, 56: looks fine, but just as before: I suggest to define the memo field as an option, not as a requirement (if this is the case).

While we are at it, I'd like to bring up the following points which I consider as very valuable:

1. Provide an option to lock the issuance of new and the removal of old tokens (strictly seen: two seperated actions and states). This seems very important to me, given that not every use-case can be satisfied by a fixed supply defined right at the start (tx: 50) nor by an variable supply (tx: 54) which may change whenever the issuer feels to do so. The arguments "but it lies in the hand of the issuer anyway" or "just don't create new tokens" don't fit, because under this premise the whole need for tx 54 (instead of tx 50) can be questioned. Down to earth use-case: crowdsale with several stages over time, but fixed amount of total tokens.
2. Provide an option to transfer ownership. Companies' structure may change for example, but even more important: wallets can become compromised. The later is very relevant to the first point, too.
3. Provide an endpoint where tokens are removed without manual action required by the issuer. To name a few applications and use-cases: redeemable coupons, invite passes, tickets, credits (in the sense of: "burn 30 tokens to extend your access by 30 days"), but also complex concepts like the Bitcoin Difficulty Derivates or Deprived Mining Speculation (brilliant solutions to create derivates, used back in the days of BTCT) are something I'm thinking about.

While tx 54 was probably created due to the need of increasing the actual supply without hording huge amounts of tokens and accessing the (cold wallet) token storage every time, point 3 can be seen as natural extension of this.

---

I'm wondering a bit about the fields "property type" and "previous property id". The introduction of tx 54-56 might depreciate "previous property id" or might be the first true application of this field. It serves the purpose of a pointer or reference in the case that a property is replaced or extended. JR's initial intention was something like "if you want to issue more tokens, then create a new property with different amount of tokens, reference and abandon the old one", if I'm not mistaken (please correct me, if I'm wrong). As far as I know it was never used in the wild, but with those new transaction types it might be worth to explore the usage and usefulness of this field once again. To me "previous property" and "property type" (new, replaced, appended) seems to combine some meta-data (reference to another property) with some hint of the action which is performed. Since properties are created explicitly and their supply is managed explicitly, I feel like I'm missing the point what those fields are intended to be used for.

But in addition, the "property type" field is also used as (justified and very solid) hint for UIs to differentiate between divisible and non-divisible tokens, thus it binds some kind of characteristic to the token. I'm wondering, if it might make sense to use this field explicitly to specify the type of tokens a bit further - in this context: to differentiate between managed and unmanaged tokens This conflicts with my first point above though, which allows to change the state of "managed" to "unmanaged".

---

(protocol philosophy)

This brings up another question and I am wondering about the implications of tx 54, an option to lock the supply and the greater picture related to tx 50, tx 51 and tx 54. All three share the ability to create new property where tx 50 is the most basic one, tx 51 does quite a lot and adds automated issuance and distribution based on some state information (invested amounts, time based bonus, deadline) and tx 54-54 introduce the concept of manageable tokens. To put it into another perspective: if we throw in the ability to lock the supply, then this can basically further broken down to:

Tx 50: "create new property" + "issue amount n" + "lock supply"
Tx 51: "create new property" + ___
Tx 54: "create new property"

... I stop here, but I'm getting really excited, because I've never looked at it this way.

---

(meta-data)

I'm not a fan of meta-data in the blockchain and especially the structure of [name, category, subcategory, url, data] is very bound and limited to a specific data context, but not every token is a coin and not every smart property has a relation to a website. And as mentioned, especially not every smart property might be created with the intention to be used by the public, but maybe in a very isolated environment where it's critical to avoid the leak of any information about the usage or type of a property.

Stuffing Mastercoin transactions with other data (strictly seen: a change output at minimum) or junk is perfectly accepted on a protocol level. If I wanted to attach anything additional, such as meta-data, I would simply append it after the last field. Thus the request of reordering the fields at minimum, so that the important fields are at the beginning. I created another post about this topic in general some time ago: #222

[wanderingbort]

RE: meta-data, I am in agreement with @dexX7 . My preference, is that information encoded in the blockchain be reduced to the minimal set necessary to operate the protocol. Concessions can be made for things like the "memo" field to allow a small bits of application data to be securely attached.

The current proposal is metadata heavy because the existing SP transactions are metadata heavy and I wanted to fit in with the existing transaction scheme.

I am fine with the memo being optional, I will update that soon. As for re-ordering the fields on the initial broadcast, I am fine with it, but if we are going to break the pattern we may as well seriously discuss moving lots of the metadata offchain.

As for transferring ownership and locking new grants/revokes, those may be better achieved through the sister PR #244 . There is no way (currently) to irrevocably lock certain transactions in that PR as new administration could always impose new rules, but that may be desirable.

[dexX7]

I totally missed that you mirrored the current structure and didn't even think about how it's organized at the moment. The current design is indeed pretty metadata heavy and build around the idea of a system which is kinda similar to a warehouse where items are categorized with tx 52 (promote a property) probably being the tip of the iceberg. I'm split and actually agree that breaking the pattern now might not be the best move, given the whole context.

While I also agree with you related to the usefulness of #244, it fundamentally seems to change everything and given the complexity, I'd seperate here.

By adding the ability to add/remove tokens of an existing property you already opened pandora's box in my opinion and introduced the concept of "managed" and "unmanaged" properties with all benefits and new attack vectors this brings - going one step further and adding a transition from "managed" to "unmanaged" doesn't seem too far. Locking property creation mainly serves as assurance that supply won't change after a given point, guarding against intentional or unintentional issuance of new tokens (e.g. in the case of a compromised wallet or issuer). I see a benefit of a transfer of ownership under a similar security aspect, but also due to the new functionality.

The need (in my opinion) for additional mechanisms is directly linked to the new ability of adding tokens.

Adding an explicit endpoint to remove tokens from the system might be used by an issuer to avoid touching the wallet which is able to create new tokens, but also paves the way for autonomous service providers - basic example: let X be the removal endpoint of A tokens and at the same time setup a sale of B tokens which can be purchased by sending A tokens to X -- now you have a token-exchange service... :).

[marv-engine]

change "Instead to additional ..." to "Instead two additional ...".

We have to see if the spec or the code assumes there is a non-zero number of tokens for each smart property. I expect not, e.g. a crowdsale creates the smart property but no tokens are issued until the first user sends a payment.

[marv-engine]

A couple of related items -

1. We should take some time now to consider possible future uses/features/capabilities so that we don't preclude or make awkward something we want to do later.
2. For example, how about an expiration date when the tokens are first sent? Customer loyalty programs have points with a limited lifetime, coupons behave the same way. Everything has a lifetime of some sort. (This might be the first instance of uniquely identifiable tokens, but I don't think that's necessary for implementation.)

[wanderingbort]

@marv-engine , great catches in the PR, I will update soon with changes to reflect the various restrictions.

Re: additional scope. Some things like a optional maximum tokens may only have slight impacts on the logic however bigger additions like token expiry may be too much to consider for this.

Re: different grant/removal addresses. Part of this is achievable through the SP administration PR and application level logic. Any address in the Administration pool should/could/would qualify under all the restrictions currently listed as only valid from the address that initially broadcast the SP. Thats the legacy version of Administration and you could have several addresses all with application level semantics attached to them.

The side-project with @CraigSellars will involve a fully automated grant/revoke pipeline using addresses in this manner, building our own mini-consensus bots out of mastercore instances and inferring the data we need for automated approval from the addresses and memos.

[CraigSellars]

Great discussion - I love the idea of the token exchange service.
As the outstanding comments have been addressed, I am merging this pull request.