# Practical I-Voting on Stellar Blockchain
## 3 System Proposition
### Privacy
He uses them to validate their structure, especially if they do not try to issue more than one vote token or perform any illegal operation. The one unrevealed transaction can be used by [PERSON] to cast a vote anonymously. There is still one more problem. In Stellar, to guarantee consistency, each account has a sequence number counter. Only transactions with sequence number 1 greater than the current account sequence number are processed by validators. For example, if some account's sequence number is 100, then the network accepts transaction only if the sequence number is 101. Processing valid transaction increments the account's sequence number; therefore, the next transaction's sequence number must be 102, and so on. Stellar transactions are synchronous; even if we use the concept of channels [47], channels are still synchronous. That means, if [PERSON] and [PERSON] proceed with blind signature on Stellar transaction, where [PERSON]'s account is the source, only [PERSON] can submit the transaction to the network, no one else. That way, [PERSON] can connect the transaction submitted to the network by recording his account sequence number at the time of the blind signature. We could eliminate the problem by making the user create the Stellar channel account that would serve as a source account for the transaction. However, Stellar requires each account to be funded with a minimal amount of 1 XLM, an account can be funded by the Bob, but then we are back to the original problem of sequence numbers. For Blockchains that does not rely on sequence numbers, transactions can be prepared and submitted asynchronously; therefore, the problem does not exist. Here in Stellar, we sign blindly not the transaction, but introduce the intermediary step where the blind signature subject is the authorization token. Such token can be redeemed for ballot transaction asynchronously and so, anonymously. Let us see how it is implemented. [PERSON] prepares an authorization token \(M\) and creates a blind signature with [PERSON]. After a random period of time, [PERSON] comes back to [PERSON], this time as an anonymous user. From now, [PERSON] is called [PERSON] to indicate that for [PERSON], the person has no connection to [PERSON]. [PERSON] knows nothing about Anonymous, except that it has a signed token, which authorizes it to redeem ballot-paper. We understand ballot-paper as a transaction that funds account and send one vote-token to the account specified by Anonymous. From now, Anonymous can send the vote token to the ballot-box account, in any order, at any time. It is important to note that [PERSON] uses a different key pair for a blind signature. That way, he is protected from signing malicious transactions on the Stellar network. We need to figure out one more thing, the value of \(M\). It must be at the equilibrium point, where the user is safe about its anonymity, yet, [PERSON] is protected from double-token-issuance. It turns out that just random bytes will do the work. It does not reveal any information about the user, and it prevents from double-token-issuance because [PERSON] will record each \(M\) so that they can be redeemed only once. Users are incentivized to pick a unique random number because collisions would disqualify them from redeeming ballot-paper. To achieve even more anonymity, the user must completely cover its track. For now, only an IP address is common across all steps. To fix this issue, we can use Tor (The Onion Router) on the client-app.