Is there any reason why we should not submit the public key with the signature?

The PeaceFounder voting system works fine without encrypting the vote before sending it over to the tally. However, encryption of the vote selection can be added with seemingly no extra assumptions. In particular, the failure of the collector to decrypt the votes is equivalent to saying that the votes have been deleted from their system. In both cases, the blamed party is unchanged, and the result is the same - unpublished votes.

Encrypted votes can help maintain the imparity of auditors/proxies through which votes are routed in case of collector failures. The TOR exit node is another involved party where imparity would be necessary so that it wouldn't become an avenue for network sabotage for those who don't vote in a particular way.

Another use of selection encryption is that it could enable coerced vote tagging. In situations where the voter anticipates that their coercer will watch from the back or will take their device and ask for credentials, the voter can produce a decoy PIN code, which works as an ordinary one except for the fact that the votes cast with it would be tagged as coerced and thus not counted. If previously a vote had been cast without a coercion tag, it would be counted instead. For this to work, the coercer should not know that the voter had created a decoy PIN code, as then he could ask for both of them. An unlimited number of decoy PIN codes should be allowed to be created. An alternative is that every wrong PIN code could be considered a decoy PIN code with which a vote would be tagged as coerced.

To implement vote encryption, we shall recognise the two failure modes we need to protect against:

• The voter encrypts a jibberish and blames the collector for incorrectly decrypting.
• The collector spoils the vote by claiming that the vote has been encrypted incorrectly.

To protect against these introduced threat vectors, we need a proof of correct decryption.

The simplest way to encrypt the vote is to use collector public key C <- g^x as a means to establish a secret key on the client as K<-C^y, which can be hashed and then used with symmetric encryption. The voter sends back V<-g^y along the symmetric encryption, from which the collector can derive the symmetric key. In this scenario, at the end of the vote, the collector could prove that it has decrypted the vote correctly by publishing zero-knowledge proof that log_C K = log_g V, which is doable but overly complicated.

We can use the fact that the encryption is only needed temporarily. The collector creates a sacrificial public key S<-g^s and distributes it to voters before they cast their vote. That can be done in the same way as the commit is distributed currently. After the vote, the collector would publish s, allowing everyone to verify a correct decryption.

To act on this proposal, we will need to encrypt the selection for the vote:

struct Vote
    proposal::Digest
    seed::Digest
    enc::EncryptedSelection
    seq::Integer
    sig::Seal
end

struct EncryptedSelection
    S::Pseudonym
    V::Pseudonym
    cyphertext::Vector{UInt8}
end	

Notice that the sequence number nor the signature is encrypted. The signature must be left unencrypted as that allows everyone whose vote is eligible to be included in the ballot box to verify that, which is essential for accountability. The link between the pseudonym and the voter is secret; thus, disturbing the voting experience for those who would usually not vote in a certain way is impossible. The sequence number, on the other hand, can be left in the open as it is only trying to establish an order for votes in the final tally and thus is of no importance for maintaining imparity.

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

There could be situations where citizens had lost their ID cards and thus needs to get a new one. How would one deal with the public key in the public ledger?

A possible solution seems to be:

• Put in the anonymous public key ledger also the expiration date of the ID card and thus of the public key.
• Ask citizen to sign his ID data with his card and keep the signature in secret to prove his relation with the public key.

It is possible to imagine a situation where coercer gets an ID card with PIN code proceeds with the creation of a new account to be sure that the random numbers are not registered. And then proceeds with the signing of the vote.

A possible solution to such a problem seems to be:

• Delegate only authorized devices which are only held by state officials to be able to create a new fake ID.

Revenue:

• Software development for smartcards with the designed protocol for security.
• Hardware
• Support for governments and corporations

Publicity:

• Open-source company
• A decentralised alternative to https://www.loomio.org/
• A non-blockchain alternative to https://aragon.org/
• Democratisation of activism

Offer for investors:

• Max 20%/year returns on an invested capital measured in terms of labour-power - how many hours one can afford to hire an entry-level programmer in the company.
• Participation in business decisions with co-founders
• No property rights, no compensation for lost investment
• Has a first hand on what to do on revenue (up to 20% a year).

Under the current state of PeaceFounder, administrators face a significant limitation: they lack the capability to terminate memberships. This function is crucial in various scenarios. For instance, when a member fails to submit necessary authenticity documents within the allotted time post-registration, their membership must be annulled. Additionally, this feature is vital for addressing privacy concerns, such as when members wish to withdraw and have their associated records deleted. Furthermore, an essential aspect of membership management involves issuing new credentials in cases where a member loses their device or experiences a security breach with their key being compromised.

The process of terminating a membership in PeaceFounder presents its own set of challenges. The core difficulty lies in the inability to link a member's real identity and their current pseudonym, which prevents the removal of it in subsequent braidings. This link is only known exclusively to the member's client device, as it only knows the private key that can generate them.

A straightforward approach to address this issue involves resetting the generator in the braidchain and taking identity pseudonyms of the membership certificates as inputs to subsequent braidings. However, this method presents a significant hurdle, particularly for larger organisations. Implementing this reset each time a member is terminated can be prohibitively expensive. In particular, taking into account that the frequency of membership termination cases increases proportionally with the number of members as well as the required compute to do braidings, making this approach to scale as $O(N^2)$. Therefore, a more sophisticated and nuanced solution is needed.

To reduce the number of generator resets, the membership terminations could be batched together until some set threshold is reached. In between this time, we could leverage an assumption that members use a PeaceFounder client that has not been tampered with and thus could block terminated members from voting at the endpoint. One may argue that the best time to reset the generator is before the proposal is published; thus, such assumption would not be needed. Nevertheless, the client's device would need to inform if their membership is terminated in a timely manner rather than letting members be confused on the issue of why their cast votes can't be recorded. Thus, the implementation would essentially be the same.

To officially terminate a membership, the registrar issues a Termination record, which is submitted to the braidchain. In the most simple form, it points to the terminated membership certificate record index and contains the registrar signature:

struct Termination <: Transaction
    index::Int
    approval::Seal # also contains a timestamp
end

Perhaps we may need to rename it to MembershipTermination if specialised fields for the nature of the termination need to be provided. However, there is also a potential use for a termination record to cancel a malformed Proposal record before the vote in situations where urgent corrections are needed.

The next step is to inform the corresponding member's clients' devices about this record. It is not allowed for clients' devices to ask if their membership record is still valid before or after the vote casting as that provides a giveaway for the identity of the pseudonym with which the vote is cast, as it can be easily tracked.

To avoid such tracking, a bitmask that lists all terminated records could be included in the braidchain commit state retrieved along with the proposal record. So that upon receiving the proposal, the members' clients would know whether their membership is still valid. In case the bitmask shows that their membership is terminated, the member's client, instead of voting, would source for the termination record under a path:

/braidchain/terminated/{index}

which would return a terminated record for the client along with its inclusion proof. Retrieval of the record is necessary to provide the users with tangible evidence they can check with other sources. In particular, the device would show the Termination record index, timestamp and issuer, which, if made improperly, can be disputed by the affected individual.

When a sufficient number of members have been terminated, the relative generator needs to be reset from the base generator to flush out old pseudonyms. This is done by a generator reset record that has the following schema:

struct GeneratorReset <: Transaction
    approval::Seal
end

Then, in the next braid, input is taken from the generator as specified in the DemeSpec record, and the pseudonym set is constructed from identity pseudonyms recorded from the admission part of the member certificates.

A risk is that a corrupt member could exploit this behaviour by getting more votes than others. In the short term, this could be mitigated by limiting to a single new membership certificate until the generator is reset. In the long term, the behaviour of members frequently requesting new credentials would be suspicious and could form the grounds for permanent termination of membership.

One limitation for issuing new credentials is that a long-lasting member would be treated as a newly registered one. So, it would not be able to vote on already published proposals on the braidchain. In situations where the member is able to recover the key from the secondary source, it still could be cautiously used for old proposals by the member to check if someone else does not supersede it. Meanwhile, for new proposals, a new key would be used. This would require a modification of the termination record to include a field that the old key can still be used.

In large demes, the size of the bitmask could become large. To alleviate that, a bit of compression can be used. On top of that, GeneratorReset could contain terminated members, and then commits could show only newly terminated ones, which would significantly reduce a compressed bitmask size and make it practical for those contexts.

We need to land the design within the present research literature. Mainly the task is to find references for every particular design choice and proper terminology as used in the literature.

For example, anti-coercion and anti-bribery scheme is already discussed in:

http://www.cs.cornell.edu/andru/papers/civitas-tr.pdf

In order to ensure the integrity of elections, it is crucial that independent auditors audit the legitimacy of members. However, the records that support the membership cannot be made public as it would violate the members' right to freedom of association and would also infringe on GDPR. Keeping these records confidential while ensuring they are sufficiently audited can be challenging and may require reducing openness to prevent any possible leaks.

To overcome this dilemma in favour of more openness, a sampling of the electoral roll could be used. A large enough sample size can provide sufficient confidence that a potentially corrupt registrar could not have affected the election result, whereas keeping it small reduces the impact of leaks from the auditors. This lowers the trust barrier and opens the electoral roll auditing for more independent parties.

However, the sampling of electoral roll records introduces the following threat vectors:

• If the auditor is allowed to choose which particular member records they want to get, that could be used for spying, an opportunity for collecting information for the association of yet unknown members for the adversary;
• If the registrar is allowed to choose which records to provide, it could simply provide those which are authentic and hide the fake members to affect the results of important votes;
• Another strategy a corrupt registrar could corroborate with a small minority is that fake credentials can be signed multiple times. Thus, the supporting documents for the sample can be compiled so that signed records would not reveal this kind of abuse.

The solution to the first two issues requires a verifiably random sample. This can be achieved by sorting members with a random number and taking the top of the list. The random number can be generated verifiably with the League of Entropy. The time of closing could be taken as the identifier for the pulse, which has a robust case for commitment as it is signed by every member who casts a vote for a particular proposal.

The second ingredient to protect against a corrupt registrar and conspiring minority is to keep an immutable append-only log for all supporting records for membership certificates. The log must list document hashes (which can be randomised with a secret factor) and the member index for which it is recorded. A hash that fixates the list can be put within the proposal to prevent tampering with this list after the vote.

It seems reasonable to embed the document hashes into a history tree. If it would be used, then we could use proposals to store the current tree root hash. This could be combined with a fancy consistency proof with respect to the previous tree root hash, thus ensuring that new records are only appended to the electoral roll ledger. This property, for instance, ensures that auditing of the legitimacy of the latest proposal also automatically legitimises previous ones.

The electoral roll would need to anticipate that a member may want to terminate their membership and request the removal of associated data. To do so, the electoral roll would have a special PRUNED record which contains hashes of all removed records so that the integrity of the history tree would not be affected.

For auditors to audit the electoral roll, they would need the complete list of record hashes, which lists when the record was created and for which member it was made, together with receiving the member record sample records. The auditor then would verify the following:

• All records linked to membership are provided unless the member records have been explicitly pruned before the vote started and membership was terminated accordingly;
• That history tree is consistent with the root hash encoded in the proposal;
• That member sample is verifiably random according to the provided evidence used for correctly used randomness;
• That every provided member's record is authentic.

The first three steps can be automated with a single command, whereas the auditor does the last step manually as before.

The changes which need to be done are to add a field electoral_roll::AckConsistency{ElectoralRollState} in the Proposal type and add checks to the proposal. Another required addition is the public key from the League of Entropy, which will be authorised to issue the randomness. On top of that comes the implementation of electoral roll record management and coupling it to proposal creation to get these parameters.

Implementation of the proposal would add an assumption that randomness generated by the League of Entropy can be trusted and will be available. This assumption is also needed to implement ballot sharding, which could be explored in the future. In addition, a sampling could also be applied to the votes to provide them to the auditors before the cooldown period has ended so that the probability that coercers/bribers could learn whether their efforts had been effective could be too small to bother.

Currently, there is an in-house implementation for authorised request handling. It is used during the registration procedure where prospective member clients authorise their identity pseudonyms with the received token using HMAC. Also, the HMAC authorisation allows external services to authorise the invitation of a new member, which is demonstrated with Recruiters.jl.

The problem with the current approach is that types of messages are hardcoded and thus introduce unnecessary complexity for maintaining the code. One of the bad places is with external server registration API, where each API parameter was included individually into an octet string for hashing. Also, it has obstructed method access in the mapper layer where authorisation is being done.

It has become clear that there is no reason not to embrace the authorisation at the HTTP request level. The mapper layer would maintain the list of tokens and keys, whereas the bouncing logic would be put in the service layer.

The most authoritative specification for HMAC-authorised requests comes from Microsoft for Azure REST API access. It specifies that the HTTP header should have the following form:

Host: {myconfig}.azconfig.io
Date: Fri, 11 May 2018 18:48:36 GMT
x-ms-content-sha256: {SHA256 hash of the request body}
Authorization: HMAC-SHA256 Credential={Access Key ID}&SignedHeaders=x-ms-date;host;x-ms-content-sha256&Signature={Signature}

Where the signature is done on HTTP_METHOD + '\n' + path_and_query + '\n' + signed_headers_values where signed header values are separated by a semicolon.

One of the shortcomings of the specification is that it only specifies how requests shall be signed but not replies. To overcome that, a method = REPLY could be appropriate to ensure the integrity of the reply and prevent it from being used in a replay attack for the server.

The steps for implementing this would be:

• Get some test vectors from the JS code snippet signRequest method;
• Implement a corresponding signRequest method in Julia;
• Create a minimal example with HTTP bouncer in Julia and test that;
• Reimplement client identity pseudonym registration;
• Expose a new member registration API for external use.

Blind signature for proving participation

Some communities may wish to nudge their members to vote, providing benefits for those who have already cast a vote or punishing those who ignore democratic decision-making. In ordinary e-voting systems, that can be easily achieved through a voter's registry. However, this is not possible for PeaceFounder because voters are completely anonymous when they cast a vote.

One way to address this issue is with a blind signature scheme. The voter takes his identity pseudonym, blinds it with a random factor and includes that in the vote when it is sent to the ballot box. The collector checks that the vote is valid and, if so, signs the blinded group element at the time when the vote is recorded in the ledger. The previous blind signature is used if the voter has already cast a ballot.

The voter then receives an acknowledgement that the vote is permanently recorded in the chain together with the blind signature and timestamp. The voter unblinds the blind signature with its blinding factor and obtains a signature on his identity pseudonym as proof of participation. That can then be safely shown publicly for anyone who wants to see that the person has voted without being linked to the casted vote.

The assumptions for this scheme to work are:

• The voter's device is free of malware and does not attempt to sabotage the process
• The collector does not issue more blind signatures as necessary

It's hard to imagine what could be the end goal for malware to sabotage the process. For certain, it would make voters immediately aware of an issue of voting, which would raise suspicion for security being compromised of the device and consequently would give a stimulus to be addressed.

The second assumption would be easily found out. Furthermore, as a signature is issued on the identity pseudonym, there are no ways for the adversary to get a practical advantage as one is sufficient. Thus this scheme should be fairly secure for proving participation.

Requirements

Let's list a few properties which are essential when selecting a blind signature to use:

• The blind signature can be publically verified to be valid.
• Blinded messages can't be linked to unblinded ones, even with the knowledge of the signer's secret key.
• A malformed signature which could enable it to be linked to unblinded one could not be made undetected.

It seems that the first property is not satisfied by RSA blind signatures; nevertheless, it perhaps could be addressed using zero-knowledge proof. The second property is critical to satisfy as it can spoil all anonymity gained through braiding.

Implementation

The work has already started as inclusion for timestamp added the possibility to record votes together with other fields. The changed types of supporting the scheme could look as follows:

struct Vote
    proposal::Digest
    seed::Digest
    selection::Selection
    seq::Int
    approval::Union{Seal, Nothing} 
    blinded_commitment		
end

A blinded commitment is constructed from the voter's identity pseudonym with a hash-like function.

struct CastRecord
    vote::Vote
    timestamp::DateTime
    blind_signature
end

Note that to ensure fairness in property and prevent also disclosing information for revoting, the signature is not published as a receipt, but it is rather a hash calculated as H(vote|blind_signature).

struct CastReceipt
    vote::Digest
    timestamp::DateTime
    blind_signature::Digest # H(vote|blind_signature)
end

When the vote is cast, the blind signature is returned with the CastAck message:

struct CastAck
    blind_signature
    receipt::CastReceipt
    ack::InclusionProof
end

Alternatives

• Perhaps, something could be done with accumulators.
• Reversing through braiders

If one considers a static random number in the signature an intelligent briber could lookup into a random number which was in the public key registration signature.

A possible solution to the problem:

• Make random numbers with a hashing function hash(random,count) where the count is an internal counter of the card.

At present, voters can only confirm that their vote has been cast as intended and accurately counted after the vote has ended and the votes are published. As the publication of votes can be delayed as a measure against coercion, it might discourage voters' participation from verifying that their vote is indeed cast as intended and counted as cast. The key issue lies in the possibility of unnoticed malware on voting devices. If voters don't verify their votes, the likelihood of malware affecting a significant number of votes without detection increases. Thus, having a procedure that enables immediate verification of the voting process is essential to engage more voters to check their votes.

The PeaceFounder system can address this by providing voters with a token displayed on the client's screen for vote verification. This token can be used in a web browser to confirm that the vote has been cast as intended. It also indicates if the vote has been superseded by a subsequent vote or one with a higher sequence number, which may occur if the member's key is compromised. To maintain receipt-freeness, the token remains valid for only a short period, such as 15 minutes. The expiration is crucial; it allows voters to verify their votes while preventing coercion or bribery attempts. It also hinders any unsolicited checks on voters' choices.

The most straightforward method to generate a token is using the byte string of the vote. This is done by setting the token as $token={\rm{Hash}}(0|vote)$, where the vote itself is the secret to be safeguarded. To utilise this token, an HTTP request is sent to the server containing $TokenID={\rm Hash}(token)$ along with an HMAC of the request. This request is directed to:

GET /ballotbox/{proposal_index}/votes/peek/{token_id}

When the server receives a vote verification request, it first checks that the token is valid and has not expired and then returns the vote's metadata. To maintain the integrity of this response during its transmission, the reply is secured with HMAC. Additionally, encrypting this reply would be advantageous to safeguard the voter's privacy when their network is under surveillance.

However, this approach has limitations. It doesn't prevent the possibility of a network monitor storing data for future comparison with the information on the ballotbox ledger, where votes and, therefore, tokens are eventually published. To enhance security in this aspect, the token could be derived from the Diffie-Hellman key, which could remain secret indefinitely. The server would generate a key pair and incorporate the public key into the receipt, whereas locally exponentiate pseudonym to derive the key.

There's also the risk of a corrupt election authority monitoring the voter. That could trace the voter's pseudonym back to their IP address and, ultimately, their identity. The most effective way to mitigate this risk is to run these requests through a TOR browser, ensuring anonymity. An ultimate solution from a usability point of view would be if the TOR client could be embedded within web assembly to make the request, but there does not seem to be support for that.

For this issue, the following tasks thus need to be addressed:

• Implement the HTTP endpoint;
• Add HMAC verification for the request;
• Add encryption of the reply;
• Implement a static website form where the request for peeking a vote can be made.

Regarding the website interface, several technical details must be specified: the server's address, the Hash/HMAC function for request authorisation, and the encryption method for replies. However, these technicalities will be seamlessly integrated into the user experience. A custom-designed bulletin board facade will hardcode these parameters, requiring the user only to input the token.

It's crucial to highlight that while voters can verify their vote to be cast as intended through this system, there remains uncertainty. Voters cannot be assured that malware won't ultimately influence the election results by altering their votes or adding a coercion tag invalidating it (which is not disclosed). Additionally, this implementation does not guard against the possibility of the server providing misleading information about the vote being cast. In such a scenario, the worst-case recourse for voters would be to recast their vote and eventually compare it with the ballotbox ledger after the votes are published.

A small democratic community often faces the challenge of limited resources, particularly when it comes to hosting bulletin board data or maintaining a comprehensive website for public record access. However, a recent trend offers a practical solution with static website hosting platforms. These platforms allow the creation of a static website directly from source code stored in a git repository without the hassle of setting up and managing certificates. A popular example is GitHub Pages, which simplifies deployment using action scripts to compile websites from sources.

Integrating a GitHub workflow to compile a webpage makes it an ideal platform for hosting a bulletin board interface. This setup has a dual advantage. The GitHub repository can serve as an authentic storage space for bulletin board records. Secondly, these records are easily accessible to the public via a web interface. Continuous integration further enhances this with build scripts, ensuring the integrity and verification of the bulletin board's contents. Those interested in verifying the bulletin board's integrity independently can either fork the repository and run the action script or clone the data locally.

Additionally, the use of the Zenodo repository enriches this system. Zenodo provides excellent archival workflows and the capability to generate a DOI link. This link serves a similar purpose to dataset references in scientific research, offering a reliable and citable record.

UX Concept

The public bulletin board closely mirrors that of the admin panel, with a few key adjustments tailored for voters. On accessing the bulletin page, voters are presented with a list of proposals organised by their opening time. Selecting a proposal takes them directly to its ballot box view.

Unlike the admin panel, where votes are always visible, the voter's view is designed to uphold fairness and receipt-freeness. Voters can see all votes only after their official release. Until then, the ballotbox view displays a notification detailing when the votes will become available. Additionally, voters are provided with a verification form to ensure that each vote is cast as intended. This form must be used within a 15-minute expiration window after casting the vote.

Once the votes are released, voters can confirm their individual votes within the ballot box. They can locate their vote using either the cast index, a pseudonym alias, or a timestamp. This step is crucial for voters to verify that their vote has been accurately counted and is free from external interference, such as malware or compromised key. It also allows them to ensure their vote has not been erroneously marked as coerced or overridden with a subsequent vote.

Implementation Details

To greatly simplify the implementation of the bulletin board facade and minimise the number of HTTP requests to the server, we store the bulletin board records within the git repository alongside the HTML page sources. These records are then displayed from a generated cache. This cache simplifies the information by flattening it, removing signatures, and substituting pseudonyms with their corresponding aliases. Initially, this caching system can be pretty straightforward. Managing one cache object for each record is feasible while allowing the JavaScript to load them dynamically.

Another essential feature is the notification system alerting users when the bulletin board content becomes outdated. This is particularly crucial in two scenarios: the addition of new proposals and the release of votes that are not yet available. For the braidchain ledger, which might become outdated, a manual trigger can be initiated through an HTTP request to the server. This request would involve comparing the latest proposal index on the server with the one stored locally. However, in most cases, this synchronisation would be handled more efficiently through regularly scheduled GitHub action scripts.

On the other hand, the absence of available votes would be flagged by comparing the scheduled release date and time of the votes, as listed in the proposal, with the current time. From the server's perspective, it is critical to ensure the git repository is updated promptly with new records, whether due to recent proposals being added or votes being released. Implementing this process should be straightforward, thus guaranteeing timely updates and keeping users well-informed.

The following list of tasks needs to be done to implement a public bulletin board facade:

• Serialize Bulletin Board Records on Disk. In particular implement serialisation and deserialisation of BraidReceipt objects.

• Create a Cache Generation Code. Develop code capable of generating a cache from locally stored bulletin board records.

• Implement JavaScript for Displaying Local Records. Write JavaScript code to read local records and display them in the braid chain, ballot box, and proposal list.

• Implement Outdated BraidChain Alert List all proposals and add a code to check the latest proposal index. Add the latest proposal index to the braid chain state commit and show an error if a newer proposal exists. Create a GitHub actions script that regularly checks if the more recent proposal is available, which is recorded in the cache.

• Develop JavaScript for Vote Verification. Add functionality to verify and display votes using a unique token number provided for voters after the vote.

• Integrate JavaScript for Ballot Box View and Information Messages. Implement switching between ballot box views when votes are released and display messages when the records are unavailable in the repo.

• Create a PeaceFounderBB. A package intended to initialise the repository which contains HTML interface and action scripts for continious integration.

The current invitation format, while functional, is rather verbose. It takes up too much space in the email, and the size of it can be offputting to users who need to copy and paste it. Another consideration is that the code could perhaps be made clickable, similar to how a magnet link works for torrent clients now.

As a reference, the current invite that PeaceFounder sends over email is as follows:

{"demehash":"8fd0ddc86f5ef0cf89a52bbb2f1f19b1b33ed53e73ce5a05da6fd9da3e94a4a7",
"route":"http://192.168.1.16:4584",
"hasher":"sha256",
"token":"2b148f52bc5a2f220b8e6f61b2b013c364ccb7050a0c397ec199413ebc923cb2",
"ticketid":"e9ef0fc87e04556487c656229fd140bd"}

There are three improvements which can be made to make the invites better:

1. Removing ticketid from Invites: The ticketid field can be eliminated from the invite structure. Instead, we can use the token to derive a sessionid by hashing the token.

2. Adopting a Magnet Link Inspired Format: Transitioning from JSON to a magnet link-inspired format will further streamline the invitation system. The proposed format is more compact and human-readable, which is beneficial for both use and debugging:

deme:xt=sha256:8fd0ddc86f5ef0cf89a52bbb2f1f19b1b33ed53e73ce5a05da6fd9da3e94a4a7&sr=http://192.168.1.16:4584&tk=2b148f52bc5a2f220b8e6f61b2b013c364ccb7050a0c397ec199413ebc923cb2

3. Optimizing Token and Hash Lengths: Considering the short-lived nature of these tokens and the subsequent signing with a digital identity provider, we can limit the token range for efficiency. Additionally, truncating the hash to 128 bits should maintain reasonable security. This approach will further reduce the invite size:

deme:xt=sha256:8fd0ddc86f5ef0cf89a52bbb2f1f19b1&sr=http://192.168.1.16:4584&tk=2b148f52bc5a2f22

This format maintains readability, which is essential for debugging while ensuring the invite is concise.

Currently, if a person attends many elections with the same ID card, it is possible to see how a particular anonymous person had changed his preferences over time. There is one interesting question:

• Is it a bug or a feature?

If one wants to make votes unlinked, it is possible to use the linked ring signature scheme where the signup group is different every time.

The current logo design is inspired by a twisted rope showing three individual strands from a side, which, for future reference, is as follows:

The logo was drawn on a reMarkable tablet, imported in Inkscape, and simplified. The logo which is used in GitHub has the following look:

where the boundary is being added automatically by the Orion browser, which looks quite elegant.

Unfortunately, the asymmetry is quite visible and contributes an unproven significantly to the unprofessional look. It was improved a little for the PeaceFounderAdmin panel:

I have been trying to generate the logo from the ground up with Luxor and got the following:

Which does look unrecognisable as a twisted rope.

Taking the two lines away helps in making the logo more pleasant to the eyes:

I tried to colour the logo in the following ways:

The code is published on a gist. However, the result is still unsatisfying.

After a voter casts their vote, a receipt is shown in which the pseudonym is listed as shown here:

The pseudonym field in this picture shows truncated sha256. The idea is that if one uses a modular prime group, it will take the entire screen, which is utterly unacceptable from a UI point of view. However, its utility is low and complicates the display of the vote on the bulletin board, as now one needs to show both the accurate pseudonym and a truncated hash of it. Furthermore, why sha256 and not sha1 or another hash function?

A more optimal solution already used extensively within PeaceFounderAdmin is to show a pseudonym alias. Pseuodnym alias is derived from sorting pseudonyms and assigning them an alias equal to its row index. This is highly practical as it enables showing pseudonyms in the following form:

#23.32

where #23 is a braid receipt record on the braidchain and 32 is a row index in the pseudonym output of the braid.

A key challenge arises from the client's inability to compute the alias independently, as it does not maintain a copy of the braidchain ledger. To address this, the server must deliver the alias while ensuring the client cannot be misguided. Additionally, it's crucial to keep the alias hidden from the receipt to prevent tracking. This scenario resembles the implementation of a blind signature scheme, which serves as a method for proving participation without compromising privacy.

To resolve this issue, we need to modify CastReceipt and CastAck types as follows:

struct CastReceipt
    vote::Digest
    timestamp::DateTime
    alias_commitment::Digest # H(vote|alias)
end

struct CastAck
    alias::Int
    receipt::CastReceipt
    ack::InclusionProof
end

The alias is returned unencrypted because encryption offers no utility here. For instance, if an eavesdropper has been monitoring the connection from the start, they would already know the vote and associated pseudonym. The only important part here is to prevent the coercer from looking up the bulletin board receipts and being unable to check if the voter has already revoted, maintaining receipt freeness.

Currently, it is possible for a corrupt official to generate a private key on his computer to upload the public key to the ledger. One would now that there are too many keys, by counting citizens in the public ledger. But it seems impossible to find a person who did that or find the key.

Two possible solutions are:

• The signature can be added only to the ledger if it is signed by a nonanonymous signature. In the ledger of identities, we could keep also the public key for the specific person.
• Authority keeps secret records of public key and ID correspondence. (The option still leaves room for a corrupt state).

Possible options:

• DemocracyCredit (current)
• PeaceFounder
• InvisibleHand

The PeaceFounder system is universally verifiable, a feature ensuring that every vote is cryptographically proven to come from a registered member, even if all involved parties are corrupt. To mitigate the influence of coercion or bribery, the authority can strategically delay the publication of votes, which weakens the link between coercers and their subjects before the voters lose receipt freeness. After the votes are published, every aspect of the voting process is transparent: all proofs of votes are made publicly available. This transparency allows any interested party to audit the election results and, at their convenience, independently reproduce the announced tally.

Evidence auditing in the PeaceFounder system begins immediately after the authority publishes the election tally, accompanied by a tree hash of the votes. Each voter's client software maintains a 'consistency proof chain.' This chain validates that their vote has been recorded accurately. Subsequently, voters can update their proof chains to verify that their vote remains included in the final announced tally. This verification is done by comparing the tree hash displayed on their device with the one in the official tally.

In cases where a voter discovers a discrepancy in the tree hash or their devices show inconsistencies with the newly received ballot box commitment, they have the option to generate a blame proof. This proof can be published anonymously, proving the corruption of the authority. However, the effectiveness of this system relies on a critical assumption: the public environment must be open to these blame proofs and hold the authority accountable. If this receptiveness is lacking, the published tree hash cannot be regarded as a consensus. Therefore, auditors must consider potential corruption within the authority and be vigilant about the channels through which they receive a ballotbox tree hash.

The best source for the ballotbox tree hash comes from the member's client devices, which can display the current tree hash and forward ballotbox commitment to the auditor. Even if the devices are infected with the malware, they would be unable to affect the ballotbox commitment. PeaceFounder's security is fundamentally based on the premise that at least one device remains uncompromised, and the voter would compare the tree hash shown on the device with that of an officially announced tally, and a corrupt ballot box collector cannot discern which device is. Therefore, that compels them to maintain a consistent view of the ballot box ledger for everyone, as failing to do so would generate blame proof.

When the auditor secures the authoritative source of the ballot box tree hash, they can initiate a comprehensive audit. The process begins with the retrieval of both the ballotbox and braidchain ledgers. This retrieval may involve collecting records through individual HTTP requests, accessing published records on a GitHub repository, or utilising other hosting providers and synchronisation solutions. Once all necessary data has been gathered, the auditor conducts an initial verification to ensure the completeness of the data using the following command:

peacefounder-audit root ballotbox ⌘371:sha256:BFDODDC-6FSEFOCF-B852883-2F1F1581-B33EDS3-73CESAD5-DAEFD8DA-39414A7

where ballotbox is the location of records.

In the event of an invalid ballot box commit, the command will trigger an error. Conversely, if there are more records in the ballot box than indicated by the commit tree hash, a warning prompts the auditor to verify whether a new tree hash has been officially announced with the tally or if member devices have retrieved a newer version. Should neither be the case, the auditor will have the option to isolate the uncommitted records for separate inspection.

The next step involves auditing all published evidence, which can be executed using the following command:

peacefounder-audit eligibility braidchain ballotbox

In this context, braidchain refers to the retrieved records. It's important to note that the braidchain itself does not require separate verification. This is because each vote in the ballotbox includes a hash of the corresponding proposal, which in turn contains a tree hash within its anchor section. If the braidchain does not contain a proposal with a given hash, or if the braidchain tree hash is inconsistent with that of one listed in the proposal, the audit will terminate with an error. In such cases, the auditor must seek an alternative source to retrieve the braidchain.

After the tree hash of the braidchain is verified, it follows through checking its integrity. Records are issued by authorised entities listed in the DemeSpec roster; checks that all signatures are valid and that added records are compatible with the braid chain state and verify zero-knowledge proofs of the braid receipts. Finally, the pseudonym set with which votes are collected in the ballot box is compared by the generator encoded in the with the one ge proposal anchor.

When the audit successfully verifies that only eligible pseudonyms have cast the vote, the process can advance to a tallying stage, executed with the following command:

peacefounder-audit tally ballotbox ⌘371:sha256:BFDODDC-6FSEFOCF-B852883-2F1F1581-B33EDS3-73CESAD5-DAEFD8DA-39414A7

This command checks first that every signature for the vote is valid. Then, it proceeds in selecting valid votes, which are then finally being counted. This command works without braidchain as ballotbox contains proposal, demespec and inclusion proof for the demespec with respect to the proposal anchor tree root under ballotbox/meta directory (the votes themselves are stored under ballotbox/votes and receipts under ballotbox/receipts). Note that this works because the hash function is passed with the tree hash. Upon a successful audit, the command outputs the final tally along with the ballot box tree hash.

The last part of auditing is verifying the authenticity of the members who could have participated in the vote, which is important to establish the legitimacy of the vote. In situations where all membership supporting documents are given to the auditor, the auditing stops there. However, in a situation where supporting documents are sampled as proposed previously, the way the sample is formed must be verified to be verifiably random. This could be audited as follows:

peacefounder-audit cohort braidchain electoral-roll-sample

where electoral-roll-sample contains a meta folder that includes a proposal record and a pulse issued by Legue of Entropy. This is, however, just an API and will need to be implemented with electoral roll sampling feature implementation.

With the implementation of evidence auditing, the Model part of the PeaceFounder codebase could be refactored into Core, which could contain only the types and methods necessary to implement auditing and is something which could be investigated. In such a situation, audit terminal API could be implemented under the Audit module, which would depend only on Parser and Core, making it easier to reason about it.

The necessary steps thus to support this API are:

• implement serialisation/deserialization for a braid receipt record;
• store the evidence on the disk;
• implement a method to retrieve all records over HTTP;
• implement record submission to a GitHub repo, which can be configured from admin panel;
• collect the auditing pieces under Audit module and implement terminal API;
• refactor the Model module and create a Core module;
• make an integration test where braidchain and ballotbox are serialised into the disk and then verified with the Audit module.