I been intending to reply to this, so now I will since Factom's price is rising:
Someone asked me in a private message if I have compared my planned (currently vaporware) design to
Factom.
There are some key distinctions between my design and Factom's:
- Since Factom uses the Bitcoin block chain, it doesn't defeat selfish mining
employing my math derivation. - Since Factom uses the Bitcoin block chain, it doesn't fix mining so that proof-of-work is unprofitable for ASICs and thus only the users mine.
- Factom conflates the requirement to use their tokens (factoids) in order to use their consensus network, thus network is not orthogonal to user's preferred asset class.
- Factom transactions don't become irreversible for 10 minutes, whereas my design is on the order of a second or seconds to become irreversible.
- Factom's consensus network is a fixed number of federated servers, and not an open, unbounded entropy permission-less network. I will not explain why at this time; this limitation in Factom is derives from the fact that Factom doesn't mine its own block chain.
- Whereas afaik Ethereum's unresolved technical problem has been it forces all the nodes to verify each script (or did they ever stop thrashing their research and settle on a delegation algorithm?), contract, or transaction, Factom consensus does not verify at all (relegates to clients to interpret but afaics clients can't inhibit further downstream graph entanglement), thus a tangled mayhem! I believe my design resolves this major, major issue.
- I do not see any mention of network partitioning tolerance for Factom.
There may be other differences and I will need to spend more time analyzing to be sure I have enumerated every difference.
P.S. still planning to evaluate eMunie.
Some feedback.
Factom only uses the blockchain to secure the record. One anchor is dropped into the bitcoin blockchain every 10 minutes. Even if some anchors do not make it into the blockchain in a timely fashion, they can call be written, and they can also be recorded in other chains and other histories. I don't think selfish mining has much of a way of attacking this.
That doesn't address my criticism which is that transactions are not confirmed for 10 minutes. No instant transactions. Thus no microtransactions (since these usually need to be instant).
Only the federated servers record and build the Factom history. They are elected only by those holding Entry Credits (i.e. using the protocol). So ASICs have little to do with Factom outside of Bitcoin as a publishing mechanism.
If the confirmation mechanism is attacked (and note that
Bitcoin is controlled by China), then so is Factom.
The 51 percent attack on Bitcoin might prevent anchors from being written by Factom. There are other ways to write anchors though, so not too much of a concern.
You can't write anything to the block chain if the attacker doesn't allow you to.
Factom itself must have a majority of Federated Servers following the rules. So a 51 percent attack remains possible.
Factom doesn't require Factoids to use the protocol, but Entry Credits. And while Entry Credits are created from Factoids, by breaking the direct connection of the token from the use of the protocol, the use of the protocol can be denominated in any token. So in fact, you could give someone dollars, or Bitcoin, or XCoin in exchange for Entry Credits and make use of the Factom protocol, and never touch a Factoid. The token only exists to reward servers to record data. Meta protocols can thus run on top of Factom, and if those protocols have value, they can be used without any particular user having to have factoids.
The point is that one must obtain some tokens or units other than their preferred one in order to run Factom or Ethereum. This limits network effects and use cases, because it adds exchange risk and latency risk.
Factoid transactions are irreversible as soon as a federated server has issued a receipt.
Impossible. You simply
don't understand anything about Nash equilibrium and the Prisoner's dilemma. This an entirely broken design. The only possible way it could work is for all Federated servers to have absolute trust in each other.
Each receipt is part of a chain of entries, so each receipt builds on the previous entries. Thus a transaction can be considered final in Factom in seconds.
No because nothing is confirmed by a consensus system. You simply do not understand the issues about Nash equilibrium, trust, and the Prisoner's dilemma.