Parameters for a specific type_tag of structured data

Development
1

I’m probably in way over my head here, but having dug in for Class research, I’m starting to think from an App Dev’s perspective (a little :sweat:) i.e., what can be done with structured data. But without the ability to dig in to the code or other deep materials to figure it out, maybe others can help me over the hurdle.

The scene is this.

Say I want to create a token which represents voting shares in some enterprise. I want that token to have specific attributes that are different from any other sort of structured data out there, and have application only to my enterprise. I want it to apply specifically to my enterprise. I want to have the number of tokens limited to one million. I want to create and take possession of all of these tokens, and then disburse them per existing ownership of stock, or whatever.

From what I understand of the structured data model, I think I can see basically how to do almost all of these things–at least theoretically, since I’m not a coder.

What I do not know is if there is a way to define the type_tag so that those one million tokens are all that can be viewed as valid under that type_tag.

In other words, how does a user-defined type_tag limit the quantity of the asset? I’m sure it must be doable. I just don’t know how easily or how expensive. Or if I’m going down the wrong road to that goal.

This has all sorts of implications, from user-defined cryptocurrencies, to stocks, token-controlled access, etc.

I guess the other aspect to be asked is, can the type_tag itself be owned in any way, so that the quantity could be changed? That would make another set of options open up, not all good.

9 Likes
2

@fergish at first glance here is a good answer on how to make a quantity:
The same way bitcoin has a quantity:

3

I don’t see it. I’ve looked over the reference. All I get is vague notions that make my head creak.

Can you spell it out?

1 Like
4

The coins themselves are not discrete things which need storage - when coins are mined the miner’s balance is credited via a “generate” transaction which adds to his or her available balance. When coins are sent from A to B, that transaction subtracts from A’s balance and adds to B’s balance.

When you make an initial balance in a structured data, you can then transfer the ‘balance’ to someone else’s control and then validate that the amount sent does not exceed the past balance that was owned.

1 Like
5

Create a million, sign them, put the signature in the data field. Make your app (protocol) only recognize them if they have a valid signature. Or even easier, only recognize those with an ID from 0 to 1 million (or any other range).

4 Likes
6

Yeah, but in the case of safecoin the coins are discrete things. They exist as data states on the network, but they are discrete, individually identified, individually owned things, as opposed to a balance of inputs and outputs as in the case of bitcoins. I was assuming a similar state of the tokens/coins in question.

You seem to be speaking of a ledger system. I’m not following.

7

This makes sense to me.

The only thing that pops to mind as a potential hack is someone designing an app that looks like your control app, but has different parameters and would accept other tokens of the same type_tag as valid. But I’m just stretching on that wherein I do not know.

8

I’m with you @fergish. I don’t understand how you can do it either! Waiting for a TL;DR / ELI5 from our resident geniuses! :smile:

2 Likes
9

It sounds like you’re trying to create an alternative currency that functions just like Safecoin on the SAFE Network. From my understanding, this might not possible. Here’s why…

SAFE Network Enforcement

  1. The SAFE Network is bootstrapped with “pre-knowledge” of Safecoin.
  1. AFAIK the SAFE Network only enforces type_tag Safecoin to prevent counterfeiting.
  • So if a user claims, they own 1 Billion “unowned” SC, the Network checks that claim against it’s own “pre-knowledge” and rejects the claim.

APP Enforcement
You can create structured data (your own alternative currency) but the SAFE Network is not “trained” to enforce it, which why your APP has to prevent counterfeiting. This means the APP must keep a record of what is “owned” and therefore not discrete… it’s basically a public shared ledger. As you mentioned, there are problems with APP enforcement, but it’s doable.

Off-Topic

I’m brainstorming an idea for alternative currency creation, using a conversion feature.

This is not meant for the SAFE Network because it has a coin cap.

This idea is best suited for a Network without a coin cap. The idea is to create 3 levels for the Network’s currency system.

  1. network_type_tag = “Network’s Name”
  2. token_type_tag = “Safecoin”
  3. owner_type_tag = “Owner’s Name”

Point #1
This top level tag identifies the Network’s currency. In this example it would be called “SAFE”. This currency can only be created through farming. See my post on bootstrapping solution showing how currency comes into existence. This solves the counterfeit problem by using Network generation as enforcement.

Point #2
All farmed tokens will be labeled as “Safecoin” as a secondary identifier. Once a Safecoin token as been created. The label “Safecoin” can be renamed through conversion. So if someone wants to create 1 million STAR coins, they must have 1 million Safecoin tokens. Then they can convert Safecoin ~> STAR which renames the token_type_tag. This condition creates a beautiful synergy between farming and alt coin creation.

Point #3
We use a 3rd identifier which holds the previous and current owner. This works just like our current design plan, so nothing has changed. Ownership is kept discrete, and the Network is able to enforce all transactions without APP enforcement.

I haven’t thought of everything yet. There is one issue about other people increasing your alt token supply by converting their own Safecoin to STAR coins. I’m still working on a solution to solve “unique conversion”. This means only 1 person can create a quantity of unique alt tokens. My first guess would be to add an author_type_tag which prevents others from copying your tokens.

brainstorm continuation…

Point # 4 - Unique Conversion
We would need to make token_type_tag a “first come first serve” basis. This means there must be a Network Record to reference during conversion. So if @fergish was the first to convert Safecoin to STAR, then @dyamanaka conversion will fail, saying “that name is already taken!”

It will be easier for everyone to have only 1 author per converted token name. I just realized that prevents others from copying your tokens, haha!

At the same time, the original author can add more converted tokens to their supply, if they wish. Or they can set an address range (serial numbers) for each coin to “limit” supply, preventing additional creation. See @happybeing post below.

It would also be nice to see a public network list of converted token names, so you can see what is already taken.

1 Like
10

David, you always bring an interesting and unexpected dimension to a problem.

I’ll have to work your idea over. Not sure I get it yet.

I really do wonder if it would be possible to have an owned and transferable type_tag. That’s definitely something to ponder.

2 Likes
11

I’m sure I’m using the wrong code terms “type_tag”… probably should have used “string_name.”

I’m just trying to explain how it could work. It’s up to the coders to take the idea and code it into reality. All programs revolve around rules and conditions. So anything is possible.

The implications are very exciting because there is huge demand to create unique assets (alt coins, stocks, contracts, crowd sales, etc) and it would be really great for the Network to have a simple way of transferring/enforcing these SD assets private/public from individual to individual.

2 Likes
12

In that case, I want a chicken in every pot! :wink:

Yes, the implications are very, very exciting, and apparently quite reachable. I’m probing to see how far it can go, out of the box.

1 Like
13
  • Change the app to start recognizing 2 million.
  • Issue and sign 1 more million tokens
  • Profit!

Or:

  • Subtly change the app to recognize token in range you own twice by taking a random vote from tokens in ranges you don’t own.
  • As the issuer (founder), get elected to the board, always
  • Profit!

There must be some implicit trust in the issuer, but this approach doesn’t seem as reliable as with other cryptocurrencies such as Bitcoin.

1 Like
14

To clarify, no, because whatever else safecoin is tied to the network resources lever–a powerful.

Not looking to create competition, just a discrete number of tokens for a whole bunch of purposes, including cryptocurrency. If you’ve listened to much of Andreas A.'s talks you’ll be familiar with JoeyCoin and AmyCoin.:grinning: While a discrete SD can transfer ownership, having a limited number can be vital.

15

I remember that, it’s from this presentation.

16

When you sign the 1,000,000 SD you create, you sign them with your ID so that no one else can sign them and be seen as valid. If you sign them with the private key, then others can validate them with the public key. Thus other APPs can validate them without compromising security.

This prevents other APP from creating SDs that validate. Also you number your SDs 1 to 1,000,000 so that each one has a serial#. This also allows you to do a “2 for 1” offer or increase the number which you sign.

If it turns out that others can create SDs with that type and number 1,000,001 and up, then rather than use the number as part of the SD key you use the serial# hashed with your ID private key and have the serial# as part of the SD contents. Thus it becomes improbable that someone could create a SD within your expanded range. 1 in 2^256 chance.

1 Like
17

How can I know for sure that there’s no more than 1 mil tokens issued by the issuer who says he issued only $1 million?

1 Like
18

So you’re talking about at type_tag that dictates that a valid type be signed by and retain the cryptographic sig as proof of authenticity, while ownership and ownership transfer are separate fields?

19

Its how you want to.

Notes:

  1. encrypting with your ID’s private key means no one else can duplicate it
  2. when I say “no one” it is technically possible if someone can break the encryption
  • You could take the serial# and encrypt it with your private key.
  • Create your chosen TAG_ID (how ever that will be done.
  • Create SD using the TAG_ID and encrypted serial#. This means that it is virtually impossible for someone to deliberately create new SDs that follow on (in serial#) from the SDs you create
  • Create your SDs (1 million in your example)
  • in your SD you will have some information that will not change. Encrypt this with your private key and write the hash in the SD contents as well. Then it is virtually impossible for anyone to modify that permanent information.
  • the permanent information would include, but not limited to, the serial#. This further protects the validity of the record because the encrypted serial# is part of the SD address.
  • the rest of the contents which will be modified as part of the operations can be signed separately if desired

I am not sure, but I think the SD can be jointly owned. It would be owned by your ID and the person who owns the ?certificate?. That way the only person who can corrupt the certificate is the owner and it is to their loss to do so. They cannot falsify the certificate info (permanent info) because it is your ID that signed it. The rest of the fields can be protected if you wish

So if wish you could create more and be confident that they will be available. If you found that some extremely lucky sod had created a SD with the same address as one of these extra SDs you want to create then you could have a system that allows the certificate serial# to have a “check” digit that means that it is 36x “virtual impossible” to create a SD that you need.

Because it costs to create SDs you can also be reasonable confident that someone is not going to use your TAG_ID and try and block you creating more. Seeing as the address is 256 bits, I doubt anyone even think they could

1 Like
20

Fascinating. I’ll have to work through this to let it settle in.

Maybe it would be possible to create an SD type that allowed for a Creator Field, which could not be altered after it passed out of the possession of the creator? Thereafter the ownership could change, but not the Creator field, which would contain the serialization.

Now that would open some doors.