The first clause of Design Considerations, "Although elegant and (thus far) invincible," shows a lack of understanding of currently possible and prior blockchain attacks.
This protocol allows voting any Voter ID multiple times. There is a significant window of time until one of the blocks containing the Voter ID/ballot ID Hash is added to the block chain. During this time, all Voter IDs in the prospective block may be voted multiple times. This can occur by making a copy of a physical voter ID and simply using it twice at relatively the same time - just not on the same terminal. The exploitability chance increases as the number of votes per block increases. The blockchain plus the union of all unsent blocks for all terminals, not a local database, should be checked for who has voted. This is compounded by not checking when the blocks are added to the blockchain.
Another issue with the local database, is that even if it is made to be a site database, many jurisdictions with early voting allow voters to vote anywhere, not just at their assigned voting location.
The selected candidates are not signed properly with a voter's key. There is no assurance that a particular voter actually cast a vote for a specific candidate and not, say, "Mickey Mouse." This is actually one of the purposes of smart cards and similar. Beyond any protocol issues, this is the central purpose of any voting system, to ensure that when votes are cast the voter id is redacted but that that voter id's candidate selection can be validated!
The Central Admin should release the list of the machine's public keys _prior_ to the election not _after_.
There really are a lot of security issues with this security design.
That being said, this paper is the winner of a cyber challenge here: http://www.economist.com/whichmba/mba-case-studies/cyber-sec...