Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Manually issued Smart Property Tokens #243
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:
Most notably is the project that @CraigSellars is involved in which requires the ability to grant and revoke tokens at will.
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.
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:
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".
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"
... I stop here, but I'm getting really excited, because I've never looked at it this way.
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
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.
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... :).
A couple of related items -
@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.