tldr; it would be great to have a way to create user generated tokens with an optionally capped supply, where the user originally making the token is the only one who can create new tokens, unless the cap is reached or ownership is transferred.
If I understand correctly safecoin can only be created by the network and not users because it is a reserved type. If a user could create an entity with safecoin’s type, they could create new coins out of thin air.
Perhaps reserved types could be opened up for everyone. Basically to create a reserved type you would maybe send a message to the network that you want to create a new type, together with a small fee in safecoin to avoid spam and then you would get an id back that you would now own and only someone with your private key could create a new instance of some MutableData with that id.
This could be useful for example for creating altcoins, the request to the network to get a reserved id could optionally include a max number of entities with the specific id that could be created so that it would be possible to create altcoins with a fixed coin supply. You could then create tokens for all kinds of stuff. A company could issue tokens corresponding to it’s shares perhaps?
Maybe this doesn’t make sense or there’s other ways to do this though. I am still reading up on stuff.
Interesting idea and I can see many uses for it. The reserved tags were mainly for network specific types which may require different or special processing.
The issue I see here is that to make altcoins like SAFEcoin there would need to be the underlying processing to occur in the transferring of the altcoin like is done with SAFEcoin. Otherwise you are still left the problem of secure transfer of ownership of the altcoin.
I would like to see the routines that are used for SAFEcoin to be opened up a little to accept altcoin types and transact them the same secure way. Basically you would need your idea of user creatable reserved types (tags) and opening up the code to accept other tags than SAFEcoin for the secure transfer. Obviously there would be a fee for anything other than SAFEcoins. Maybe a few “PUT” costs to cover the updates to the MDs etc.
Yeah, I guess there could be various ways of doing this.
One thing I am wondering about is how datachains might fit into the whole token thing. Still don’t really know how datachains works, but if I understand it right it might not be useful to actually create a new capped token by itself, but would be useful for keeping a ledger, if one wanted to keep a blockchain-like record?
An example is you might set up a token which has a cap of 6 and say that this token represents a sword in some online game. Then there would really only be 6 of this sword, even when all the game data was stored online in a decentralized matter. Storing game data on SafeNet is a really interesting possibility, you could make a client and it could be implemented with different game engines like Unreal or Unity, but they’d have the same decentralized store of all the in-game items, players, state of everything in the game etc and you could even transfer items and characters between games in a secure manner. Combined with a ledger you could prove that, yeah this sword is one out of 6 created, not only that, it’s the sword that person X used in some famous raid or whatever, so it could have that unique provable history, kinda like a physical item.
What looks like might be a potential advantage of reserved tags for making altcoins/tokens compared to obfuscated transaction trees, is that with the transaction trees, the history has to be verified, requiring lots of computation, which will incur a cost both in time and electricity, it’s less than for a blockchain, but it’s not nothing either. You want the transactions to go as fast as possible, even having to wait 10 seconds could be annoying in some cases and you want the cost to be as small as possible, especially if you want to support microtransactions.
Tokens is one of the really big things on Ethereum now. In the future, the cost and speed of transactions is one of the factors that new dApps etc will look at when there will be multiple possible platforms to chose from when creating a new token.
There’s been a somewhat similar discussion before. Perhaps most of what could be achieved with reservable tags could be achieved with what’s suggested in this thread
I think what’s suggested there is basically taking XorName of a piece of MutableData and encrypting it with the private key of the issuer. Then the public key could be used to verify that the issuer was the one that created the MD. The name of a token would be something like mytokenprefix_token-number, so the names would go from mytokenprefix_0000 to mytokenprefix_10000 for example if there was to be 10 000 tokens, then these names would be encrypted with the issuers private key and added to the data and when the issuer goes public with the new token, all token MDs should already be created and they would just say that the valid tokens are tokens named mytokenprefix_0000 to mytokenprefix_10000.
Actually maybe encrypting it with the private key wouldn’t even be needed? If I understand correctly XorName is unique and is the hash of a name the user sets for a piece of MutableData. So if someone wants to issue a token then just creating MDs for all tokens mytokenprefix_0000 to mytokenprefix_10000 and saying that the only valid tokens are the ones with those names should be enough?
Well actually if you create the MD then you can set it to read only and noone can modify it. The owner ID is stored in MD anyhow so it can be verified. MDs will also allow you to set user (other) updateable fields in the MD which might allow you some interesting things.
If the intention is to pre-create the tokens then you have no need to reserve any tag types and simply create the tokens as read only.
Another simple thing you can do is have “index” MDs. This allows you to have a MD that lists the addresses of the tokens so then you don’t even have to have specific addresses for the tokens. Also you can create new tokens later on and store the address in the “index” MD(s). These index MD(s) are set to owner only update.