Privacy implementation scheme proposal

[Fiono11]

The purpose of this scheme isn’t to solve Nano’s privacy problem (it’s not an implementation and I don’t even know if it is possible one), but to provide a basis for a theoretical discussion of how privacy could be implemented in Nano, transaction wise and consensus wise. It is based mainly on range proofs and homomorphic encryption.

Example of a transaction

• Account A has initial balance a
• Account B has initial balance b
• Account A sends transaction amount x to B
• Account A’s final balance is y
• Account B’s final balance is z
• Account A’s balances and transaction amount are encrypted with its representative 1 public key, that has homomorphic properties
• Account B’s balances and transaction amount are encrypted with its representative 2 public key, that has homomorphic properties

Like this, we get:

• E1(a) – E1(x) = E1(y)
• E2(b) – E2(x) = E2(z)

To send the transaction, account A has to do the following:

• Commit to the values x and y, which can be done using Pedersen commitments: Com(x) = x B + x’ B’
  Com(y) = y B + y’ B’

• Prove that y >= 0, using a range proof protocol (e.g. Bulletproofs) and using the previously committed value.

• Prove that E1(y) encrypts the same committed value used in the range proof: E1(Com(y)) = v1 <=> E1(y B + y’ B’) = v1 <=> E1(y) E1(B) + E1(y’) E1(B’) = v1 <=> E1(y) = (v1 – E1(y’) * E1(B’)) / E1(B)

• Check that the result of E1(a) – E1(x) equals the result of the previous equation: E1(a) – E1(x) = (v1 – E1(y’) * E1(B’)) / E1(B)

To receive the transaction, account B has to do the following:

• Prove that E2(x) encrypts the same committed value by account A: E2(Com(x)) = v2 <=> E2(x B + x’ B’) = v2 <=> E2(x) E2(B) + E2(x’) E2(B’) = v2 <=> E2(x) = (v2 – E2(x’) * E2(B’)) / E2(B)

• Calculate E2(z):
  E2(z) = E2(b) + (v2 – E2(x’) * E2(B’)) / E2(B)

Consensus level

Nano’s consensus mechanism relies on knowing the voting weights of the representatives to function. With this scheme, and since every balance account would be encrypted using the respective representative public key, representatives could calculate their voting weight using homomorphic encryption, decrypt it using their private key, and announcing it to the network. This can’t be done every time a transaction occurs, since you can associate the change in voting weight to the transaction, but you can do it every x number of blocks. Because Nano is asynchronous, you need a way to coordinate the voting weight updates, which can be done in the following way: once a node reaches a certain defined block height, he announces his new voting weight to the network. When the other nodes receive the message, they announce their new voting weights as well, until the network reaches a consensus for the new voting weights.

Problems of this scheme

• Representatives would know the balances and the transaction amounts of the accounts that delegated to them (can this be an incentive to run a node?)
• It doesn’t work for nodes with only one account delegated to them
• Division of encrypted values is still a hard problem to deal in cryptography, with the major libraries of homomorphic encryption not supporting it.
• It can be hard for the network to reach a consensus regarding the new voting weights, because transactions don’t stop and nodes have different frontiers at a given time.

[Fiono11]

Another problem: origin and destination of a transaction can still be tracked.

[kayabaNerve]

This was thoroughly discussed on GitHub.

1) @PlasmaPower mentioned that when you switch reps, old reps don't have incentive to update their weight tallies. 2) I mentioned that if you send to someone with a different rep, the same thing happens. 3) Depending on how often reps update their weight, timing attacks can be applied to figure out who sent what where and for how much. 4) By forcing reps to say where their new weight came from, new reps could force the hand of old reps. This may reduce privacy and makes timing attacks even more viable. 4) If reps only update every week, timing attacks can be thoroughly mitigated with increased TPS and increased centralization. That said, that would be a major issue if a rep became malicious. I wouldn't trust a network which didn't update at least every 12 hours. 5) I'm personally unclear on how you can prove your weight, as a rep, without announcing all the balances of people who trust you as their rep. 6) @PlasmaPower pointed out you can't divide commitments and using two separate schemes (homomorphic encryption and commitments) for the same values is "bound for trouble".