# Practical I-Voting on Stellar Blockchain
## 3 System Proposition
### Privacy
For instance, if we take 3 candidates \(c_{i}\in\{c_{1},c_{2},c_{3}\}\), we assign each of them prime number \(P=\{3,5,7\}\), also, we have the pool of encrypted votes \(\{E(m_{1}),E(m_{2}),E(m_{3})\}\) where \(m_{i}\in P\), we compute the product  
\[E(N)=E(m_{1})*E(m_{2})*E(m_{3}) \tag{4}\]  
\[E(N)=E(m_{1}*m_{2}*m_{3}) \tag{5}\]  
after decryption we get the product \(N\), we write the equation in following form  
\[N=3^{k_{1}}*5^{k_{2}}*7^{k_{3}} \tag{6}\]  
then \(k_{i}\) is the number of votes for \(i\)-th candidate. To calculate \(k_{i}\) we need to perform prime factorization on \(N\). The problem with this approach is the computation complexity. Factorization is in the NP complexity class, so the computation of the results are very slow. The system that decided to use this method [13], claims that for 4 candidates and 10,000 votes, it takes 0.220 s to calculate results if the number of votes gets increased 100 times, computing time gets increased 7700 times (1692 s), which seems to be acceptable. However, we can notice the exponential increase of computing time in a number of votes. Additionally, we find one more problem, if the decryption key is published, then one could compute \(c_{i}=N-\frac{N}{m_{i}}\) for each \(m_{i}\) revealing the candidate for each \(m_{i}\). Moreover, if the assumption \"eventually the authorization server will get compromised\" holds, and the connection between identity and transaction leak. Then we can connect everyone with their vote. To prevent this, the encryption key can not be published. Therefore trustless result counting is not possible. Another approach to achieve privacy is blind signatures [1]. This technique makes it possible to sign encrypted (blinded) transaction and use the signature with the decrypted (unblinded) transaction. In other words, [PERSON] can prepare a vote transaction, encrypt it, send it to [PERSON], who then sign it and send it back to [PERSON]. As a result, [PERSON] gets a valid signature without revealing her actual vote. When [PERSON] publishes such a transaction, [PERSON] can not connect the previously signed transaction with [PERSON]. Here we present the [PERSON] blind signature [46] on the ed25519 scheme. Let us assume [PERSON] to be a voter, [PERSON] to be an issuer, \(P\) to be [PERSON] public key, \(H\) to be hash function, \(||\) to be concatenation operator, \(M\) to be the message we want to sign blindly. This process consists of the following steps:  
1. [PERSON] generate random nonce number \(k\) in the range \((1,q-1)\), compute \[r=G^{k}\pmod{p}\] (7) and sends \(r\) to [PERSON]. 2. [PERSON] picks two random numbers \(a\) and \(b\) in the range \((1,q-1)\), use them to compute challenge number \(e\) \[R^{\prime} =r*(G^{a})*(P^{b})\pmod{p}\] (8) \[e^{\prime} =  
[PERSON] gets valid signature on transaction \(M\), while [PERSON] knows only blinded hash of the transaction \(M\). This process can be visualized as:  
* [PERSON] prepares a message. * Place it into the envelope along with carbon paper. * [PERSON] signs the envelope. * [PERSON] takes a signed message from the envelope. This technique seems perfect until we realize the consequences of the words \"[PERSON] signs message \(M\) blindly\". If [PERSON] knows nothing about the message \(M\), [PERSON] can send him any arbitrary transaction, e.g., transfer all remaining vote tokens to her account, and he would sign it because--he is blind. To prevent it, we can use cut-and-choose method to mitigate the chance of cheating to a minimum. The Cut-and-Choose method works as follows: [PERSON] creates \(n\) (e.g., 100) random votes batch transactions. The batch consists of all possible vote options. For example, if there are six candidates, and \(n\) equals 100, then we need to create 100 batches of 6 transactions each (600 transactions). Each batch gets blinded with different blinding factor. [PERSON] sends them to [PERSON]. Who challenges [PERSON] for \(n-1\) unblinded batch of transaction.