Several technical questions for DEG

There is no one who has not heard of the controversy surrounding electronic voting. The claims from the opposition seem to be correct, and the resistance from the database holders, which contradicts the declared principles that should be embedded in the system, looks like an attempt to hide the truth.

The chief editor of ECHO Moscow, Venediktov, who persistently pushed the EG, and claims that everything is fair, and no one convinced him of anything, the opposite.

The question is technical and interesting. And therefore, I studied What is wrong with the DEG in Moscow? from Zhizhyn. I went to and downloaded the database dumps that are there, PostgreSQL server and tried to figure out what exactly was wrong.

Technical side, first impression

For study, I chose a database in which information about “Election of deputies of the State Duma of the Federal Assembly of the Russian Federation of the eighth convocation in a single-mandate constituency.“, file: observer-20210921_143000.sql

It’s all very bad.

The fact is that the database that lies there is not a blockchain, it is an accompanying database, which is supposed to be used for easy and fast access to the data that the blockchain contains. But, you can forget about it forever.

The first and main complaint of everyone who touched this database is that there is no connection with the person registered for voting and all subsequent actions with ballots.

Thus, voters and ballots are not connected in any way, but lie in different heaps. And, accordingly, the question is, if there is a re-voting, then how to understand which voice was previously? After all, it cannot be taken into account.

How does this happen and why?

This is because the DB on was created not for work, but for observation purposes. And it was done anyhow. It cannot be argued that this was done on purpose to make it impossible to verify the vote. Because if this is just “some kind of” base for observers, then no one really bothered to bother with it, and even more so to check and test, and therefore they made it crooked and askew.

The technical side. Getting to know the database

  1. the “blocks” table – this table is essentially useless here, it could make sense if it was supposed to be reconciled with a live blockchain. But for any checks and studies, there is no benefit from it, since it only contains links to transactions that are in the “transactions” table, and in it itself, data about the block is already contained. The only thing that could be verified is whether all the transactions contained in the block are really in the transactions table.

  2. the “transactions” table is the main table, where there is everything (what was put there), and we already know from other materials for studying this data that not everything was put there. The method_id field contains the code for the purpose of this transaction, (the description was taken from Zhizhin) that are important for us: 1 – registration of voters, 4 – issuing a ballot, 5 – checking the voter’s access, 6 – accepting a ballot (with an encrypted vote), 9 – decoding the vote

  3. table: “decrypted_ballots”, contains hashes of transactions with id 6 and id 9, and the decrypted voting result

The technical side. Data exploration

  • the “blocks” table appears to contain many empty blocks. It seems that the system, for some reason, constantly creates blocks, without much dependence on whether there is data or not. As if they are creating some kind of time lapse, confirming that everything is working, there are simply no operations. In theory, there is nothing wrong with that, but there is no good either. On the graph, it looks something like this:

  • the “transactions” table is the main table, where there is everything (what was put there), and we already know from other materials for studying this data that not everything was put there.

    • And then a problem arises, transactions with method_id 1 and 4 contain “voter_id” in the form “22443685531066461899103156899237857105006237160299631129744914447305194856993“, and transactions with method_id 5 and 6 contain related fields voter_key and author in the form of a hash”78cc1e391507d9ef8bcddfbf72d1cbde95c1f36f84940a5b8be4e8fa0542096a“Thus, it is impossible to associate a voter with his ballot. There is a possibility that voter_key is an encrypted voter_id, but this is not confirmed, because if we assume that we have revotes in the database, then there will be duplicates of voter_key in the list of transactions of types 5 and 6.

    • Searching for duplicate transactions, returned method_id = 4, but they are not related to voting, but contain error records that occurred at the same time. In total, there are 34294 voters in the database who had entries about errors, and judging by the time of these errors (almost without an interval between them), they are purely technical in nature, the entry in the “status” field for them looks like this "{"type":"service_error","description":"Ballot cannot be issued","code":5,"runtime_id":0,"call_site":{"instance_id":1001,"call_type":"method","method_id":4}}"… As a result, the bulletin is issued 1.

    • Total, for method_id = 5 and 6, there are no double records, when checking records where there are duplicate voter_id, they showed that there are 34294 such voter_id in the database, and the total number of records is 78077. So, what do you get?

      • method_id = 4 = 1987373 – 78077 + 34294 = 1943590 ballots were issued, which corresponds to the data on the observer.

      • method_id = 5 = 2021969 confirmation records

      • method_id = 6 = 2021969 voting records,

      How can this be? Revotes? but a ballot is also issued for him (must be issued, otherwise how? O_o).
      Total: 2021969 – 1943590 = 78379 extra ballots! what is this? Stuffs? but how to check, there is no connection with the voters, just ballots that lie on top of those that were “printed by the printing house.” And this question is already beyond re-voting, etc.

    • method_id 9 – decryption of the vote, such entries in the “transactions” table are 1319943, which is significantly less than the issued ballots, they contain information about the decryption of the vote in the ballot, and this data is contained in the following table: “decrypted_ballots”. Why there are so few of them is a separate question. I heard such an explanation that the data on re-voting is in a separate secret blockchain, and taking into account the reconciliation with it, the votes were counted.

  • table: “decrypted_ballots”, contains 1318977 records, which is 966 less than in decryption transactions! This should not be the case in principle! The records simply disappeared, suddenly. There are decryption transactions, but no decryption itself. Of course, they can be deciphered, but stop. Why do we need to do this? There is a program, a blockchain, a database that should work. But it turns out that their work contains serious problems that lead to the fact that data simply disappears.

  • The graph shows that the dynamics are really similar to revotes, but the question arises, how could the revote be around 23:00 09/20/2019? 236 votes made between 7:00 pm and 8:00 pm were not counted. And we remember that you can re-vote only 3 hours after voting. While the last block was created at 2021-09-19 21:19:07.902 + 03. If these are re-votes, and the system should block the opportunity for 3 hours, then this could only be done by a special bot that did not take this feature into account.

  • An idea came up to compare the decrypted and unscrambled voices (which were probably canceled due to the likely re-voting):

  • It turns out a fierce trash. The last 236 unscrambled votes were simply not taken into account, at this hour and after it, there were simply no new ones. Therefore, a precise and clear answer is needed. Are the votes in the “decrypted_ballots” table complete and correct?

    • And if so, what is this strange revote discrepancy? then 0%, then 100%, what is wrong with these votes? Where do some of the votes go and for what reason?

    • If not, then there is nothing to talk about, incorrect data = no data, which means there was no observation of the vote, but it was just a show for disguise.

Why didn’t I start doing statistics?

There is no data on which statistics will be correctly done, yes, they do it, it shows anomalies, and it is important and necessary to do it, but, in my opinion, there are enough direct errors in the data that show that this system is completely unsuitable for voting.

Already those veils of the fact that:

  • More ballots were counted than were issued – a failure.

  • Some of the decrypted ballots have disappeared – a failure.

  • It is impossible to understand what exactly is happening in the database – there is no connection between the voter and the ballot, which means it is impossible to calculate correctly – a failure.

  • It is impossible to understand why only 65.23% were deciphered – a failure.

  • If these data that were given to us are not correct, then give the correct ones, they cannot provide them – a failure.

It is enough to recognize the system as inoperative and cancel the EG results completely.

Even if “they” provide some correct databases later, alas, it will be difficult to trust them. I doubt they will be able to falsify the hash chains well enough to create a suitable fake blockchain. Therefore, they will not give anything.

The question is, how will statistics help if the organizers do not admit direct and obvious mistakes?

Some conclusions

  1. It is not known how to interpret such relations in general. The fact is that observers, in fact, do not have the correct material for observation and verification.

  2. It is only clear that some of the data is probably correct, and according to them, many people make quite interesting statistical reviews that indicate anomalies that are impossible without outside interference.

  3. If some data is hidden from us, then the question arises – why? Blockchains with money are in the public domain, and the blockchain with voting is hidden from us. If this has a purpose, what is it? The options that come to mind:

    1. Nothing worked and a bunch of errors turned out, and the data that was foisted on us is incorrect. And hide a broken, substandard product.

    2. They hide the real data, since they differ from the results that are offered to us as the voting results.

    3. It is likely that in the real blockchain, stuffing was done, but so clumsy that they will be obvious.

    4. Their secret blockchain contains real data of voters, who voted and how. Alas, the system cannot be anonymous by definition. Registration on state sites is not anonymous. SMS are sent to real people. Therefore, they lie to us that everything is anonymous, but in reality it is not.

    5. Any combination to choose from.

  4. If the data that we were offered must be considered correct and complete, then the only conclusion that can be drawn is that the EG system did not work, we see a lot of errors and inconsistencies that simply cannot be in a correctly working system, and if it does not work correctly, then it is impossible to trust the results of its work, which means they should be canceled, and the system should be finalized

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *