Mixnet integration

[zdave-parity]

Integrate the mixnet crate to provide support for submitting transactions anonymously.

[tomaka]

I've seen that the PR is about sending transactions, which are simply gossiped out.
A random question: would the mixnet be also be able to support "sending back responses"?

The reason why I'm asking is that in the context of a light client, when the user wants to see for example their account balance, the light client requests a Merkle proof of the storage value of this balance from the networking. Because of this, it can probably be quite easy for the full node that receives this request to figure out who controls the light client.

Another example is: before gossiping a transaction, a light client requests a call proof of TransactionApi_validate_transaction (and sends the transaction as part of this request). The full node that receives the request can easily guess that this light client is going to submit said transaction.

Making these requests go through the mixnet would avoid this privacy problem.

[zdave-parity]

The mixnet supports responses via SURBs (see the spec for a short explanation, or the Sphinx paper for a longer one).

Even in the transaction case a response is sent, although currently it just confirms that the transaction was imported into the recipient's transaction pool. In the future we could send enough SURBs with a transaction to allow additional responses to be sent on block inclusion and finalisation.

Re using the mixnet for these light client queries, this sounds reasonable to me. Do note however that the mixnet is quite slow; with the current defaults a request+reply takes about 10 seconds on average. This could probably be improved (eg the number of hops could probably be reduced; the current default is quite conservative), but there's always going to be a significant delay that will need to be accounted for on the UX side of things.

[tomaka]

I see, thanks

Are the 10 seconds caused by the fact that nodes have to connect to each other (and thus could be improved) or is it because of random delays and covert traffic?

[zdave-parity]

Packets are artificially delayed at each hop by a random amount (sampled from an exponential distribution); this is what provides the mixing. The two main factors controlling the time a request+reply will take are:

• The number of hops. This can be chosen by the sender. More hops means more mixing and increases the likelihood that the request/reply will pass through at least one trustworthy node.
• The average delay at each hop. This is fixed across the whole mixnet. A smaller average delay effectively means each packet gets mixed with fewer other packets.

The 10 seconds just comes from the current fairly conservative defaults of 5 hops each way and 1 second average delay per hop. We might decide to change these parameters when the mixnet is actually deployed.

[zdave-parity]

Note that the seed for the random delay at each hop is determined from the shared secret for the hop, so the sender can calculate the total delay for a packet before sending it. It is possible for the sender to keep "rerolling" until it gets a low total delay. I don't know what the security implications of doing this are though, and rerolling is quite expensive as it involves a bunch of elliptic curve operations.

[tomaka]

Thanks for the details.

When it comes to preserving anonymity when accessing the chain, given the constraints I feel like it's easier to instead request additional useless/covert keys (for example if you want to read your account balance, you ask for your balance plus 9 other random account balances) and frequently rotate peer, rather than use the mixnet.

The only place where we can't do that is validating a transaction before submitting it (we're not going to ask the user to sign fake transactions).
However, the reason why we validate a transaction from the light client is to give feedback to the user in case their transaction is invalid (as otherwise they have no way to know whether the transaction will be included or not), and since the mixnet indicates whether the transaction is included then we're all good.