# A P2P Scheme for Debating and Voting with Unconditional Flexibility
## 3 Scheme
### Phase 2: Alias Checking and Debating  
The second phase groups the operations required to accept alias keys from the other users (Figure 2). This phase makes use of anonymous channels that prevent physical traceability (see Section 2). Users connect to the others through these channels, identifying themselves with their alias key only, and proving their eligibility with the corresponding signatures obtained in the previous phase. The steps are threefold:  
1. User \(U_{i}\) runs the TLS protocol over an anonymous channel using the alias certificate \(AC_{ij}\) with each user \(U_{j}\). In this link \(U_{i}\) acts as a client and \(U_{j}\) as a server. User \(U_{i}\) must check the digital certificate \(DC_{j}\) of user \(U_{j}\) and user \(U_{j}\) must check his/her own signature on alias hash, namely \(Sign(a_{i},K_{j}^{-1})\) shown in alias certificate \(AC_{ij}\). If it passes the test, the alias is accepted. At the end of this process each user has two TLS channels with each of the other users: one as an alias client to send messages and the other as a public server to listen to other aliases.
2. Now users can interact with others to argue, propose, and vote. This can be conducted in many ways, depending on the software that manages the debate. Any of them will allow users to make contributions (opinions, proposals, arguments, candidates, votes, etc.), which can vary in types, length and quantity. However, regardless of their features (unconditional flexibility), these contributions are messages that can be sent by a secure TLS channel which uses symmetric encryption or, when available, a broadcast anonymous channel. Thus, using these channels, any debate software can be used. Notice that this software works in a centralized way with respect to the rest of aliases.
3. The end of the debate and voting is determined by the time defined at the beginning with the initiator. At this point, all the contributions of an alias \(A_{i}\) can be compiled in a list. Users can check whether all their contributions (as aliases) have been registered in this list, and provide anything missing if necessary. When the list is complete, its  
Figure 1: Phase 1: Each pair of users \((U_{i},U_{j})\) builds a secure communication channel (1,2) and generates their alias keys (3). Then they transmit their hidden alias thanks to a random number. For example, \(U_{i}\) sends \(a_{i}\) hidden by \(r_{ij}\) (4). The receiving user \((U_{j})\) signs and returns it (5). Removing the \(r_{ij}\) factor gives the signed alias \(AC_{ij}\) (6).  
hash signed with \(A_{i}^{-1}\) is sent by each alias and checked by the receiver. This ends alias interaction.
4. Each user gathers all data sent by aliases, signs it with his/her digital certificate, and sends it to the other users. This signature prevents users from sending different data to different users without being detected. Then they compare what they have received. If there is a consensus the process ends. If there is a mismatch, signatures of users are compared to detect inconsistencies, and the aliases are revised. Aliases which are present more than \(n+1-\sqrt{n+1}\) times are accepted and the tally is computed with them.