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

FATIP-1 Non-Fungible Token Standard #22

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@drkatz
Copy link
Contributor

drkatz commented Nov 17, 2018

Rework legacy version of FATIP-1 with updated supporting standards and FATIP-0 mechanics. Initial commit contains basic token features comparable to FATIP-0

@drkatz drkatz requested review from AdamSLevy and PaulBernier Nov 17, 2018

@drkatz drkatz added the FATIP-1 label Nov 17, 2018


Token issuance entries are ongoing like transaction entries to allow ongoing issuance of tokens by the issuer.

This comment has been minimized.

@PaulBernier

PaulBernier Nov 18, 2018

Contributor

This sentence made me more confused. Could you rephrase it differently for me to help me understand the information you are trying to convey here?

This comment has been minimized.

@drkatz

drkatz Nov 19, 2018

Contributor

Absolutely. More confused? What was confusing before this so that I/we can fix it? 😉

This comment has been minimized.

@PaulBernier

PaulBernier Nov 20, 2018

Contributor

I just mean I'd be fine if this sentence didn't existe, but after reading it I was really like, what does he mean exactly, am I missing an important point, why does it compare it to transaction? Were you trying to draw a parallel with coinbase transactions of FAT-1?
In the end you are just saying that there can be new issuance of new tokens?

This comment has been minimized.

@drkatz

drkatz Nov 20, 2018

Contributor

Saying that there can be new issuance of new tokens. If the issuer submits the initial issuance entry and issues tokens A, B, C, they can then a week later submit another issuance entry to issue tokens D & E. The parallel drawn with transactions is that since issuance entries can occur multiple times, they require similar security considerations to transactions (which are not currently reflected in the spec).

This comment has been minimized.

@PaulBernier

PaulBernier Nov 20, 2018

Contributor

Ok I see. I don't know maybe it is just me but I just found the meaning of this sentence hard to grasp. I'd have gone with something more straightforward first like "It is possible to issue new tokens at any time by creating a new issuance entry" and then if you want to mention the security considerations that stem from that fact I would do it explicitly (rather than implicitly by drawing a parallel with transactions).

| tokens | array | An array of token objects, representing tokens being issued | Must be an array of objects | N |
| tokens[n].id | string | The unique ID of the token being issued | Length > 0 | Y |
| tokens[n].metadata | object | Object holding user defined key-value pairs | | N |
| salt | string | Random string to salt the issuance | user defined. Optional | N |

This comment has been minimized.

@PaulBernier

PaulBernier Nov 18, 2018

Contributor

I'm not sure the salt is ever needed here either. Those entries are "naturally salted" by the token IDs. Nobody could recreate the same issuance (either voluntarily or maliciously) because it would be discarded by the fact that those token ids have already been issued. In which case that salt would be useful?

This comment has been minimized.

@AdamSLevy

AdamSLevy Nov 19, 2018

Contributor

Agreed. I don't have a salt in my issuance entry for fat0 in my implementation for this reason.

Here are the types I have included for fat0.
https://github.com/Factom-Asset-Tokens/fatd/blob/develop/fat0/issuance.go#L36

Also note that it embeds the Entry type which also features a "metadata" field for all fat0 entries. It's a json.rawMessage type so that golang doesn't bother unmarshaling it at all but still retains the json bytes.
https://github.com/Factom-Asset-Tokens/fatd/blob/develop/fat0/entry.go#L12

This comment has been minimized.

@AdamSLevy

AdamSLevy Nov 19, 2018

Contributor
Suggested change Beta
| salt | string | Random string to salt the issuance | user defined. Optional | N |
| metadata | any | Any user supplied meta data | No validation |N

This comment has been minimized.

@drkatz

drkatz Nov 19, 2018

Contributor

@PaulBernier this is a good point. However, it is not currently required that tokens be present in the first issuance entry.

@AdamSLevy In FAT-0 I believe we can get away with that because there is a single authoritative issuance entry that establishes the token(we don't have to worry about replay vulnerabilities on the same chain). In FAT-1 issuance entries are ongoing, as I so in-eloquently stated in the spec 😛

Token issuance entries are ongoing like transaction entries to allow ongoing issuance of tokens by the issuer.

There is a risk of replay, albeit the replay would currently be ignored/invalid since it would be attempting to re-issue already issued tokens. However, If we add additional functionality to the issuance entries (for example FATIP-201 for address workflows) this could be an attack vector people could use to re-enable their addresses, and all other types of same chain griefery. In terms of security & protection, we should approach these FATIP-1 issuance entries more like transactions. It may be necessary to use blockheight and institute validation like in transactions.

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