yoha

Well played! If only I had made my attempt earlier!

    2019-03-18T20:23:06+01:00
    AMD Phenom(tm) II X4 B50 Processor
    56.674783% (0x2912f5a00000 / 0x48792741a51a) ETA: 1 year 138 days (2020-09-18)

That is indeed the main issue with verifiable voting. The usual solutions offer various compromises, but it is not possible to both guarantee the ability to verify that one's ballot is counted correctly, and that you cannot prove for whom you voted.

Yes, it's possible, and it is an area of research in cryptography. For instance, have a look at Helios and Belenios.

> That's only possible if you sacrifice some of the stronger anonymity requirements

Untrue. You can use strong encryption to ensure confidentiality and zero-knowledge proofs to ensure integrity. Then, you can use methods from homomorphic encryption to tally the ballots. There is a whole area of research dedicated to this.

"Automated proof" means that the verification is automated. Actually automating the process of finding proofs is still mostly an open problem.

Formal proof software will help you on small stuff, but you will still do most of the work, and you have to go much more in details, so it takes much more time.

> When you try to come up with random words to compose a password

That's why you don't. Give a 64ki word dictionary from your native tongue to your computer and let it choose four words uniformly at random out of it. This gives you a password from a distribution with 64 bits of entropy, and is reasonably easy to memorize with moderate effort.

This means an attacker is expected to proceed to 2\\63 hashes to crack such a password. It would take almost 4 year to crack its MD5 digest on the rig used in the demonstration. If you not using a password manager for external sites (which might not use proper KDFs), you can throw in a fifth word, and be safe for the foreseeable future.

Right, my bad. I tend to write loops in the former style, thinking of them as reversed(range(9)). This is another advantage of this style. I should have been more cautious when writing the second one.

The point is that a beginner does not need to care about signedness. When you get to that point, you can take the time to explain how to loop properly over it.

This is about weighing correction versus readability. In the "arrow operator" version, the readability is decreased; in the "proper" version, a type cast is required, and this can lead to bugs with values greater than 2^sizeof(ssize_t).

Obviously, I just follow the convention when contributing to an existing project.