Skip to content

Commit

Permalink
Clarify FATIP-0 Language & Validation
Browse files Browse the repository at this point in the history
Remove redundant tx validation rule. Add implementation links
  • Loading branch information
Devon Katz committed Mar 6, 2019
1 parent b102de9 commit 06ed814
Showing 1 changed file with 17 additions and 16 deletions.
33 changes: 17 additions & 16 deletions fatips/0.md
Expand Up @@ -269,20 +269,16 @@ The x.3.x requirements are generally related to cryptographic validations.
### T.x Requirements for all transactions

- T.1.1: The content of the entry must be a single well-formed JSON.
- T.1.2: The JSON must contain all required fields listed in the above table of
the correct type. No unspecified fields may be present. No duplicate field
names.
- T.1.2: The JSON must contain all required fields listed in the above table, all fields and their members must be of the correct type. No unspecified fields may be present. No duplicate field names are allowed.
- T.1.3: A Factoid Address may only appear ONCE in the `inputs` and `outputs`
objects combined. This means that the "inputs" and "outputs" may not share
any common keys (Factoid Addresses), nor each have any duplicates.
objects combined. This means that the `inputs` and `outputs` may not share
any common keys (Factoid Addresses), nor have any duplicate keys.
- T.2.1: The sum of all amounts in the `inputs` object must be equal to the sum
of all amounts in the `outputs` object.
- T.2.2: The set of input addresses must not intersect with the set of output
addresses.
- T.2.3: The entry hash of the transaction entry must be unique among all
- T.2.2: The entry hash of the transaction entry must be unique among all
previously valid transactions belonging to this token.
- T.3.1: The External IDs must follow the cryptographic and structural
requirements defined by [FATIP-103.md](103.md).
requirements defined by [FATIP-103](103.md).

### N.x Requirements for normal account-to-account transactions

Expand All @@ -293,8 +289,8 @@ Normal transactions must meet all T.x and N.x requirements.
to their respective amounts declared in the transaction.
- N.3.1: For each input address, there exists a corresponding valid
RCD/Signature pair in the External IDs as specified by
[FATIP-103.md](103.md). No additional RCD/Signature pairs beyond those that
correspond with an input may be included.
[FATIP-103](103.md). No additional RCD/Signature pairs beyond those that
correspond with an input may be included.

### C.x Requirements for Coinbase distribution transactions

Expand All @@ -311,8 +307,7 @@ Issuance entry (if not unlimited).

Implementations must maintain the state of the balances of all addresses in
order to evaluate the validity of a transaction. The current state can be built
by iterating through all entries in the token chain and updating the state for
any valid transaction.
by iterating through all entries in the token chain in chronological order and updating the state for any valid transaction.

The following pseudo code describes how to compute the current state of all
balances. A transaction must be applied entirely or not at all. Entries that
Expand All @@ -330,17 +325,23 @@ for entry in token_chain.entries:
balances[output.address] += output.amount
```


# Implementation

- [FAT Daemon & CLI](https://github.com/Factom-Asset-Tokens/fatd) (fatd) - Official FAT token daemon, API server, and CLI implementation
- A program written in Go that tracks and validates FAT Token chains, and provides up an API for other applications to access FAT's data.
- [fat-js](https://github.com/Factom-Asset-Tokens/wallet) - Official FAT Javascript library for NodeJS & Browser
- [FAT Wallet](https://github.com/Factom-Asset-Tokens/wallet) - Official FAT Wallet UI



## Duplicate JSON field names

Most JSON libraries do not consider duplicate field names to be an error. Thus
they can go undetected if not mitigated through other detection mechanisms. One
simple way to detect duplicate field names is to compare the length of the
minified JSON with the expected length of the JSON after parsing all of the
fields. The expected length is easy to determine once all of the fields are
parsed. See the `fatd` reference implementation of `fat0.Transaction` or
parsed. See the `fatd` [reference implementation](https://github.com/Factom-Asset-Tokens/fatd) of `fat0.Transaction` or
`fat0.Initialization` for examples of this.

A less efficient way to detect this is to parse the JSON, then regenerate the
Expand All @@ -353,4 +354,4 @@ whitespace to their JSON.
# Copyright

Copyright and related rights waived via
[CC0](https://creativecommons.org/publicdomain/zero/1.0/).
[CC0](https://creativecommons.org/publicdomain/zero/1.0/).

0 comments on commit 06ed814

Please sign in to comment.