# Practical I-Voting on Stellar Blockchain
## 3 System Proposition
### Privacy  
Blockchain by design is a fully transparent and traceable system. There are some exceptions like Monero [41] and Zerocash [42]. Each transfer can be easily traced down to its origin. Here comes the problem, how to distribute the token to the user, guaranteeing that no one can track it back to its identity. The easiest solution is to trust the organizers that they will not record the act of authorizing the vote with our identity. This is the weakest form of guarantee because even if organizers are honest entities, we can not be sure that unauthorized intruder does not get access to the system. We need to be prepared for the worst scenario, where all information is recorded and accessible to everyone. Such an assumption forces us to design a protocol where users \"play costume party\" to mislead the organizers about their identity. One technique allowing such action is called CoinJoin transaction [43]. In CoinJoin, multiple users conspire together in token laundering. \(n\) users create one transaction, which consists of \(n\) inputs and produce output to \(n\) new addresses; each new address is in possession of the user who participated in the procedure. That way, the chance that the output of the CoinJoin transaction is the user's input equals \(\frac{1}{n}\). If we proceed with this operation \(m\) times, we get \(\frac{1}{n^{m}}\) chance that the output is actually the input token of the particular user. Another technique called all-or-nothing-disclosure-of-secrets (ANDOS) [1, 44, 45] allows each voter to privately pick one authorization code, which can then be attached to the transaction, making it valid. ANDOS guarantees that neither the distributor can gain any knowledge of the code picked by a user, nor the user gets any knowledge of other available codes. There are two problems. We cannot be sure that the distributor does not offer us some subset of codes, such that nobody, except us, could pick one of them. That way, he can connect us with the picked code. We could mitigate the problem by forming groups of peers who participate together in picking the codes together. This algorithm can be visualized as follows: the organizer holds a bag of secret codes printed on paper cards; all participants put hands into the bag; simultaneously, all of them pick one card and pull off the cards. Nobody, except the picker, knows the picked code. Here is another problem; two people picking the same card cause conflict. It can be mitigated by generating a large number of authorization codes, much larger than the number of participants, but still, there is a small chance that some of them will pick the same code. To solve it, we can make the peers communicate together. The cooperative algorithm is relatively complex but well-described in [1] (Chapter 23.9). Coordination of both CoinJoin and ANDOS techniques can be troublesome on low-scale votings. If we assume that users should form groups of 10 people when the total number of voters is 100, there might be a problem finding such people in a reasonable time. Furthermore, privacy in such peer groups must be protected. Although we have decided not to use those techniques in our system, we consider them valuable alternatives. Another technique of providing privacy is homomorphic encryption. It allows computation on ciphertext in such a way that after decryption, the results match the results as if they were computed on a plaintext. For example, the ElGamal cryptosystem allows us to perform multiplication on encrypted numbers, and after decryption, the results are still valid. Let us call \(E\) encryption function and \(m_{i}\) the \(i\)-th message, then homomorphic property guarantee \(E(m_{1})*E(m_{2})=E(m_{1}*m_{2})\).