Forwarding nodes help to balance the load. If you want to have a client that does not have a full ledger on its own, like a phone app, you need a service to consult for account information. This is equivalent to services like Blockchain.info in the Bitcoin world. We think that a full client is not the right solution for most users, so made this part of the protocol. This has the advantage that in the future, app users can freely configure which forwarding node to consult, because they are all using the same protocol.

tl;dr: In Bitcoin language, a forwarding node would be a full node (having full ledger copy) which is not mining (in our case voting).

Everybody can run validator and forwarding nodes, which have a full copy of the ledger.

Yes. But you need a lot of resources, because validator nodes require deposit. It is analogous to buying a lot of mining hardware and overtake Bitcoin mining.
                                 
Random here does not mean “connect to any node”, but select nodes in a mathematically random way from the full list of nodes. The full list of nodes is literally public, because deposit accounts are listed in the ledger.



If anything remains unclear, feel free to ask more specific questions. Note that the project is under active development and more detailed documentation will be released over time, of course.

Sorry, but I cannot let this statement unchallenged:

You are assuming that there is an “algorithm” in Bitcoin preventing the creation of new coins “out of thin air”. That assertion is full of misconceptions. The creation of coins is defined by the protocol. The protocol is, whatever the majority of miners defines it to be. The Bitcoin protocol is not unchangeable, quite the opposite: It changes a lot over time in order to improve Bitcoin. This also comes with bad side effects like the fork a few day ago:

Coindesk: Double Spending Risk Remains After July 4th Bitcoin Fork

The only thing that prevents miners from changing the number of newly created coins is their incentive to not devalue their reward. This can easily change in the future as default reward is going down and income from fees may not rise to the same level.

The situation is the same with Trestor validators. They will reject any transaction that is not covered by existing accounts, rendering creation of coins impossible. It is in the hand of the majority how all these aspects of the protocol are defined, and maybe changed in the future.

And all of this by the way has nothing to do with proof-of-work.

This is Stephan, one of Trestor's protocol architects.

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.

That claim does not make sense. It is up to the majority of validators, which after some time will not be controlled by Trestor.


What? That statement makes me think that you do not understand Bitcoin.

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).

This is Stephan, protocol designer at Trestor.



In our protocol, a large majority of Validator nodes is required to agree in order to change the ledger. A law enforcement agency or any other powerful entity would be required to either force a lot of node operators from various jurisdictions to cooperate, or to set up a large number of their own nodes (which would require a large amount of deposits and will not stay undetected).

Trestor does not require fees, because running a Validator node does not require nearly as many resources as running a Bitcoin miner. The idea is, that these nodes are voluntarily run by enthusiasts and organizations (e.g. universities), like we all know it for Tor nodes. The incentives to run a node are of course very different from the incentives why people mine Bitcoins, but that does not change anything about the fact that they are run in a decentralized way by a variety of parties from different jurisdictions.

The hardest problem is to bootstrap the whole network. In the beginning, when the number of Validator nodes is small, the deposit required to run a node has to be set high in order to effectively secure the network. Our plan to get the network started is that the Trestor Foundation will provide organizations, which are willing to run a node, with the required deposit amount.

A reward-based proof-of-stake system is very hard to secure, because there is no way to prevent stake-owners to sign multiple conflicting ledgers with their stake. Some even say that reward-based proof-of-stake systems are completely impossible. We are not doing anything like that. In our system, fees would make no sense, because there is no competition among Validator nodes like we know it from miners. Who is supposed to get the fees, after a majority agreed on a new ledger update?

This is not a technical question, but I will try to answer from my tech-team perspective.

There is a fixed number of coins which in the beginning are controlled by the Foundation. This is similar to Ripple, but note the following differences:

- Trestor Foundation is a non-profit, there are no stock holders who personally own these coins.
- As the coins are more and more distributed, the Foundation's control will go down.
- Since our network is not federated, there are no “better” nodes who dictate the protocol rules. The rules are whatever the majority of nodes decides. Like in Bitcoin, they can be changed if the majority of rules decides to, including the rules about how many coins there are and how they are generated/distributed in the first place.

Comparison to Bitcoin:
- With Bitcoin, a large part of the coins is owned by early miners, nobody really knows who, while with Trestor you know that they are controled by the Foundation which is dedicated to support and promote the Trestor project.
- With Bitcoin, vast resources (hardware investments, electricity) are required in order to run a miner, while with Trestor a deposit of Trests in the ledger is required in order to run a validator node.

Trests can be traded at any market place, just like any other coin.

Trests are controlled by the user via a wallet with secret keys, just like Bitcoin. He is free to trade Tests with any other person on any platform of his choice.

I also do have this account here.




As you can read on our website, one of our primary goals is that all the software involved will be open source. At the moment, we are still in a very early stage of development. (Our project is not a (direct or indirect) fork of the Bitcoin software (unlike the dozens of altcoins, who did nothing but change the logo in bitcoin-qt and some parameters like block generation rate). That's why it takes some time.)

To get a first idea about how the Trestor network will work, you should take a look at our tech draft.

In a nutshell:
- Coin ownership and transactions are based on digital signatures, like in all crypto-curriencies.
- Unlike Bitcoin, there is no work-based mining, but voting among “validator” nodes.
- Unlike Ripple, voting is not based on federated trust relationships. Validator nodes are backed by deposit accounts in a proof-of-stake manner. This makes it decentralized: No validator is valued more than others.

Note that some of this is work in progress. We are sharing this information early with you in order to counter the scam accusations, which we are facing.

Feel free to ask any questions.

Best,
Stephan

I don't get why you insist on calling it “blinding”, since no message is hidden here. Using commitments to cooperatively generate a random bitstring is pretty common.

Do I get this right that the table only checks whether the signer's current behavior is consistent with the signer's past behavior? I don't get how the user could possibly know what “h” or “Q” is correct for a certain secret key (or its corresponding public key).

This protocol has another nice feature: The non-signer party in this protocol does not have to be the party who generates the message to be signed. This is a relevant difference to the blind-signature variant.

This means you have the following setup:


Signer and Verifier can prepare a number of choices for “u” and “t” like in gmaxwell's Hashtree proposal. After that, the App can request Transactions from the Wallet, and the independent verifier device can verify that they are leak-free. Note that “u” may contain secret messages, but only the verifying device (which can be offline) knows the “u” values.

It doesn't have too much to do with closeness. There is a linear relationship between any pair of two numbers in the “Z_n” (with n from Bitcoin's secp256k1 curve). The question is whether you know it. Easier “k” is much easier to break, because it results in identical “r” appearing in the blockchain. Anybody can detect them immediately. But for an evil programmer who manipulates the generation of “k”, there is much more potential to leak values, without having obvious appearances in the blockchain.

Does not help against the attack from here, because the manipulated random numbers are provably indistinguishable, but it would have prevented the ridiculous bug in MyWallet.

This is a very nice protocol to tackle the problem of leakage, but it is not perfect either. It is practically the same as mine with ZK proofs or gmaxwell's based on Schnorr, because leakage can still happen via “u”.

But it is better than mine because it is easily computable. It is better than gmaxwell's because it does not require a protocol change.

The whole attack scenario here is about malicious wallet implementations. If your wallet implementation is doing what it is supposed to do, everything is fine, even if it is not deterministic.

Note that there is no way to tell that from looking only at the resulting transactions, as the attacker hides the leak well. You have to make sure that you (or a person you trust) know the code, understand the code and actually know that the source code you have actually matches the code that is running on the offline wallet.

This is a theoretical/technical discussion about a potential attack and suitable counter-measures. There are no documented cases of this attack being done.

It was known right from the beginning, when ElGamal published his signature scheme, on which Schnorr signatures are based, on which classical DSA is based, on which ECDSA is based.


From his 1985 paper:

Yes. “k” can be deterministic, but it has to be unknown, otherwise you can extract the private key “d” from “(r, s)”. In RFC6979, the choice of “k” depends on the private key “d”, it (hopefully) cannot be reproduced without it.

tl;dr thread summary:

gmaxwell's proposal based on blind Schnorr signatures prevents that by replacing the “r” component of a signature with a different value “r'” which depends on two random choices, only one of which is made by the offline wallet itself. “r” is still generated in the process, but not published into the blockchain.
Problems:
-- The original “r” has to be kept secret.
-- Schorr signatures are not compatible with ECDSA, so this solution requires a change of the Bitcoin protocol.

In my proposal using ZK proofs, the offline wallet outputs a proof “p” together with the signature “(r, s)”, where “p” proves the following statement: (“Q” is the public key, “m” the message.)
Since the formula has only existentially quantified variables, it is an NP statement and we know that there exist ZK proofs for it. Since the wallet knows the witnesses “d” and “k”, it has all the knowledge necessary to generate such a proof “efficiently”.
Problems:
-- How to make sure that the wallet does now leak secrets through the proof, as most ZK proofs require lots of random choices by both parties (prover and verifier).
-- Alternatively the proof has to be kept secret like the original “r” in the blind Schnorr signature scheme.
-- How to make the proof efficient enough for practical applications, especially the part “k = H(m||d)” for a complicated cryptographic hash function “H”.

I second your recommendation as a current solution, together with the obvious recommendation to always prefer verifiable implementations.

But it does not make me stop thinking about new solutions, and the fact that the two of us are searching in different directions will only make us richer.

Depends on what kind of attack you are looking at. As I said, a full attack application on Bitcoin requires some additional steps. But even without that, it is an attack with the “offline property”.

The host does not really have to actively do anything. All information about the keys may eventually be on the host, and only the attacker can know that. It would have to be offline as well.

Interesting.

Yes, it is not suitable for an embedded wallet, but that is not the only offline wallet. For a disconnected PC this wouldn't be a problem.

Yes, but that is no different to your blind-signature solution. If your host successfully keeps the messages from the protocol secret, it would be fine. And both (my proof or your protocol messages) don't have to be stored after once used/verified.

I found some time to look into blinded Schnorr signatures now. It does not prevent my attack, but it indeed makes a practical application of my attack harder. The values “R = kG” and thus information about the private keys are still leaving the offline wallet. But it is not displayed in the transaction any more.

In addition, this solution is not compatible with classic ECDSA, it requires a change to the protocol. This is not required in my proposal of deterministic “k” plus proof.

I think the problem that ZK proofs are comparatively slow is a minor issue in comparison. If a user wants to make a transaction with an offline wallet, it requires time anyway (let alone the time for confirmations). Even if the proof requires minutes to generate and megabytes to store, it does not really matter. The proof is created for the user himself, and he only has to verify it once, he can forget it afterwards. It has NOT to be sent to any other Bitcoin peer and it has not to be stored in the blockchain or anywhere else. If a user transfers his transaction from an offline wallet via a removable medium or something, the size and time is not really that big of an issue. This solution makes sense for some use cases. Note that I don't claim that this is perfect for every Offline wallet setup and use case. Every user* has to decide himself what requirements of security, performance etc.


*) I mean power users who care about offline wallets, e.g. professional users like online merchants or exchanges.

The attacks presented by gmaxwell and me go even further. Even if you would ensure that the inputs and outputs are correct, you cannot detect the malicious behavior, because the outputs provably look like regular outputs, i.e. they are following a statistical distribution that cannot be distinguished by any efficient algorithm.



I don't get how this would prevent the leakage of private keys at all. My attack does not need to know what the message is, and it does not even need to know what the private key is. It just creates a choice of “k” in a way that enables the attacker to extract “k” from two signatures. If one knows how the wallet implementation works, it would be enough for this attack to just inject the right “random numbers” into the wallet's entropy source.