search

Factom-Asset-Tokens / FAT

Factom Asset Tokens - Open tokenization standards on Factom
17 stars 8 forks source link

FATIP-2 Update to Pegged Asset Token Standard #28

Closed PaulSnow closed 5 years ago

PaulSnow commented 5 years ago

Added a .gitignore for artifacts that development tools often generate Fixed errors of hex to ascii in chain names Updated the winners to be required 10 (exception is the genesis OPR) and to short hashes in hex (for easier review by miners) Reward is a PNT address (with the caveat that we can make it a tagged address)

Removed signing and identity dependency -- we don't need this because of the previous winners lock entries into a block (so they cannot be replayed) and Proof of Work and grading establishes who should be paid.

Added grading algorithm from the whitepaper.

PaulSnow commented 5 years ago

Sorry for the prior deleted branches. Just kept losing myself with the long branch names and screwing up.

PaulSnow commented 5 years ago

Values must be 10 valid entry hashes that correspond to the previous OPR winning entries in order. The genesis OPR has no previous winning entries

drkatz commented 5 years ago

@PaulSnow Values must be valid entry hashes that correspond to OPR entries. Can be 0 elements in length This is a direct quote form the spec and why I'm asking this question :wink: How does this rule handle the case I mentioned above?

WhoSoup commented 5 years ago

In the very first OPR entries post-genesis OPR (1-10) it wont be possible to list 10 winning OPRS, since they themselves require 10 valid previous OPRS, creating a condition where it's impossible to fulfill this requirement

Hm, I just double-checked the code and it seems at the moment if the previous block has no winners (which happens if there are fewer than 10 entries), it will just have an empty list of previous winners, so at the moment it's going to either have 10 winners or 0.

I'm going to make a separate issue on this as it's a potential attack vector.

drkatz commented 5 years ago

Thanks @WhoSoup, will continue the thread there. Good convo so far :+1:

PaulSnow commented 5 years ago

In the very first OPR entries post-genesis OPR (1-10) it wont be possible to list 10 winning OPRS, since they themselves require 10 valid previous OPRS, creating a condition where it's impossible to fulfill this requirement

Hm, I just double-checked the code and it seems at the moment if the previous block has no winners (which happens if there are fewer than 10 entries), it will just have an empty list of previous winners, so at the moment it's going to either have 10 winners or 0.

I'm going to make a separate issue on this as it's a potential attack vector.

I believe the current code lists the last 10 winners, even if that skips some directory blocks. There is some discussion on the PegNet repository issues, but I think that is what we want to spec here.

drkatz commented 5 years ago

@PaulSnow I'll merge this if that's alright, changes all look good. Conversation about the above case has continued in an official issue https://github.com/pegnet/pegnet/issues/107