FATIP-1 Non-Fungible Token Standard #22
Conversation
fatips/1.md
Outdated
|
|
||
| Token issuance entries are ongoing like transaction entries to allow ongoing issuance of tokens by the issuer. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Absolutely. More confused? What was confusing before this so that I/we can fix it? 😉
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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).
fatips/1.md
Outdated
| | 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 | |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
| | salt | string | Random string to salt the issuance | user defined. Optional | N | | |
| | metadata | any | Any user supplied meta data | No validation |N |
There was a problem hiding this comment.
@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.
Use more concise inheritance structure, match data structures & validation to current implementation
|
Can we look into merging this PR? Because what's in the repo is very outdated at this point and potentially misleading for anyone investigating the standards |
There was a problem hiding this comment.
I am not a big fan of the general inheritance of the FAT-0 standard. As a reader, it is quite incovenient to have to open the FAT-0 token and have to re-conciliate all the rules by myself (not as easy for me as for a machine to handle overridden rules ;)). High risk of confusion and error prone. There is also the risk that FAT-0 is updated one day, and without realizing it we indirectly break FAT-1. Inheritance works well with small, well contained standards, but here it is overwhelming in my opinion.
fatips/1.md
Outdated
|
|
||
|
|
||
| # Motivation | ||
|
|
||
| Extend upon the FAT-0 standard by offering non-fungible token functionality for | ||
| unique, indivisible, and traceable assets. | ||
| Offer an efficient non-fungible token system, allowing attachment of arbitray metadata to issued tokens. Allow unique, indivisible, and traceable assets on top of FAT. |
There was a problem hiding this comment.
on top of FAT? Typo? FAT is a layer on top of Factom, but FAT-1 is not on top of FAT.
|
|
||
| Unlike FAT-0, the issuance chain can contain multiple entries. FAT-1 allows the | ||
| ongoing issuance of unique tokens over time up to a maximum supply. | ||
| FATIP-1 has the unique ability to specify sequential ranges of non-fungible token IDs during issuance and transaction. For example, the range `{"min": 0, "max":4410}` represents the range of token IDs `0` to `4410`, inclusive. |
There was a problem hiding this comment.
does fatd acceppt 0 @AdamSLevy ? I think I tried few days ago and I had to start at 1.
Rework legacy version of FATIP-1 with updated supporting standards and FATIP-0 mechanics. Initial commit contains basic token features comparable to FATIP-0