Introduction
Current crypto protocols appear to be a solution looking for a problem. Trestor Foundation has developed 'Trestor Network' aka T-Net solution by first identifying and understanding the systemic challenges of the real world financial problem and then working its way back to devise an elegant solution. At Trestor, we consider decentralization to be an excellent tool. It is means to the end goal, not the end goal itself.
Key technical differences: T-Net and Bitcoin
Signature Algorithm Curve Selection
Accounts not UTXOs
Distributed consensus via Node Voting not mining

Signature Algorithms
In Trestor, a user has pairs of private and public keys in order to manage his Trests. A user's balance is associated with a public key. The standard way for a user to spend his money is by creating a transaction signed with the corresponding private key.

Trestor differs from other distributed payment protocols by choosing the EdDSA signature algorithm over ECDSA with secp256k1, which is used in most other payment protocols.

EdDSA is a newer signature system proposed by a team of renowned experts led by the cryptographer Daniel Bernstein. It uses a Twisted Edwards curve known as Ed25519.
The Curve Matters

The curve secp256k1 comes with some problems. As cryptographer Nicolas Curtois points out, the curve has some known weaknesses that make it easier to break than usual. Even though there is still no practical attack know, this is considered a bad sign by most cryptographers.
Ed25519, the curve in EdDSA, has been selected by the team with the above and other known weaknesses in mind. The parameters were generated in a way that can be reproduced by interested experts in order to show that there are no backdoors.

Accounts not UTXO
In Trestor Network, ‘the state’ stores a list of accounts where each account has a balance, and a transaction is valid if the sending account has enough balance to pay for it, in which case the sending account is debited and the receiving account is credited with the value.
Distributed Consensus - Overview
Trestor imposes following Constraints in addition to bitcoin

Lightweight (weak constraint): A consensus algorithm’s hardware and bandwidth requirement should be minimal so that even old unused smartphones may be recycled to act as a Trestor node

Trestor Consensus
The Trestor network is a distributed network consisting of many independent validators operated by different parties. These validators have to agree on sets of new transactions to be added to the ledger. In order to achieve this, T-Net implements a voting process. Any validator can propose a set of transactions, and other (honest and correct) validators vote for it, if the following requirements are met, in addition to bitcoin:

The validator has not voted for a contradicting transaction before

Deposit accounts
To restrict the number of validators, T-Net will require each validator to have a deposit account. A deposit account is technically the same as a regular user account, but tagged as such. T-Net will require a certain number of Trests to be deposited on that account in order to consider the validator legitimate.
In order to make it easier for the network to deal with new validators appearing on the horizon, the deposit account will have another difference to regular accounts: T-Net requires the funds on the account to stay there for a certain amount of time (about one hour to one day) before it can legitimate a validator. On the other hand, if the operator wants the funds to go back to a regular account, that transaction will take the same amount of time. Note that this is not a real limitation for the operator, since he does not pay any fees or loses any money, it only takes more time.

The private key of an account is an EdDSA private key, which can be used to sign any kind of messages. This way, the validator is able to sign messages, for example the ones belonging to the voting process.

This solution comes with two other benefits:
The private key of an account is an EdDSA private key, which can be used to sign any kind of messages. The validator can use it to sign messages, for example the ones belonging to the voting process.
With those deposit accounts, we have implicitly given a complete list of all (potential) validator nodes that are known to the network. We have no need to trust some single source for providing such a list. (We can still have list providers to make things easier, but each node is able to independently verify it based on the ledger.)

The result is that an attacker needs to control a lot of Trests in order to gain a majority. Since our process does not require expensive mining operation, we do not need to reward validators to incentivize them in the first place. In mining-based schemes, mining is rewarded, which makes the big investment for the attacker to gain a majority pay itself (at least partly), reducing the actual cost for such an attack far below the level of the hardware expense itself.



The Voting Scheme

After a validator node collected some transactions and compiled a set of non-conflicting transactions that are valid under the current ledger state, it can initiate a voting.

The voting will consist of multiple rounds. This is necessary to avoid different groups of validators agreeing on incompatible sets of transactions.

Basic Idea

One validator compiles a set of transactions to add to the ledger, tags it with a time stamp and proposes a voting round on this message t.
Every node votes “yes”, if it has not voted for a conflicting set t’ that has not been aborted. Otherwise it votes “no”.
If more than 80 percent of a node’s peers have voted for the set t, the node will broadcast a vote for the message confirm(t).
If more than 80 percent of peers voted confirm(t), the node also votes confirm(t).
After confirming t, nodes add the set to the ledger.

Note that the message confirm(t) is different from the message t. Voting for the first one does not contradict a vote against the second one.

But unfortunately, this voting scheme does only half of the job: If only one set of transactions appears in one time, it will just find it’s way through the network and get confirmed. If two conflicting sets appear, there are two possibilities:

One set will gain the necessary 80 percent first. In that case, nodes will confirm this one.
Neither set will gain 80 percent. In that case the voting will get stuck.

Because of that, all ballots come with a time stamp. Validators will reject any ballot with a timestamp in the future, and all ballots with a timestamp less than a certain time ago will expire. After a ballot expired, (honest) validators are free to vote on the same transactions differently.

Note that this case should not occur in normal operation, because the user app will not send contradicting transactions. However, this process is necessary to prevent attacks and avoid problems with transactions created by buggy user clients.

Randomized Peer Selection

As the number of validators will grow over time, messages from each validator to every single other one would cause a huge scalability problem. At this point we can make use of the fact that we have an implicit list of all active validator nodes.

When a new validator node gets set up, it will select a fixed number of peers (e.g. 100) from the known set and use their votes as a basis. At the same time, there will be about 100 nodes selecting this new validator as their basis.

The selection will take place at random. Nobody should be able to influence which set of peers is trusted by a validator. Because of that, validators should only trust validators that they selected themselves. Validators should provide incoming connections with their votes, but not count votes from incoming connections.