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

Manually issued Smart Property Tokens #243

Merged
merged 3 commits into from Aug 29, 2014

Conversation

Projects
None yet
5 participants
@wanderingbort
Copy link
Contributor

wanderingbort commented Aug 20, 2014

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 comment has been minimized.

Copy link
Contributor

dacoinminster commented Aug 20, 2014

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

This comment has been minimized.

Copy link
Member

dexX7 commented Aug 20, 2014

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

This comment has been minimized.

Copy link
Contributor

wanderingbort commented Aug 21, 2014

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

This comment has been minimized.

Copy link
Member

dexX7 commented Aug 21, 2014

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... :).

README.md Outdated

Description: Transaction type 54 is used to create a new Smart Property whose token pool is actively managed by the address that creates the property.

Creating a managed smart property does not automatically grant any tokens to the address that broadcasts the transaction. Instead to additional transaction types exist to actively manage the size of the token pool: [Grant Tokens](#granting-tokens-for-a-managed-property) and [Revoke Tokens](#revoking-tokens-for-a-managed-property).

This comment has been minimized.

@marv-engine

marv-engine Aug 21, 2014

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.

|Property Name | [String null-terminated](#field-string-255-byte-null-terminated) | “Quantum Miner\0” (14 bytes)|
|Property URL| [String null-terminated](#field-string-255-byte-null-terminated) | “tinyurl.com/kwejgoig\0” (21 bytes) |
|Property Data | [String null-terminated](#field-string-255-byte-null-terminated) | “\0” (1 byte) |

This comment has been minimized.

@marv-engine

marv-engine Aug 21, 2014

How about a field to specify the max number of tokens that can exist at any one time? Otherwise the limit is the "9 gazillion" value.

README.md Outdated

Description: Properties issued with a [Property with Managed Number of Tokens](#new-property-with-managed-number-of-tokens) transaction have no tokens by default. After issuance, tokens may be added to the balance of the wallet whose address originally broadcast the property creation transaction.

It is invalid to attempt to grant tokens on any property that was not broadcast as a [Property with Managed Number of Tokens](#new-property-with-managed-number-of-tokens).

This comment has been minimized.

@marv-engine

marv-engine Aug 21, 2014

It's invalid to attempt to grant tokens on any property that was created by another address.

README.md Outdated

### Granting Tokens for a Managed Property

Description: Properties issued with a [Property with Managed Number of Tokens](#new-property-with-managed-number-of-tokens) transaction have no tokens by default. After issuance, tokens may be added to the balance of the wallet whose address originally broadcast the property creation transaction.

This comment has been minimized.

@marv-engine

marv-engine Aug 21, 2014

Balances are owned directly by addresses. Addresses may be contained in wallets, but that's an application-level construct beyond the scope of the spec.

How about including an optional destination address for the generated coins? That would save tx fees and time.

README.md Outdated
| Transaction type | [Transaction type](#field-transaction-type) | 55|
| Property ID | [Currency identifier](#field-currency-identifier) | 8 |
| Number Properties | [Number of coins](#field-number-of-coins) | 1,000 |
| Memo | [String null-terminated](#field-string-255-byte-null-terminated) | “First Milestone Reached!” (24 byte) |

This comment has been minimized.

@marv-engine

marv-engine Aug 21, 2014

We should generalize this memo facility. If it's available for this tx, it should be available for any other tx. I strongly believe variable length strings such as this shouldn't be stored in the blockchain.

This comment has been minimized.

@dexX7

dexX7 Aug 21, 2014

Member

Maybe replace all "property data" fields with "memo"? The underlying data type is "null terminated string" anyway, but "memo" is much more telling. - I share your sentiment about blockchain storage and @wanderingbort already agreed to flag this field as optional.

This comment has been minimized.

@wanderingbort

wanderingbort Aug 22, 2014

Contributor

I am fine with both making this a fixed size optional field (my suggestion would be 20 bytes). I am also fine with removing all the metadata save for this optional memo/key that can be used to ID related metadata hosted as a signed blob on a 3rd party service.

My only major concern with it, is the inconsistency with the rest of the smart property issuance transactions. I think my hesitation is that we could have a separate PR which ups the transaction versions of all existing SP issuance and removes metadata that would achieve the same effect and keep consistency.

This comment has been minimized.

@dexX7

dexX7 Aug 23, 2014

Member

Fixed size? I actually think the statement was meant as "if a memo field is available in this transaction, then it should be available in other transactions as well" + "a memo shouldn't be stored on the blockchain".

Other text fields allow a length of 255 byte, so I would stick to this number, but since the field is at the end of the transaction, (also in general) one could easily add more text behind without invalidating the transaction. Though this wouldn't be parsed and shown by clients which honor the protocol.

README.md Outdated

Description: Properties issued with a [Property with Managed Number of Tokens](#new-property-with-managed-number-of-tokens) transaction may have tokens revoked from the balance of the wallet address that originally broadcast the property creation transaction.

It is invalid to attempt to revoke tokens on any property that was not broadcast as a [Property with Managed Number of Tokens](#new-property-with-managed-number-of-tokens).

This comment has been minimized.

@marv-engine

marv-engine Aug 21, 2014

It's invalid to attempt to revoke tokens of any property that was created by another address.
It's invalid if the amount to revoke exceeds the number owned and available by the address that originally broadcast the property creation transaction.

@marv-engine

This comment has been minimized.

Copy link

marv-engine commented Aug 21, 2014

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

This comment has been minimized.

Copy link
Contributor

wanderingbort commented Aug 22, 2014

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

Updates based on PR feedback
clarified restrictions on grants/revokes
removed wallet references
made memo optional
added TBD for feature release block
@CraigSellars

This comment has been minimized.

Copy link
Member

CraigSellars commented Aug 29, 2014

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

CraigSellars added a commit that referenced this pull request Aug 29, 2014

Merge pull request #243 from wanderingbort/manual_issuances
Manually issued Smart Property Tokens

@CraigSellars CraigSellars merged commit 1911305 into OmniLayer:master Aug 29, 2014

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