This is Stephan, one of Trestor's protocol architects.
Problems that Trestor's developers said they did not understand:
1. Trests only get sent from one app to another if they are validated by validators. The right to become a validator is by "buying" it from trestor but there is no return as profit! So why would someone become a validator? Either to earn from fees or to earn by selling trests. Thus it becomes a pyramid scheme where investors who will continue to recruit other investors for an incentive that is presented as an investment opportunity - the right to sell a particular product or to earn fees from them.
Not true. The idea is that Trestor Foundation provides deposits to institutions (e.g. universities), which are willing to voluntarily run a node. Pretty much like Tor nodes. As running a node does not require vast resources like mining, it can be easily run by any willing institution.
The more independent institutions from different jurisdictions are getting on board, the more decentralized control over the network will become.
2. If there is a dispute, there is no history and resolving it is purely a matter of Trestor's discretion.
3. Even if trestor starts saving the history, there is no proof of it's correctness since they do not use proof-of-work or anything. thus every new participant in the network needs to trust the pre-existing validators. Thus also vulnerable to mitm.
That claim does not make sense. It is up to the majority of validators, which after some time will not be controlled by Trestor.
4. If a majority decides that a transaction is valid, that transaction is validated, irrespective of any algorithm preventing trests to be created out of thin air; not even Trestor, because again, they have no proof-of-work.
What? That statement makes me think that you do not understand Bitcoin.
5. In case of a double spend the transaction gets stuck, since validators can't vote against themselves. To resolve this they have implemented time-bound validity of nodes. This doesn't solve it. Consider a scenario where first 50% validated A->B and second half validated A->C at the same time. The transaction gets stuck. Votes expire after time t and now the first half votes for A->C & the transaction gets stuck again & so on..
A (honest) node cannot vote for a transaction conflicting with a transaction it previously voted on, that is correct. But your analysis is based on assumptions about our protocol which are incorrect. A node can still get knowledge about the conflicting transaction. At that point, the node will blacklist the corresponding account until all those transactions are invalid (plus some buffer).