<div dir="ltr"><div class="gmail_default" style="font-size:small">I am currently deploying the Mesh services for an external test and looking for small, self-contained applications that can be supported thereon.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The basic premise of the Mesh is that it becomes really easy to do a lot of cool cryptography iff we get to a point where use of private keys for security purposes is as fluent as passwords.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One facility I will eventually need is the ability to checkpoint assertions about public keys in a linked hash log (aka Blockchain). Since I am not of the proof of work faith, I am looking to DAG type approaches to assure integrity of the hash log (aka HashGraph). So I am looking for a smallish project that could showcase the effort and create a nucleus of services that could later be built into a HashGraph infrastructure.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One facility I think we need is the ability to record non-anonymous votes. This happens a lot in industry consortia where each member has a vote and the way that they vote is public. [Yes anonymous is more interesting as a problem but that can be built on the public voting scheme].</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So the basic idea is that there is a Web Service that accepts two types of data and records them in a hash log:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Votes</div><div class="gmail_default" style="font-size:small">2) Witness values.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Assume I am not stupid and the votes are authenticated appropriately, timestamped, etc. Votes can be encrypted until the close of the ballot is declared, etc.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The Witness values are any unpredictable value published by any other source that can be verified retrospectively. For example:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* A signed time source</div><div class="gmail_default" style="font-size:small">* Any block chain output</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Each witness value contains sufficient information to allow a third party to verify it. Typically this would be a URI and possibly a date-time or index value. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The hash log is signed every n minutes. When a vote (or any other value) is enrolled in the hash log, the service provides a signed receipt. This enables the voter to call fraud should their vote not be recorded. [For additional bonus points we can add in Micali Fair Contracts which went out of patent recently]</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Now consider a situation in which there are multiple vote servers accepting votes on the same ballot. If one goes down, another server can accept it. All the vote counter then needs to do is check all the approved logs. This prevents a form of fraud where the vote server goes down (or is DDoSed) when the ballot is in one side's favor.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One building block for such a system would be a disclosure service which publishes a list of public keys and then releases the corresponding private key at a specified time. So I would probably publish key pairs for each hour for the next 30 days, for each day for the next year and each week for the next decade on a rolling basis. Easy enough to do from a single master secret.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Using the same techniques as proxy re-encryption, people can choose multiple services and build n of m type quorum schemes using Shamir secret sharing on top. So if encrypted ballots are used and one of the disclosure services dies, the system remains robust.</div></div>