xBdgcAR4

1Cicada: A Distributed Direct
2Democracy and Decentralized
3Application Platform
4@laugh1ng.m0nk3y - @jade.rabb1t.23 - @ox.head.826
5cicada [AT] iamcicada.com
6Version 2016.28.11.GA.003
7Table of Contents
8Abstract .................................................................................................................................................. 3
9Motivation .............................................................................................................................................. 3
10Defining Distributed Direct Democracy .................................................................................................... 5
11Technology Introduction ......................................................................................................................... 7
12Philosophy of the Project ........................................................................................................................ 8
13Architecture .......................................................................................................................................... 12
14Abstracts/Primitives of the System ........................................................................................................ 13
15Individual Component Outlines ............................................................................................................. 15
16Human Unique Identifier - HUID/SID/SIN ............................................................................................... 15
17Outline of Proposed Steps for Enrollment in the System ........................................................................ 20
18Use of the HUID in the System ............................................................................................................... 22
19Sub/IDs ................................................................................................................................................. 23
20Organizational Identities ....................................................................................................................... 24
21Info Wallets ........................................................................................................................................... 26
22Blockchain/Distributed Ledger .............................................................................................................. 26
23Blockchain of Blockchains ...................................................................................................................... 27
24Distributed Proof of Work ..................................................................................................................... 28
25Verifiable Computing ............................................................................................................................. 32 
262
27Upgradability......................................................................................................................................... 32
28Networking Outline ............................................................................................................................... 33
29Attacks on Kademlia Networks .......................................................................................................... 35
30Sybil Attacks .................................................................................................................................. 35
31Attacks on the underlying network ................................................................................................ 36
32Node Impersonation ...................................................................................................................... 36
33Eclipse Attacks ............................................................................................................................... 37
34Churn Attacks ................................................................................................................................ 37
35Reputation Attacks ........................................................................................................................ 37
36Self-promotion .............................................................................................................................. 37
37Whitewashing ................................................................................................................................ 37
38Slandering ..................................................................................................................................... 37
39Defeating Attacks on Kademlia and Trust Networks ........................................................................... 37
40Mesh Network Fallback ..................................................................................................................... 39
41MixNet .............................................................................................................................................. 40
42P2P Communication System .................................................................................................................. 40
43Additional Components of the System ................................................................................................... 41
44Stores of Value .................................................................................................................................. 42
45Money ............................................................................................................................................... 42
46Action Tokens .................................................................................................................................... 42
47Blind Tokens ...................................................................................................................................... 43
48Transactions ...................................................................................................................................... 43
49Proposal System ................................................................................................................................ 43
50Rulesets ............................................................................................................................................. 44
51Rules/Law Framework ....................................................................................................................... 44
52Voting Framework ............................................................................................................................. 44
53Vote Suggestion System .................................................................................................................... 44
54Auto-Voting system ........................................................................................................................... 45
55Rewards ............................................................................................................................................ 45
56Data Storage ...................................................................................................................................... 45
57Sub-Organizations ............................................................................................................................. 45
58Information Post ............................................................................................................................... 45 
593
60Marketplace ...................................................................................................................................... 46
61Modules/Extensions .......................................................................................................................... 46
62Procedural Patterns of the Platform ...................................................................................................... 46
63System Bootstrap/System Instantiation ............................................................................................. 46
64Procedures of the DDD .......................................................................................................................... 47
65Defining Citizenship by Linking HUID to Citizenship IDs ...................................................................... 47
66Conclusion ............................................................................................................................................ 49
67Abstract
68This paper outlines a revolutionary, open source, decentralized application platform (DAPP) along
69with its first major application, a distributed direct democracy (DDD). To create something scalable
70enough to run an entire nation with no representatives, we created two cutting edge technologies to
71serve as the foundation of the platform:
721] A decentralized, privacy guaranteeing Human Unique Identifier (HUID) unique to every person on
73the planet that returns control of personally identifying information (PII) back to individuals, allowing
74for revocable role based access control to that data.
752] A new Distributed Proof of Work (DPoW) backed blockchain that is immune to centralization
76because of a unified client/miner with only one miner allowed per person, linked anonymously to a
77HUID. Miners are randomly drafted into built-in pools, meaning everyone contributes yet nobody
78dominates. The system provides a workable UNIVERSAL BASIC INCOME (UBI), i.e., it pays users
79to participate, since everyone is drafted to secure the network. It is incredibly energy efficient
80because it does not mine all the time and it is also storage efficient because it uses a Distributed
81Hash Table (DHT) of historical blockchain transactions, allowing it to fit and run on a cell phone.
82Motivation
83A true Direct Democracy (DD) requires representativeless government. The concept is so new that
84the word representativeless does not even exist. We had to invent it. Think of a digital DD as true
85algorithmic government. It holds the potential to unleash the true will of the people, while being a
86natural evolution from current governmental systems. While Direct Democracies have been tried in 
874
88the past, in limited scope, such as in Athens and pre-republic Rome, there was simply no practical
89way to make such a system work with pure analog technology. A Direct Democracy absolutely
90requires mass communication and digitization and it almost certainly requires Artificial Intelligence.
91The inspiration for the idea was two-fold. The first was author Daniel Jeffries' work on The Jasmine
92Wars, an epic sci-fi and military saga in which China becomes the world’s first direct democracy, run
93by a highly advanced, artificially intelligent version of a DAPP platform called Cicada. This led
94Jeffries to wonder what exactly it would take to create such a platform, and whether the technology
95to do so was even feasible. When he conceived of the idea twenty years ago, the answer was
96decidedly "No," but society is now at the stage where it can at least begin to create this technology,
97even if some of the necessary pieces are still evolving.
98The second inspiration came from the Arab Spring. Beginning in Tunisia in Dec 2010, a
99revolutionary wave swept the Arab world as the people rose up and finally managed to throw off
100generations of brutal and oppressive regimes. After the heady and hopeful early days of these
101revolutions, the results were dismally predictable: Tunisia remains unstable and, at the time of
102writing, unable to adopt a constitution. The Egyptians have replaced one military dictatorship with
103another. Syria has devolved into the brutal and horrifying civil war that gave rise to the vicious and
104fanatical ISIS, while creating a refugee crisis that threatens to rip the civilized world apart.
105In other words, people are worse off than when they started.
106This result is sadly the norm throughout history. Even when people manage to peacefully overthrow
107decades of dictatorship, with very, very few exceptions, they wind up with yet another one.
108Communist China is another perfect example. The Chinese people rose up and replaced five
109thousand years of dynastic rule with a dynasty by yet another name: the People's Republic of China,
110a communist "people's dictatorship" that is essentially just a minor evolution of their dynastic system.
111This problem of replacing one bad government with another stems from various organizational and
112systemic issues. After the Egyptian revolution, the only people sufficiently prepared and organized
113enough to gather votes were the Muslim Brotherhood, who had been organizing underground for
114years. More liberal and secular minded parties were left scrambling to make their voice heard. This
115led to the Muslim Brotherhood getting elected with a majority despite their relative unpopularity.
116Once in power, they sought to create a constitution bent to the will of religion. This was no surprise,
117since their primary worldview is that religion should be supreme in governing people's lives.
118People's worldviews directly shape and limit their ability to create solutions. Unfortunately, since the
119Brotherhood's view was not shared by everyone in the system, and they failed to account for and
120give voice to alternative viewpoints, which is the very foundation of a democracy, their swift collapse
121was inevitable. Within a year they were overthrown by the only other organized group: the military.
122So in just three years Egypt wound up right back where it started, trading one military junta with 40
123years of "emergency executive powers" for another military junta masquerading as a democracy. 
1245
125A properly developed Distributed Direct Democracy that runs from everyone's phones and/or the
126personal IoT electronics of tomorrow has the potential to break this cycle forever.
127In its idealized state, a Direct Democracy is self organizing, self-booting, self-replicating system that
128provides, instantiates and automates all functions of government. It is able to sustain itself
129indefinitely, provided sufficient communications infrastructure still exists within the country or
130sufficient client devices still exist to power a mesh network.
131Creating such a platform may take ten years. It will require cutting edge programming, critical
132thinking, and a willingness to solve a string of currently unsolved problems. But the potential
133rewards are vast and manifold, easily making it worth the huge engineering effort required to make it
134a reality.
135If there is one goal for this project, above all others, it is this:
136The next time there is an Arab Spring, the people will be able to replace their leaders with code.
137Defining Distributed Direct Democracy
138Before we dive into the technical details, let's discuss what a Distributed Direct Democracy is and
139why it is even needed?
140To start with, a DD is not another digital democracy initiative that focuses on augmenting or
141streamlining current representative systems of government. A DD is a representativeless
142government, where every idea is voted on by every citizen.
143This, of course, creates a number of new challenges, such as driving voter participation, avoiding
144voter fatigue, and dealing with the average voter's imperfect understanding of essential issues.
145There is also the problem of preventing the system from being overwhelmed by irrelevant,
146impractical, or disingenuous proposals, an issue which plagues existing frameworks such as
147California's ballot primary system or the UK government's petition website.
148A later section addresses many of these issues via automated voting, gamification of voting, and the
149ability to call expert private groups to create fast tracked proposals for complex topics such as
150economics, technology, and the sciences, rather than relying on politicians with no experience or
151meaningful understanding these disciplines. We will also provide a filtration system that dramatically
152limits the amount of proposals presented to the entire nation for voting, ensuring only the cream
153rises to the top.
154In short, we propose creating:
155• Algorithmic government 
1566
157• Representativeless government
158We are also focused on building something that is:
159• Entirely decentralized and serverless, with no central choke points
160Existing projects and initiatives, such as DemocracyOS, Liquid Feedback, and BitCongress, while
161interesting, innovative, and admittedly further along than this project in some respects, are primarily
162about providing an easy way to talk to elected representatives.
163The problem is that those representatives are under no obligation whatsoever to care about that
164feedback.
165And we already have a robust platform for debate and learning about issues. It's called the Internet.
166Representatives are not interested in constant feedback from those they represent. They are
167interested in their own views and agendas, which is why these platforms have seen very limited
168adoption and likely will remain that way.
169A representative system is flawed because representatives don't really have to care what people
170think. They are elected as proxies, not as a direct reflection of the people's ideas and opinions.
171They are there to govern for us. If their views begin to widely diverge from popular opinion, there is
172no patch for that flaw in the system. The people are out of luck, doomed to watch as their
173"representatives" begin to implement policies that work against them, with no way to slow or stop the
174slide. While the United States still remains the standard bearer for democratic success in world
175history, the policy positions of elective representatives significantly diverge from those of the average
176"man on the street." The now famous Princeton Study, which looked at 40 years of lawmaking,
177found that if a policy had a 100% approval rating from the people it had only a 30% chance of
178passing. Conversely if a policy had 0% support it STILL had a 30% chance of passing. These
179divergences are intrinsic to a representative system. Thus any system that looks to provide
180feedback will not change much at all.
181By contrast, a Direct Democracy creates a powerful framework for continuous voting that reflects the
182changing will of the people, exactly as they intend. While there are certainly challenges and
183weaknesses to solve for in this type of system, we believe the system can be crafted in such a way
184that it will be strongly resistant to distortions while providing powerful checks and balances at an
185algorithmic level, making it less prone to subversion when elected representatives decide to erode or
186ignore constitutional and legal checks and balances on their power for personal gain. 
1877
188Technology Introduction
189Making such an audacious idea a reality requires a fundamental rethinking of DAPP platforms.
190While it is possible that Bitcoin and Ethereum, the two major contenders to the DAPP throne, will
191one day be ready to scale the heights needed to securely run an entire nation, that day is not now.
192Bitcoin is almost exclusively focused on the limited use case of creating a cryptocurrency and has
193major scalablity issues that the debate over 2MB or 8MB blocks barely addresses. If the Lighting
194Network project creators' calculations are correct, then 8MB doesn't even come close to solving the
195problem. To grow to a planet scale, Bitcoin will require a radical re-architecture or the successful
196implementation of an off-blockchain payment system, where the blockchain merely functions as a
197dispute mitigator. To put the problem in perspective: if 7 billion people perform 2 transactions a day,
198that alone gives us 24 GB blocks, generating a blockchain of 3.5 TB a day, or 1.27 PB per year.
199Ethereum has different challenges. It is a truly ambitious project, run by a brilliant and visionary
200founder in Vitalik Buterin, and it may yet prove successful and revolutionary in the long run. But
201today it is still in its infancy. Recently Ethereum suffered a major breach because of a security
202vulnerability in its smart contracts, allowing a hacker to steal $60 million in Ether from a
203Decentralized Autonomous Organization (DAO), forcing a hard fork in the blockchain to restore the
204stolen currency. This precipitated a kind of civil war inside the platform, with Ethereum Classic
205maintaining the original blockchain and the official project working off a forked blockchain, a civil war
206that is still raging to this day.
207In truth, Ethereum is really an extension and evolutionary iteration of the ideas of Bitcoin. It was built
208to enable some technology that Bitcoin refused to support, such as a Turing-complete scripting
209language. However, it maintains many of the limitations of Bitcoin, such as its proof of work (POW),
210which is prone to heavy centralization, and its reliance on a wildly fluctuating currency.
211We need a new way of thinking about DAPPs to create the platform that will run the next generation
212of decentralized, autonomous applications and give us the Internet we deserved in the first place,
213instead of the increasingly brittle, insecure, and centrally controlled system we have today.
214There are several crucial technologies necessary to build this new system, each of which will be
215explored in turn.
2161] A HUID generated through the intersection of revocable biometrics and cryptography. Revocable
217biometrics improves biometrics by allowing systems to revoke a biometric token without revoking the
218underlying biometric. This is further improved with the addition of cryptography. By using biometric
219markers (initially utilizing both irises as inputs) to create public/private keypairs, we can generate a
220unique ID for each person on the planet. This ID is not centrally controlled, which will virtually
221eliminate all Sybil attacks, along with the vast majority of problems in peer to peer networks. The 
2228
223HUID also allows for blind signature/zero-knowledge proof sub-IDs that allow role-based access
224control to personally identifiable information (PII).
2252] A peer-to-peer network based on a modified version of the Kademlia protocol. By using a special,
226single-use sub-ID of the HUID to generate the Node IDs in the system, we can prevent Sybil attacks
227and allow for a new PoW system. This special purpose sub-ID has no access to even the basic ID
228numbers of the HUID, and thus provides unlinkablilty and unobservability. This in turn provides the
229kind of capabilities we are already used to in our democracy, such as anonymous voting and the
230principle of one person, one vote.
2313] By linking the HUID to the Node ID, we can then move on to create a powerful new Distributed
232Proof of Work (DPoW) for securing our blockchain. The key is to eliminate the split between client
233and miner that currently exists in all cryptocoin systems. Instead, we unify both client and miner,
234meaning every client is a miner and vice versa. Each person is allowed exactly one miner. To
235secure the system, miners are randomly drafted into built-in mining pools to compete against each
236other. This has the happy benefit of providing a workable and practical Universal Basic Income
237(UBI), since everyone is drafted to secure the network. However, since only a fraction of the
238network is required at any time to secure the network, it remains energy efficient enough to run on a
239cell phone, since expensive and battery-draining operations are not running constantly. In addition,
240this system eradicates the current plague of centralized mining in Bitcoin and other cryptocurrencies,
241where private companies build ASICs secretly and never release them to the public, trading one
242form of centralization (government-sanctioned banks) for another, more pernicious one (private,
243unaccountable, and ultra-secret corporations/organizations).
244 Lastly, we make the platform storage efficient by storing only the most recent transactions in the
245program, likely only the past few months' worth, and then shard up the historical blockchain via a
246Distributed Hash Table (DHT), which is then redundantly distributed to all miner/client participants so
247that it can fit on any tiny device.
248We will also outline other technologies specific to the functioning of the DDD and the underlying
249DAPP platform. But before diving into each of these fundamental building blocks in detail, let's take a
250quick look at the design philosophy behind those ideas to understand why they matter and why they
251are necessary.
252Philosophy of the Project
253Our philosophy is simple:
254There is always a solution.
2559
256Just because a problem is challenging or people have not previously discovered a solution, does not
257mean no such solution exists. It means the problem is not being looked at correctly.
258In order to create solutions for as-yet-unsolved problems, we do the following:
259• First, we identify ideal characteristics for the system.
260• Next, we develop a solution that meets all of these criteria. Solutions with known flaws are
261not acceptable unless those flaws are mitigated completely or extensively minimized.
262• We then create these solutions by taking an interdisciplinary approach, uniting ideas from
263multiple areas of human knowledge, taking inspiration from seemingly disconnected fields.
264But no field is truly disconnected. Separateness is an illusion. All things in the known
265universe share similar patterns, and when studied together, offer insight into difficult or
266seemingly impossible problems.
267Many people and teams are prone to saying "there is no solution to that problem" and then
268defaulting to known, flawed solutions. This is nothing but lazy thinking and unacceptable in the
269Cicada project. An example is using "trusted" central authorities, a system with extensive flaws and
270known weaknesses. Reliance on central trust doomed attempts to create digital currencies, such as
271e-gold, before Bitcoin solved the problem of decentralized trust and consensus.
272Where possible, we favor the following characteristics for our system, with any deviations
273needing to offer significant benefits:
274• No single organization, business, or person can control or alter the system without extensive
275consensus
276• Completely decentralized and distributed
277o Reliant on no centralized trusted entity for its core functions
278
 However, it is worth noting that pluggable modules, outside of the basic
279infrastructure plumbing of the system, may be open to relying on the services
280of centralized entities for highly specific functions, such as current web APIs
281• Privacy and the right of a person to be in control of their personally identifying information
282• Openness
283o In methodology, source code, protocols and security measures, upgradeability
284• Security of the system based on emerging "trusted computing" practices
285o Though the term "trusted computing" is controversial because of its use by
286corporations to limit what users can do with their personally owned systems, in this
287case the power of the concept will be inverted and used to return the power to the
288individual. Its ideas will be leveraged to protect the user and the system from
289malware and centralized attempts to subvert the platform.
290• Strongly resistant to coercion and subversion 
29110
292• Usability/Simplicity
293o Easily adoptable by a broad group of people with no technical skill to advanced
294technical skills.
295• As much of the technology we propose relies on encryption, we stand absolutely against key
296escrow or weakening of cryptography in any form. Ultimately, this is the only true threat to
297the system
298• End-to-end verifiable and auditable
299• Resistant to hostile actors
300If a proposed solution fails to solve for any of these principles, it is inadequate and to be discarded
301swiftly.
302The philosophy behind a project directly corresponds to the code that is created. Starting with an
303incorrect perspective leads to broken results that do not serve all the people in a system. The
304philosophy of this project is to build an "agnostic" or "universal" system. To serve as many people
305as possible it must be agnostic and immune to attempts to take control of it and force a particular
306worldview or agenda on it.
307The history of the world is a battle of ideologies. Each of those ideologies believes that if they could
308just gain complete control, everyone would be happy. Nothing could be further from the truth. There
309is literally no way for a single worldview, be it capitalism, socialism, communism, or any other "ism,"
310to satisfy all the people all the time. If the system is not agnostic, in that it serves the needs of
311everyone, it serves no one, and it will not be widely adopted. To be agnostic it must be open and
312unlimited in its use, fostering competition among ideas, with a system of underlying checks and
313balances that keep it all organized and operating fairly.
314Many of these core principles will create unique challenges. Some of the principles seem at odds
315with each other, making it hard to solve for all of them at once. When people design a system with
316such challenges, they run across hard or seemingly intractable problems. This often leads them to
317compromise. For instance, in voting systems, strong identity management and anonymity seem to
318be starkly opposed. As such, the architects often decide one of these principles must fall by the
319wayside. This leads to flawed and broken platforms that do not meet the needs of all the actors in
320the system. For example, Democracy OS "simply does away with secret ballots." For this project,
321that stance is unacceptable. It indicates that the designers did not iterate enough through the
322challenges to come up with a truly revolutionary concept, instead settling for a partial solution.
323Partial solutions are no solutions at all.
324Many problems seem totally unsolvable. This happens when systems are required to have traits
325that are in seeming opposition to one another. For example, before Satoshi Nakamoto created 
32611
327Bitcoin, all systems were believed to be subject to Zooko's triangle, which states that systems cannot
328have the following three characteristics simultaneously:
329• Human meaningful
330• Decentralized
331• Secure
332Before Bitcoin, people were able to solve for two of those properties but not all three.
333Before Roger Bannister broke the four-minute mile in 1954, it was thought to be physically
334impossible. After he broke it, multiple people were able to break it in short order, simply because
335they now realized it was possible. They now had the correct frame of reference to actually achieve
336their goal. When we assume that something is impossible, we start with an incorrect framework for
337solving hard problems. We are starting at a deficit. It often takes one person to prove something is
338possible to enlarge the problem domain.
339Unfortunately, solving a previously unsolvable problem tends to lead to a new problem that we call
340the "Satoshi box." We often jump out of one box, right into a slightly bigger box. People quickly
341adopt the solution, but are unable to think outside the framework it provides. Instead of finding
342additional solutions to the challenge, they iterate on the same solution over and over, even when it is
343not appropriate. We have seen this with almost every other cryptocoin to come after Bitcoin. With a
344few notable exceptions, all of them are but tiny variations on the same idea, with little to no
345divergence or original thinking.
346This project will require both building on the past and completely new and undiscovered solutions. It
347requires big-picture, ambitious thinking.
348Tiny iterations are not enough.
349Finally, it is also the position of this project that this technology is inevitable. Either we create it
350ourselves, or someone/something will do it for us and we will not like the results. Likely any
351centralized creation along these lines will end up being a highly partisan, privacy destroying,
352repressive, insecure and broken machine that enslaves us rather than sets us free. It's as simple as
353that. We can’t let that happen. They way to stop it is to get ahead of it now.
354Already banks and foreign governments are creating huge, weakly secure, non-revocable biometric
355identification systems in centralized databases that we have no control over. Companies
356like GenKey are already working with the Indian government to create universal IDs for billions of
357people, using a proprietary, copyrighted algorithm that people have no insight into whatsoever.
358These systems should be replaced with universally vetted, secured, and openly designed systems.
359We simply can't allow this to be a private, closed system locked away from public scrutiny. 
36012
361It must be open source, and it must run on a blockchain, to ensure no single entity controls it.
362Why? Because, human history has demonstrated again and again that centralized trust is an
363oxymoron.
364If we allow private companies or current governments to create this technology, you won't know
365where or how it is stored, what info is stored with it, whether the proprietary algorithms used to
366create it are any good, or even if it's really secure at all. You won't know most of this until it is
367inevitably hacked and all of your personal data spills out onto the nets, including your iris or
368fingerprint template or your DNA, which is now useless as an ID because you can't take it back or
369change it.
370Architecture
371In this section we discuss the high level architecture of the system.
372First, let's list the primary components of a DDD:
373Key Parts of the System
374• Human Unique Identifier (HUID)
375o Controllable by the user
376o Not stored in a centralized database of any kind
377o Deeply resistant to coercion and corruption
378o Nearly impossible to duplicate or steal
379• Organizational IDs
380• Organizational and personal RBAC
381• Decentralized DNS such as the system designed by Blockstack
382• End-to-End Verifiable Voting framework
383• Groups
384• Routing protocol
385o Based on next-gen Kademlia distributed hash table design for P2P networks
386
 Relies on the HUID to prevent Sybil attacks and uses a genetic learned trust
387algorithm among peers for routing and reliability ratings of nodes and peers
388• P2P fully encrypted communication system
389• Law framework encompassing:
390o Parsable XML based law
391o Proposal and initiative system
392• Smart contracts 
39313
394• Participant and Group Entity Reputation system
395• Decentralized Message Bus
396• Distributed code repository
397• Distributed Proof of Work (DPoW)
398• AI/Machine Learning/Deep Learning system (Potentially as the tech develops to work on less
399powerful chips)
400o An AI system would be used for
401
 Auto-vote casting
402
 Arbitration
403
 Simplifying voting descriptions
404
 Improving voting gamification
405
 Budget distribution and analysis
406Cryptography Technologies
407• Zero-Knowledge Proofs
408• Multi-signature transactions
409• Blind Signatures
410• Mixnets
411• Public/private keys
412• One way, non-invertible hash functions
413Abstracts/Primitives of the System
414Before discussing each of these components in turn, let's look at some metapatterns of the platform.
415The protocols designed for such a system would have broad applicability to a huge number of other
416types of systems, not just voting/government. Therefore, it is best to outline these protocols in
417generic, reusable terms so they can function as a complete DAPP platform.
418We are creating a method to define social interactions at the planetary scale. Social interactions are
419links between various groups or individuals. Think of these groups as a series of spheres connected
420by strings. A society is nothing but a huge sphere encompassing smaller spheres, like states,
421counties, cities, companies, local clubs, volunteer groups, reading groups, movie lovers meetups,
422and sewing circles. Humans voluntarily form and drop out of spheres all the time. The interactions
423between those groups are nothing but a series of social protocols. A society is nothing more than a
424series of implicit protocols for how we organize, connect, agree, and disagree. Agreement and
425disagreement, connecting and severing ties are transactions in the system of human experience. 
42614
427Think of this system as a human interaction modeling platform. These are what we refer to as
428"grouping primitives."
429While the project starts off as a direct democracy engine, a democracy is merely a subset use case
430of these abstracts/primitives. It should be noted that the direct democracy engine is a particularly
431unique use case, and as such will have some abstracts designed specifically for its use (e.g., action
432tokens and unlinkability to prevent vote tracking).
433The system is also completely scalable. A local charity or social club could limit their sphere of votes
434to members of that group. This would allow the platform to work for everything from a gamers' hub
435to a nation state.
436The system rests on the back of an open, totally decentralized universal ID system that uniquely
437identifies every human on the planet, is highly resistant to compromise and coercion, and is not
438controlled by any single corporate, group, or government entity. And yet those corporate and
439government and group entities can consume the ID system to attach an individual to their sphere or
440organization. However, the ID might be a unique sub-ID that simply grants limited access to only a
441subset of the what the very human owner of that ID wants them to see.
442For example, Nielsen may want to make you a member of their rating team and they might want
443access to a subset of data that you have stored in a PII database or Info Wallet, which is described
444in detail later. You might generate a sub-ID that is cryptographically linked to your primary ID, but
445that only gives them access to a small subset of those interests.
446We are looking to model every aspect of how humans interact and form bonds. How do they
447exchange value, do business, put forth ideas, create laws, enforce laws, join groups, leave groups,
448agree, disagree? 
44915
450Individual Component Outlines
451Here we outline the various critical foundations of the system. They form the framework for
452constructing the specific use case of a distributed voting system, but they can be used to govern
453many, many types of human interactions, such as joining or leaving a company, creating a
454decentralized autonomous organization (DAO), ensuring trusted computing, and decentralizing
455privacy, to name but a few.
456Human Unique Identifier - HUID/SID/SIN
457We have already broadly discussed the HUID, but this section will dive into it in detail.
458The "Human Unique Identifier" (HUID) or "Single Identifier" or "Secure Identity Number" is an
459ID unique to each human on the planet. This allows us to prevent Sybil attacks and ensure
460everyone has a voice in the system. The HUID must be unique, incontrovertible, incorruptible,
461and not centrally stored or administered.
46216
463The system's integrity rests on this ID, so it must be the most well-designed part of the
464system. No previous ID effort is an acceptable stand-in here. As such, consider this only the most
465basic framework for such a system.
466The HUID uses biometric markers to create public/private key pairs, guarded by passwords,
467which in turn are used to create IDs and linked sub-IDs. To be very clear, what we are talking
468about here is biocryptics NOT biometrics. Biocryptics are the intersection of biometrics and
469cryptography. Biocryptics holds the promise of solving for all of the problems that biometric
470systems create.
471Traditional, non-revocable biometrics has a long history of insecurity and compromise. In
472the general public they often incite fear and uncertainty, a fear and uncertainty that is
473justified. However, in the past five to ten years, cutting edge researchers have spent
474countless hours considering revocable biometrics, biometric security, and using biometrics
475in combination with cryptography to create strong ID systems that mitigate the flaws of earlier
476systems.
477Biocryptics will be the focus of this system, as there is currently no better methodology to create a
478universal identifier than to start with the markers that make us all unique: our biology. The primary
479difference between biometrics and biocryptics is that biomarkers, such as fingerprints, irises, retinas,
480DNA, and/or spectrometer readings, are used as inputs to cryptographic key functions.
481There may still be hidden flaws in the implementation of this idea that will come out as other
482researchers consider it. Nevertheless, even if the specific parameters outlined here are found to be
483flawed or incorrect in some way, the underlying idea of creating a unique ID for each person, linked
484to their biometric markers, remains crucial and foundational to the system, and designers should
485look to iterate until they have found a perfect one with no known weaknesses.
486To start with, the Cicada project will focus on using double-eye iris scans as the foundation
487of its identity system. Iris scans appear to be the best current candidate for the HUID, because
488they are fast, reliable, and have a very low false positive rate. With the release of the Samsung
489Galaxy 7, despite its issues of blowing up, which we expect to be resolved, the technology is about
490to become widely available, and may eventually become a standard feature of end user devices.
491Unlike retina scans, iris scans don't require you to be too close to the scanner. Lastly, because the
492scan can be done from a distance, it makes it easy to identify both eyes at once. This is an essential
493feature, as we want to keep people from making multiple IDs for themselves.
494However, just because we have outlined the prototype system with iris scans does not mean this is
495the only possible solution or that better ones will not come along in the future. The system should be
496pluggable and allow for upgrades/replacements/sunsetting as the technology develops along these
497lines. DNA holds the strongest possibility as a perfect ID system, considering that the problem 
49817
499of telling twins apart is now largely considered solved. Unfortunately, DNA testing at the time of
500writing still involves taking blood or saliva and sending it off to an external lab, which makes it
501vulnerable to numerous layers of compromise. In the future, we foresee systems, such as a watch
502or bracelet, that can extract imperceptible amounts of blood and synthesize that DNA without the
503data ever leaving your wrist. At that time the technology will be reconsidered.
504The HUID is created by generating a public/private key pair from an iris scan and storing that
505ID in an identity blockchain, known as the HUID chain.
506The HUID has the special advantage of being largely immune or at least incredibly resistant to Sybil
507attacks, because it is unique to each person and cannot be reused in the system. This is an
508essential trait for a system where one person, one vote applies.
509To create the public/private key pair, we scan for biometric markers known as "minutiae points."
510We identify these critical minutiae points to create a "template" of the points, convert them into a
511hash, and use them as seeds for a pseudo-random number generator to create a public/private
512key pair, along with salt to create additional randomness.
513This public private/key pair will then be used to create an "info wallet." This is similar to a
514bitcoin wallet, but used for storing personally identifiable information (PII). The public key is
515run through a function to create a unique numerical ID for a person.
516The public/private key pair will include a built-in requirement to create a strong password,
517utilizing a rainbow table of prohibited weak passwords, enforced by the blockchain, to ensure
518good security practices. A password is necessary to prevent coercion, as a person could be
519forced to use their biometric markers to do something they don't want to do, such as unlock a phone.
520Without a password, that phone simply unlocks.
521It is also possible for a user to create a "coercion password" that can be used if they are threatened
522or under duress. This password would appear to perform all the actions requested by the attacker
523but allow them to be rolled back at a later time. This creates some problems, as it could be used to
524scam legitimate transactions in a system, so this will not be considered in the rest of this paper.
525However, it should be addressed at a later design stage.
526The system will also include a blockchain-driven challenge/response system for resetting
527passwords, re-enrolling keys, or changing keys, which marks old keys as
528blacklisted/unusable. People forget passwords. With no friendly web company to reset it for you,
529there must be a secure, powerful, decentralized method built into the protocol to make it easy for
530people to do this without compromising overall security.
531To secure the template, yet prevent repeated use of the biometric signature, we delete random
532sections of the data and store it in a different biohash/fingerprint blockchain that is not linked to the 
53318
534HUID chain in any way. To do this we use a "Blockchain of Blockchain" approach, as outlined later
535in the paper. By deleting random chunks of the template, we can use that data to check if a person
536is already enrolled, but not simply take that template and attempt to create a new key.
537It's critical to note that a number of template security protocols for revocable biometrics have been
538defined in recent years, and this method may not be ideal. For the purposes of this paper it is
539considered at best a working design. It is also possible to consider homomorphic encryption for the
540template, a method where data is encrypted and never decrypted as part of the verification process.
541Homomorphic encryption is undergoing extensive R&D currently and may prove the best method in
542the future for securing biohash templates.
543The design of the system also allows for the creation of various special purpose (used for one
544purpose only once) and non-special purpose (used for anything) sub-IDs linked to the primary ID,
545which will be outlined in the next section.
546The protocol must (eventually, though not in the initial POC design) allow for alternative biometric
547markers as a backup, should a person have only one eye or none. This creates unique and difficult
548challenges in that it allows for various attacks by using Hollywood style makeup, which could allow a
549user to attempt to create two IDs. These will not be discussed in great detail, however. There are
550also other potential attacks on the system such as constructing fake eyes, but these may be
551mitigated by "liveness tests and/or anti-spoofing tests" and will require further considerations,
552perhaps requiring a user to show their face and wave their hands, etc., as well as various fuzzy logic
553and reputation-based algorithmic defenses. Since we are also building a legal framework, we may
554choose to empower a government organization with the power to repudiate or test biometric markers
555in court.
556We will sidestep these limited scope attacks for now and assume there are sufficient defenses
557against them, since researchers have been addressing these type of techniques for years. Our
558concentration is on making a robust ID system that utilizes both eyes.
559A private, bonded, proof of stake agency may be the key to allowing alternative biomarkers as an
560option in the future, which can verify that a person is missing the required biometric markers and
561issue a one-time code to create an alternative ID based on different biometric markers. However,
562other biometric markers have a number of problematic characteristics. For example, a person's
563fingers can be swollen, cut, damaged, sweaty, etc, all of which creates variance, which in turn
564creates different inputs and hence different keys. In addition, all of a person's fingerprints would
565need to be entered to prevent multiple IDs being created, which is cumbersome and time
566consuming.
567For the time being, we will simply say that the system may choose to allow for additional and/or
568replacement biometric markers to provide weight and "reputation" to the original ID or to replace a 
56919
570non-recoverable or stolen ID by flagging a lost ID as permanently blacklisted. Candidates for
571secondary biomarkers include, but are not limited to:
572• Voiceprint
573• Retinas
574• DNA
575• Palm prints
576• Fingerprints
577Again, all of these present special problems and will not be considered further here, although they
578may be addressed by the project at a later time as good solutions become available through
579research and development.
580Diagram of Proposed Iris Enrollment/Creation Procedure
58120
582Outline of Proposed Steps for
583Enrollment in the System
5841. Enrollment software boots an encrypted microkernel that checks for live network connectivity
585through a series of tests, using randomly generated secret information, challenge/response,
586pings, time checks against the blockchain, and TLS-connected NTP servers
5872. After ensuring network connectivity, the microkernel checks the software blockchain to
588ensure its binary hash matches, as well as the correct, current protocol version, and any
589other checks deemed necessary to ensure the system is running the latest, unmodified code 
59021
5913. If a pair of Irises is already enrolled, the system should check the user's password with
592challenge/response and refuse to boot if the password is incorrect after a series of n failures
5934. Should any of these checks fail, the system should refuse to boot
5945. System boots and is ready to scan the irises
5956. Irises are lined up and scanned
5967. Additional anti-spoofing tests are conducted
5978. The protocol enhances the raw image through filters
5989. Critical unique "minutiae" points are extracted
59910. The center or core point of the image and its corresponding radii are identified
60011. The type, angle and position for each minutiae point with respect to this coordinate system
601are calculated
60212. The entire iris print configuration is mapped into a string of bits known as a biohash
60313. The biohash is tested against the Biohash blockchain to check whether it already exists, to
604prevent double enrollment
605a. If the biohash does not exist:
606i. Random bits of the biohash are deleted. Homomorphic double encryption
607techniques may be used to create a secure biohash iris (SBIOH-I)
608ii. The SBIOH-I is projected into the biohash blockchain
609iii. HUID creation begins
610i. The user is prompted to create a password, using a rainbow table
611blacklist to prevent easily guessable passes and enforce password
612complexity
613ii. The user is also (potentially) prompted for a secondary "coercion
614resistance" password, which can be given in the event of violence
615against the individual and which gives the appearance of having reset
616the ID, but which silently discards the new data
617iii. A random set of challenge questions for resetting the ID and
618password is also generated
619iv. Answers and a one-way, non-invertible hash of the password are stored with
620the biohash in the biohash blockchain
621v. The biohash is used to seed a PRNG, which in turn is used to generate a
622main public/private key pair (PUBID,PRIVID)
623vi. An "info wallet" is created for local storage of keys
624vii. The public ID is created from a secondary hash function against the public
625key, just as with Bitcoin. The PUBID is NOT the HUID.
626viii. The public key and HUID are projected into the HUID blockchain, separate
627from the biohash blockchain.
628b. If the biohash already exist in the biohash blockchain
62922
630 . The user is asked whether they are attempting to reset or recover their
631biohash
632 . IF NO
633i. End
634i. If YES:
635 . Start reset process
636i. Prompt for password
637 . IF COERCION PASSWORD RECEIVED:
6381. Silently discard updates but provide identical
639messages and confirmations to the users to ensure
640their safety in the face of an attack
641ii. IF RESET PASSWORD RECEIVED
642 . Allow new biohash data to be projected into the biohash blockchain
643and start the process of generating and replacing a new public/private
644key
645 . Do not delete old biohash data, simply add the new data to a
646new spot in the chain and set to flag any bit that labels
647previous biometric data as obsolete/defunct
648i. RETURN TO NEW ENROLLMENT PROCEDURE
649Use of the HUID in the System
650The HUID is immutable to the individual and cannot be changed. It is unique, even in twins. It can
651be augmented or potentially replaced with additional biometric markers such as voiceprints,
652spectrum readings, DNA hashing, iris scans, and the like, which would add additional "weight" or
653"reputation" to the initial ID as the ID is used over time, as a backup for proving ownership. As
654defined by this system it can even be resilient to changing characteristics such as age or scarring.
655The HUID underpins the system and allows arbitrary capabilities to be tied to the HUID, through
656linking to additional tokens or capabilities, without being reliant on a central authority to secure an
657unsecurable number such as an SSN, which must be given to those authorities. This creates a
658weakness whereby any compromise of that authority is a compromise of the number itself.
659The HUID allows for a 1-to-1 voting token to be assigned to a person and rights and capabilities to
660be assigned to an HUID, such as the rights and protections of citizenship in a particular country or
661the rights of an individual in a company or collective/co-operative. 
66223
663In the Direct Democracy system, a voting token is taken from an anonymous pool of voting tokens
664and assigned temporarily each time the citizen votes. This token is then routed through a
665decentralized mix-net and released, preserving voter anonymity. The token is assigned on a one-toone basis to the anonymous voting sub-ID linked to the HUID. The voting right represented by this
666token can be taken by a centralized law body, or automated law entity, but the ID itself remains with
667the individual indefinitely and cannot be taken or corrupted. The voting token is separate and
668associated on a 1:1 basis with the HUID.
669Some research into using biometrics for cryptography allow for the deletion of the private key, which
670prevents it from needing to be stored by the end user and keeps it from being compromised. This
671method does create some challenges though in that it likely removes the essential password
672component and requires the person to continually scan their biometrics to use it. While this method
673holds some promise, unless an answer to the password problem is discovered it is likely
674unworkable. However, if it is feasible, and an attacker does manage to spoof the system, then they
675will not be able to do it for long, as only the person with the actual biomarker that made the HUID
676can prove their right to that HUID in court. This will virtually eliminate fraud.
677Sub/IDs
678A crucial component to the privacy of the system is that it allows the creation of sub-IDs. These
679sub-IDs (SIDs), linked to a HUID/SID, enable people to join or leave a group. They could be an
680ID that marks you as a citizen or an employee or as one of the Nielson raters, or as a game player in
681a MMORP. These sub-IDs also provide anonymization or unlinkability through blind
682signatures and/or zero-knowledge proofs. The signature is a single piece of secret data that
683can prove that someone's primary ID is linked to the sub-ID without revealing the primary ID.
684The sub-IDs should also allow for RBAC (role-based access control) to personal data. For
685example, a sub-ID may grant access to only a phone number, name, and email address but not an
686HUID or SSN. The sub-IDs can also be generated with zero privileges, allowing access to none of
687the user's information, but still allowing the user's identity to be verified via an embedded secret that
688can be verified via challenge/response. So an application could demand that a user prove who they
689say they are and the client could then reveal that they know the secret information via a prompt,
690proving their identity but not revealing their PII. The system may also choose to use non-interactive
691zero-knowledge proofs (NIZK), which prove ownership/identity without even having to prompt the
692user depending on the needed security of the use case involved.
693The system will also require single-use sub-IDs (SUSIDs). For example, to link an HUID to a
694NodeID (which IDs a client to the network) while simultaneously protecting the identity of the
695user and preventing that user from creating multiple nodes for themselves, we create a 
69624
697protocol for single use sub-IDs that, once generated, cannot be generated again without
698revoking the original HUID and banning the original NodeID on the network, rendering the
699client unusable. A flag is set in the HUID blockchain that this single-purpose sub-ID slot is filled
700with a Boolean yes/no. If the flag is marked "no," the program will not allow the creation of a new
701sub-ID. In the event of compromise, the sub-ID can be deleted and generated again. This sub-ID
702presents some serious design challenges and the authors may not have worked out all major attacks
703against it, but the general concept should allow for solving the unique ID + anonymity problem if all
704attacks are considered carefully and appropriate countermeasures are created from the beginning.
705RBAC sub-IDs have the potential to revolutionize our current, overly centralized, and brittle system
706of keeping everyone's PII on web servers and private databases for verification purposes. Our
707current system of information security is a house of cards. In order to prove that you are who you
708say you are, an entity such as a bank or a website has to keep lots of data on you. They have to
709keep that data secure and you have to trust that they can keep it secure. And your information is
710just a speck in the data they have to store, so they become a target-rich environment for attackers,
711be they individual hackers or a nation state. Why rob one man on the street when you can rob a
712bank? This is why we see major data breaches in the news virtually every day.
713Anyone who has worked in the field of IT for any length of time knows a dirty secret: it's virtual
714impossible to keep an IT environment entirely secure, even when you have massive amounts of
715capital and human resources and a culture that respects security. Very few entities are Google or
716VISA, with the ability to effectively manage all of their systems. The chances of most big companies
717securing everyone’s data are essentially zero. Modern systems are too complex, with too much
718code and too many variables, be they people or systems. The solution to this is not better
719security for central stores of data. The real solution is simple: Don’t store that data centrally
720in the first place.
721Organizational Identities
722The system also uses identities for "spheres" or groups within the system, borrowing the
723concept of "compound identities" from the paper Decentralizing Privacy: Using Blockchain to
724Protect Personal Data. It assigns a single general purpose ID to an entity, such as country, state,
725company, local sewing circle, etc.
726Each organization would have its own public and private keys, its Organizational ID made from a
727hash of the public key, as well as its own signatures for message transmission, as will be described
728in the Networking section. An organizational structure might require Multisignature Keys for specific
729types of transactions, such as access to the corporation's various cryptocurrency wallets. Additional 
73025
731actions may require the fulfillment of smart contract rules in order to complete a transaction, such as
732transferring shares of ownership between members in a corporation.
733Those entities can then create provable but unlinkable RBAC sub-IDs, just as individuals can, for
734individual parts of an entity, such as a department or individual set of employees or for transacting
735privately with other businesses or other organizations in a private fashion.
736Administrators are linked to organizational spheres. They control who can join or access certain
737spheres and their functions and privileges. Joining a sphere may be manual or automatic. For
738instance, an automatic system might require you to pass a test or provide proof of some particular bit
739of ownership, knowledge of a passphrase, or maybe even simple geolocation data over time to
740prove you exist in a specific area. This is discussed later in the creation of citizenship tests that can
741automatically grant people rights within a nation state.
742For smaller spheres, such as a club or corporate entity, administrators can be designated during and
743after the entity's creation. Sub-IDs or HUIDs are granted access over the various functions of that
744sphere, which allows administrators to control who can and cannot join.
745For example, a private comic book collecting group might have a simple structure whereby the
746creator of the sphere designates himself and a second ID as the administrators with "yes" or "no"
747access when a HUID or sub-ID requests to join. They may also have additional capabilities, such as
748the power to grant voting rights or take them away.
749A company might have a more complex governing RBAC structure. The initial creation of the
750structure might designate board members or founding members as admins, with varying tiers of
751power, and give them the rights to grant administrator rights to other employees, such as HR staff.
752The admins would bring on or terminate employees through their administration console. Admins
753can also use that power to grant rights to various employee HUIDs, such as stock allocations,
754percentage of voting rights in the organization, pay tiers, access to various systems/documents/data,
755access to VPNS, and other day-to-day rights and privileges of company employees.
756Backup keys or universal keys to ownership of an organizational entity can be held in a smart
757contract that has rules to follow in the event that no more administrators are available, critical
758employees are terminated, or ownership is transferred. Careful analysis of the design of such a
759framework will need to be carried out during the project's design session so there is a simple,
760reusable methodology that can be adopted by other organizations.
761The organizational templates should be stackable, or able to draw from various baseline templates
762in a layered fashion, making the drag-and-drop creation of new entities easy. The rulesets governing
763such a template could be hierarchical, with custom rules at the top overriding generic language at a
764lower level. 
76526
766Even more complicated organizations like a nation state might have designated trust groups that can
767grant or remove rights from its citizens, such as for violations of the law. A nation-state
768organizational entity might have the power to rescind voting rights under specific circumstances or to
769reinstate those rights, which would set flags in the blockchain that allow or disallow certain actions.
770Info Wallets
771Info wallets are encrypted private information stores that are held offline. This information wallet
772might store personal details which can be selectively shared with an organization or not,
773based on their sub-IDs, which can grant role-based access control to personally identifiable
774information (PII) OR the individual can share proof that they own a particular piece of data
775WITHOUT sharing that data through a blind signature and/or zero-knowledge proof. This
776allows for strong security in that centralized entities no longer have to keep vast troves of personally
777identifiable information. They can be backed up and additionally secured as necessary. A great deal
778of clever thinking on Bitcoin wallet security will benefit this effort as well. It seems that every day
779people are coming up with easy to manage Bitcoin wallets from hardware wallets to brain
780wallets that harken back to the cyberpunk masters of yore.
781Distributing the PII back to the individual forces attackers to attack millions of small areas instead of
782a large, target-rich environment. Web companies and other centralized entities will no longer have
783information on site to steal.
784Blockchain/Distributed Ledger
785A central ledger is a blockchain, such as Hyperledger, Bitcoin's blockchain, or Ethereum's
786blockchain, which is similar to hashchain technology but has several unique properties. Whereas a
787hashchain is a method of consensus among parties that already know and trust each other, a
788blockchain is a distributed cryptographic chain of record in a system that is used by
789untrusted entities to form agreement. A hashchain requires that everyone generally trust each
790other, such as a local charity group that wishes to vote on where to have their next party. A
791blockchain is a trust machine, to be used as a way to drive consensus between parties that
792may not always see eye-to-eye. Parties in the transactions may be friends, rivals, enemies,
793but the chain acts as a way to govern the protocol of their interaction. In essence it acts as a
794trust mitigator in the event of a dispute. Nodes in a blockchain decide on consensus for canonical
795transactions to the system. Transactions may be conducted off-chain such as outlined by the
796Lightning Networks, a cascading, time-locked smart contract system, with the chain acting as an 
79727
798arbiter of disputes. The system will utilize multiple blockchains, with a primary "blockchain of
799blockchains" with pointers to smaller chains that can be archived for retrieval later.
800Blockchain of Blockchains
801This project uses a central, established blockchain as a source of truth to store pointers to other
802blockchains. This could be a custom blockchain crafted for this project alone. It could be built upon
803the rapidly expanding codebase of an existing project such as Hyperledger or Ethereum. Or it might
804simply take advantage of extra fields for general purpose data stores, such as in Namecoin.
805It is likely that the best bet for the project however is a custom chain as it will not be dependent on
806the critical weakness of existing chains which the authors call the "chicken or egg problem" which is
807that a person needs to have cryptcoin to use these blockchains. To use the existing ledgers, you
808have to acquire currency in that system. That is the major limiting factor. Perhaps you simply want to
809build a voting application on Ethereum?
810Unfortunately that requires you to acquire Ether, and everyone needs to pay to vote, even if it is
811some nominal fee. Since these currencies fluctuate so often, you may pay a tiny amount one day
812and then a lot the next. Even worse, you may run out of ether and not be able to vote. For the
813purposes of a nation running itself that makes zero sense. Some things must inherently be free.
814This project differentiates monetary actions and simple actions, which spend non-currency based
815action tokens, as detailed later in the paper. This allows for actions on the system that should never
816cost money, such as voting, while still allowing commerce-based transactions as well.
817The use of multiple chains allows for the atomization of types of data, such as ID data in one chain,
818distributed DNS in another chain, software date stamps, and hashes in yet another chain to facilitate
819trusted computing.
820The outline of the blockchain of blockchains (BoB) is below. Since the BoB is storing only pointer
821data to other blockchains, it can be incredibly compact and space efficient. Chains with specific
822purposes can be pulled into memory as needed and discarded after a time of no use.
823Most importantly, the BoB can be made secure with a new proof of work, detailed in the next section,
824that may prove to be the most import creation of this project. 
82528
826Distributed Proof of Work
827The creation of the HUID allows us to build a new type of Proof of Work, called a Distributed
828Proof of Work, as outlined earlier and elaborated on here.
829Consensus is a method for determining agreement among the various nodes about which
830transactions are stored in the blockchain. The current consensus methods in use today are the Proof
831of Work (PoW) and Proof of Stake (PoS). While some other semi-novel concepts about how to
832secure the blockchain and create consensus have emerged, none of them have been able to
833dislodge these two primary methodologies.
834Current Proof of Work systems have one serious problem: they almost inevitably end up as
835centralized systems. As mining becomes more and more competitive, it creates a moat around
836entrenched players, making it ever harder to raise the capital necessary to compete against them.
837This is similar to corporations today. Once you become Coca Cola, it is very difficult for new
838companies to rise up and create a competing soft drink to dislodge it. This leaves us right back
839where we were with current monetary and social systems, with central players controlling
840and manipulating the flow of money and ideas indefinitely, leading to eventual collusion and
84150% problems.
842This project's answer is a novel Proof of Work proposal called the "Distributed Proof of
843Work" (DPoW). It takes advantage of the HUID/SIN identifier to create a new kind of 1-to-1 client
844and node. Every node is both a client and a mining server. In most instances this will be a
845person's desktop or phone with current technology levels and additional unspecified 
84629
847computing devices of the future such as AR glasses or smart clothing. Nobody is allowed to
848have more than one mining server. It is limited by their primary HUID which prevents Sybil
849attacks on the network and creates a level playing field for everyone. Additional Sub-IDs are
850not allowed to create new client/servers.
851This 1-to-1 ratio makes the protocol essentially evenly distributed forever, with no one pool of
852servers or people controlling the power of the platform. This essentially eliminates the 50%
853problem. It also has the added benefit of creating a built-in Universal Basic Income (UBI) as a
854reward for participation in the system.
855How does it work? It builds on the idea of the distributed hash table of the Kademlia P2P network,
856popularized by 3rd gen P2P systems like BitTorrent. Each client/server is assigned a NodeID stored
857in the distributed hash table of all systems on the network. Now lets take something like the Bitcoin
858system, which updates its blockchain every 10 minutes with a new block, which we will call the
859"block epoch." During those 10 minutes, transactions are broadcast to the network and miners
860gather them up into Merkle Trees and then compete against each to to solve a Proof of Work
861problem to win and release newly created coins and collect all the transaction fees from the last
862block epoch.
863In the DPoW, miner nodes are elected randomly at the start of a block epoch for later blocks
864from the node IDs of the Kademlia style hash table. They are sent a randomized code that they
865will need to respond to correctly to acknowledge they exist within a set period of time. In order to
866avoid a scramble at the beginning of each block epoch, nodes are elected in advance for an as-yetundecided amount of blocks, perhaps six. If nodes are offline and do not respond, additional
867nodes are selected until they reach X percentage of the network. A pool of backup nodes is
868designated as nodes are expected to go offline during the process and diminish their pools.
869This will allow new entities to be swapped in as needed.
870The nodes are then grouped into random mining pools, similar to a built-in version of the
871distributed mining pools popular with Bitcoin private miners today. The PoW is then distributed
872to the various head nodes, also randomly selected, to distribute to their mining pools. The head
873nodes that hand out the random shards of the PoW and collect them to win coin are randomly
874clustered, and given a checksum to validate that another head node is not cheating. They all check
875each others' work so that no one node can simply go rogue and alter the transactions or attempt to
876cheat the others in the pool. The different mining pools elected compete against each other to win
877coins and transaction fees in whatever monetary system is built into the platform, be that Ether,
878Bitcoin, or some 3.0 currency created specifically for this platform.
879As miners are called to the network, they are checked against the standard verifiable
880computing practices, such as that the binaries match hashes in the Software Blockchain, that
881the time is correct, etc., etc., as outlined in the Trusted Computing section later in the 
88230
883document. This prevents and/or reduces malware affected nodes and other malicious attacks on
884the network.
885The reason for the random pools instead of having all nodes running DPoW all the time is to
886save on electricity and battery life of devices such as cell phones, until dedicated ASICs are
887popular and massively distributed. Mining is an inherently hardware and electricity intensive
888proposition, so distributing the mining duties randomly on the network makes it
889economically and energetically feasible, while preserving end user experience.
890The winning mining pool collects the coins and transaction fees and then the mining servers become
891dormant again, leaving them as simple clients until called on again to participate. This allows each
892person who participates in the network to have a built in Universal Basic Income simply for
893participating, since every node will eventually be called upon to secure the system, making the UBI
894real and plausible right now, something that is virtually impossible with current systems due to our
895unequal income tax and earning levels, not to mention most current governing bodies' inability to
896agree on practically anything of significance.
897As more clients and servers join network, the consensus becomes even more secure and
898simultaneously more evenly distributed/egalitarian, unlike current PoW systems that leave us
899with powerful centralized miners as the system develops.
900It is also worth considering a reputation system for miners that allows reliable miners to be called on
901more regularly. However, any such system must be carefully weighted so as not to allow the same
902miners to consistently drive all traffic. Trust would be defined algorithmically, for example based on
903whether the node responded to all requests throughout time, whether it ever had malformed packets
904or out of date software, whether its binaries have ever been altered from standard hashes, the
905node's speed, dropped packets, etc. This idea is outlined in more detail in the Networking section.
906Nodes could be less likely to receive requests if they have issues or a low reputation rating or even
907blacklisted if they have repeated issues such as compromised software, altered binaries, etc.
908Lastly, blockchains can grow very large, so how would a small client like a cell phone store
909the whole blockchain? The answer is none of them would need to at all. Instead, clients need
910to keep only a current subset of the most recent transactions and the rest of the blockchain
911is sharded up and replicated in pieces to all clients, so that each client is responsible for
912storing a small portion of the historical blockchain. If nodes drop out or go offline a shard may
913be replicating temporarily from an existing node to maintain a proper percentage of the chain to
914avoid losing any piece of it. Because other nodes contain redundant instances of that particular
915shard, all of the instances would have to be destroyed to destroy that part of the blockchain, which
916makes the protocol space efficient and able to run and be stored on a mobile device. In addition, the
917blockchains could be backed up by anyone or by a backup company to keep the system safe in the
918case of total disaster and to allow for restoration later, while providing evidence of their 
91931
920completeness. Lookups would use a DHT to find which nodes currently hold the necessary part of
921the blockchain for a lookup, should an old transaction need to be verified, and multiple clients would
922be checked to ensure accuracy.
923That means that the Distributed Proof of Work delivers the following in a single platform:
924• An egalitarian system which is highly resistant, if not completely immune, to
925centralization
926• A feasible UBI system as a byproduct
927• High security
928• Dynamic consensus which encourages participation from everyone in the system
929• Energy efficiency
930• Eliminated need to develop ASICs and the resultant ASICs arms race in current
931cryptocurrency platforms
932• Minimal storage requirements
93332
934Verifiable Computing
935We must assume that every node is untrusted and/or compromised and design the software in such
936a way that it is resistant to subversion. Take smartphone voting as an example. While eventually
937Cicada might simply have her own hardware designated for running this platform online, such as a
938simple card computer with no ability to run other software, running with a stripped down micro-OS
939that is highly resistant to damage and malware, in the early days of adoption we will need to create it
940for running on cell phones or AR glasses.
941A software blockchain could contain hashed stamps of binaries, software versions, protocol
942versions, etc., and a system booting on a cell phone or any future end user device that would check
943against the chain with a challenge to ensure that their local code has not been compromised. Should
944it fail to reach the network, fail a binary or date stamp check, or otherwise not pass any part of a
945comprehensive sanity check protocol (such as the sanity check protocol that miners go through for
946each transaction broadcast to the Bitcoin network to ensure that the transaction is not malformed), it
947would refuse to boot/run or otherwise perform only a small subset of features.
948Once the software boots, it would pull down the code from a distributed blockchain backed storage
949code repository to perform a binary update, perhaps a containerized layer style update with built-in
950layer security checks, including signed layers, as further evidence of trust.
951Ironically, this idea was inspired by malware writers who used such techniques to prevent analysis
952and reverse engineering of viruses by anti-virus companies. The malware would boot a small kernel
953and check that it could communicate to the network and it would also look for the presence of virtual
954machine drivers, as anti-virus companies often used virtual machines to isolate the virus. The
955systems would also only accept commands from pre-trusted centralized command and control units
956that signed messages with their private keys. Eventually anti-virus companies were forced to attack
957the command and control servers themselves to attempt to disrupt these networks, which further
958proves the weakness of any centralized system. BitTorrent was often attacked by similar means,
959going after the centralized websites that listed torrents or the DNS servers that pointed to those
960links.
961Upgradability
962The system must store version, protocol version, software versions, date and time stamps, as well
963as other metadata in the system to allow for enforcing upgrades. For example, should a client
964version contain bugs, the system might require an upgrade before it can conduct business. Likewise,
965an encryption protocol may become outdated due to the invention of new computer hardware, and
966as such it would need to be forcibly retired and replaced with a new one. Updates should happen 
96733
968through a container-like model where layers are added on top of existing binaries or binaries are
969flushed and re-imaged with new copies that match the correct agreed upon hash in the software
970blockchain.
971Networking Outline
972One of the most crucial pieces of a decentralized application is the robustness of its
973networking protocol. Fortunately, P2P networks have evolved significantly in the last fifteen
974years. Of particular note is the Kademlia design, a distributed hash table (DHT) with a novel
975XOR system, which provided the framework for a number of successful and popular 3rd
976generation P2P apps, notably Gnutella and BitTorrent, which have successfully scaled to
977100s of millions of users. Additional research work has focused on improving the efficiency of the
978routing protocol to minimize hostile actors and inefficiencies that stem from nodes going offline while
979still having entries in the DHT due to the DHT's eventual consistency model, which will include nodes
980that are no longer online for a short period of time. Broadly, those research efforts have fallen into
981two categories:
982• Improving the reliability of nodes with a reputation system
983• Improving routing efficiency through the use of fuzzy logic or biologically inspired algorithms
984This project advocates for both of these ideas and adds a novel concept of the HUID that will help
985mitigate or eliminate the most widely used attacks against Kademlia style P2P nets: Sybil attacks.
986As stated in the Design Specification document linked above:
987"A Kademlia network consists of a number of cooperating nodes that communicate with one another
988and store information for one another. Each node has a nodeID, a quasi-unique binary number that
989identifies it in the network.
990Within the network, a block of data, a value, can also be associated with a binary number of the
991same fixed length B, the value's key.
992A node needing a value searches for it at the nodes it considers closest to the key. A node needing
993to save a value stores it at the nodes it considers closest to the key associated with the value.
994NodeID
995NodeIDs are binary numbers of length B = 160 bits. In basic Kademlia, each node chooses its own
996ID by some unspecified quasi-random procedure. It is important that nodeIDs be uniformly
997distributed; the network design relies upon this.
998While the protocol does not mandate this, there are possible advantages to the node's using the
999same nodeID whenever it joins the network, rather than generating a new, session-specific nodeID." 
100034
1001In essence what the above says is that we have a 160 bit NodeID, which should be more than large
1002enough for everyone on the planet for thousands of years to come, even if humans ever manage to
1003push out into space and dramatically expand their numbers.
1004This project takes the stance the there are definitive advantages to the node using the same
1005nodeID every time it joins the network in that it prevents, mitigates, or impedes a number of
1006known attacks on the system. In addition, this project bans freely generated IDs on the client
1007side. Generating the ID with the help of a blockchain and from the HUID non-interactive zero
1008knowledge proof, single use sub-ID, and using that sub-ID as a seed to creating the NodeID
1009works to prevent users from creating multiple nodes on the network.
1010The health of the network, as outlined in the section on the DPoW spec, depends upon the one
1011HUID/one client design of the system. As such we utilize a novel approach to NodeID creation, in
1012which the NodeID is generated from a single-use, non-interactive zero-knowledge proof token/subID of the HUID. In particular, we spin up a sub-ID with zero RBAC privileges to access a client's
1013information, to prevent linking a HUID to a NodeID (i.e., unlinkability), which in turn prevents spying
1014on that node to gather intel on voting or participation in the platform. The sub-ID includes a secret
1015piece of information that can be verified through challenge response which is owned by the user, but
1016that does not leak additional information about the user.
1017We will discuss attacks and other countermeasures against P2P networks in this section as
1018well as the sections "Attacks on Kademlia and Trust Networks" and "Defeating Attacks on
1019Kademlia and Trust Networks."
1020The design specification site also specifies the following, which outlines routing and routing tables in
1021the system:
1022A Kademlia node organizes its contacts, other nodes known to it, in buckets which hold a maximum
1023of k contacts. These are known as k-buckets.
1024The buckets are organized by the distance between the node and the contacts in the bucket.
1025Specifically, for bucket j, where 0 <= j < k, we are guaranteed that
10262^j <= distance(node, contact) < 2^(j+1)
1027Given the very large address space, this means that bucket zero has only one possible member, the
1028key which differs from the nodeID only in the high order bit, and for all practical purposes is never
1029populated, except perhaps in testing. On the other hand, if nodeIDs are evenly distributed, it is very
1030likely that half of all nodes will lie in the range of bucket B-1 = 159.
1031Bucket Size
1032Contacts
1033A contact is at least a triple:
1034the bigendian nodeID for the other node 
103535
1036its IP address
1037its UDP port address
1038The above basically says that each node maintains contacts which it can use to route to other nodes
1039in the network. Those contacts generally consist of a NodeID, an IP, and a UDP address. In the case
1040of Cicada, NodeIDs are difficult to forge as they are generated from a hash of the public key of the
1041single-use, zero-knowledge proof sub-ID and nodes use their own public/private key pairs and selfsigned certificates to sign and secure messages. But before digging into those details, let's look at
1042the various attacks on P2P networks.
1043Lastly, for the purposes of secure end-to-end messaging communication, each node in the system
1044can act as a router and VPN, forwarding packets onion router style, made famous by Tor. However,
1045unlike Tor, which requires dedicated endpoints to be set up by tech-savvy users or which allows
1046malicious users looking to compromise the network to set up nodes to capture traffic, a pure peer-topeer system would make it much more difficult to assault. Just as with the DPoW, nodes would be
1047randomly selected to act as temporary VPN/onion router node endpoints in the same way that
1048miners are elected. They are drafted for a period of time and their NodeID is stored on a VPN
1049blockchain for forwarding specific types of messages. This will eliminate attacks on VPN endpoints
1050as a means to suppress dissent and alternative viewpoints.
1051Attacks on Kademlia Networks
1052Now that we have a general understanding of the essential Kademlia concepts, which you can dig
1053further into at the design site, we can shift to how to enhance and improve the basically sound
1054framework provided by the authors.
1055Much of our thinking on how to improve the networking of the DD platform comes from the excellent
1056research paper called "S/Kademlia: A Practical Approach Towards Secure Key Based Routing." The
1057authors go a long way to creating a secure version of Kademlia, outlining a number of attacks (briefly
1058summarized below), as well as excellent though incomplete solutions to these attacks. However, this
1059project deviates from the thinking of the paper in one key aspect:
1060• Defeating/Impeding Sybil attacks
1061The authors did not know of or conceive of a universally unique human identifier, and as such had to
1062use a number of techniques to attempt to mitigate Sybil attacks that are largely solved simply by
1063having a HUID.
1064Sybil Attacks 
106536
1066The S/Kademlia paper makes the assertion that "Douceur [8] proved that [Sybil attacks] cannot be
1067prevented, only impeded."
1068We make the case that they are more dramatically impedable than previously thought via a proper,
1069successful implementation of a HUID/SIN, as described earlier. Since one client/one node is the
1070default design of the system and users are not allowed to spin up additional nodes, many of the
1071typical Sybil attacks which involve generating multiple IDs and spinning up a number of clients to
1072gain partial control over the network are now infeasible. The only caveat is that compromised nodes,
1073i.e., malware-infected nodes, still provide a feasible path to a Sybil attack as well as a variety of
1074other attacks.
1075As such, a strongly verifiable computing framework, as outlined earlier, is necessary to help ensure
1076the reliability and trustworthiness of this platform, not just for Sybil attacks but for a number of other
1077types of attacks as well. Software blockchains, forced checking or binary signatures, time stamps,
1078and other sanity checks should severely limit the number of malware attacks on the network to an
1079imperceptible amount. This is akin to reducing the number of flu particles in a host system, such that
1080the host is still infected but not to a degree that the overall system is still threatened.
1081Attacks on the underlying network
1082We assume that attacks on the underlying network, be it IPv4, IPv6, or a wireless peer-to-peer mesh
1083network are possible and unpreventable. Since we are talking about building an overlay network to
1084piggyback on existing insecure protocols, we must simply treat the underlying network as unreliable
1085and potentially hostile at all times. We also assume that nodes can spoof IP addresses, be
1086compromised, and as such allow denial of service attacks on the overlay network.
1087The focus of the project is to make the overlay network as secure and reliable as possible while
1088assuming that the underlying network can be assaulted. This is the philosophy of protocols like
1089Bitcoin, which has remained remarkably immune to serious attacks, other than denial of service
1090attacks, despite moving billions of dollars around in its ecosystem. This is certainly not for lack of
1091tying. Hackers who manage to successfully crack the system would stand to yield a significant
1092payday. As such it is safe to assume that there are many attackers working on it at any given time
1093and that they have generally failed due to the reliability of the design, the robustness of the
1094codebase, and the design team behind it.
1095In addition, the Cicada platform will include a mesh network design for operating when no under
1096network is available, such as when networking and communication infrastructure is destroyed in a
1097war, or when the platform is operating in openly hostile territory.
1098Node Impersonation 
109937
1100Node impersonation is where a NodeID attempts to impersonate the ID of another node on the
1101network.
1102Eclipse Attacks
1103This attack attempts to put malicious nodes on the network to force traffic flow through them and cut
1104off or hide good nodes from the network.
1105Churn Attacks
1106An attacker who has compromised a number of nodes may force them offline and online again and
1107again, creating instability in the network.
1108Reputation Attacks
1109One category of attacks that are not outlined in the S/Kademlia paper are reputation attacks,
1110because the authors were not proposing to expand the system using a reputation-based system.
1111Reputation attacks tend to focus on either ruining the reputation of another client, such as knocking
1112them offline repeatedly to make them seem unreliable, or on systematically building a perfect
1113reputation only to subvert that goodwill later.
1114The primary attacks on reputation systems, as outlined in the paper A Survey of Attacks on
1115Reputation Systems, are the following or a combination of all three:
1116Self-promotion
1117This is where a node attempts to create a positive reputation, only to exploit the system at a later
1118date when its trust is highest.
1119Whitewashing
1120An attacker attempts to repair their bad reputation by exploiting vulnerabilities in the platform. In
1121other words, this is the equivalent of breaking into the teacher's office to change your grades.
1122Slandering
1123Attempting to destroy another node's reputation unfairly in order to get the node blacklisted or
1124banned.
1125Defeating Attacks on Kademlia and Trust Networks
1126Now that we have outlined various attacks on the system, let's look at ways to prevent these attacks.
1127A well-designed system includes countermeasures for all known attacks as part of its ground-up
1128design. 
112938
1130First, Sybil attacks and node impersonation can be defeated by not allowing the nodes to
1131freely create their own IDs. Since the HUID's single-purpose sub-ID is linked to its NodeID, it
1132should be very hard to spoof a NodeID on the network. In addition, we propose that the NodeID
1133be created from a hash of the public key of the sub-ID, allowing the public key of the sub-ID to be
1134projected into a NodeID blockchain. This would allow other nodes on the network to determine
1135whether a NodeID is valid, simply by calculating its hash with the sub-ID's available public key.
1136Second, the best way to prevent most of the other attacks listed is to have each node create
1137its own public/private keypair. The public key of the node is projected into the node
1138blockchain. This idea builds on the work of Michael Kohnen's
1139comprehensive TrustedKAD PHD candidate dissertation. In his paper, Kohnen outlines a
1140method to prevent slandering and other attacks on reputation by generating a self-signed
1141certificate for each node that includes its IP address and port, as well as a date and time
1142stamp. TrustedKAD differs from the Cicada platform in that it does not include the node's public key
1143or the concept of a blockchain. The Cicada platform will use the node's ID in the certificate system,
1144as it is not attempting to prevent Sybil attacks at this layer, as it has already worked to prevent them
1145during the HUID and node creation process. The node signs all messages with its private key and
1146includes the certificate in the message header. If its IP address changes, the node generates a new
1147certificate. The receiving node can check the hash against the stored public key, as well as check
1148that the packets originated from the correct IP and port. If the signature or underlying network
1149information do not match, the packets are discarded.
1150The system also used a trust-based system to rate nodes. Nodes are rated for correctness of
1151protocol, whether they have up-to-date software, whether they have ever sent malformed
1152packets, etc. In addition, the system may use genetic or neural pathway inspired checks such
1153as how long a node has been online, how close it is, whether it has ever connected to the
1154sending node in the past, how many other nodes it connects to and knows about, how many
1155hops away it is, whether its time is correct, etc. An exhaustive list of application and network
1156checks will not be examined here, but will be further outlined in the project's formal design phase.
1157Ratings are binary. 1 is for good and 0 is for bad. With too many negative scores, a node may be
1158blacklisted from the DHT routing table for a period of time that increases with each violation, followed
1159by an eventual total blacklist. The total blacklist would prevent the node from participating in DPoW
1160and hence deprive it of UBI and it would prevent it from forwarding messages, so nodes would have
1161a strong incentive not to lose their UBI. However, it might still allow a user to vote, as votes would be
1162taken away or granted by governing bodies in a nation state or via automatic violations. In addition,
1163for permanently blacklisted nodes, a bonded/trusted authority may be created to restore access,
1164though any such entity and any system that allows for total blacklisting must be perfectly designed to
1165prevent ensnaring users that were unknowingly compromised, which will likely be the vast majority of 
116639
1167end users. As such, total blacklists should be considered impractical in the early phases of network
1168design.
1169Lastly, because new nodes cannot be very efficiently evaluated beyond software version, IP address
1170reputation, etc, the Cicada platform includes a grace period for new nodes.
1171The ratings for nodes must be continual. As Kohnen notes in the TrustedKAD paper, it is necessary
1172to continually "rate the behavior of a node and to avoid interaction with it if it does not behave
1173correctly,"
1174The problem of where to store the rating information could be solved by storing it in the DHT and
1175including a method to ensure that no node is able to store its own reputation information, even if that
1176information is a copy, to prevent manipulation of that information. A second option is to again use a
1177fast moving blockchain (one with less then ten minute blocks) as a trust mechanism for storing the
1178information. Since the Cicada platform uses sharded up chains to store them in the small space of
1179local clients, a flag would again be needed to ensure a node does not store its own reputation
1180information.
1181The methodology of storing the reputation information is one that requires further research, and the
1182above suggestions should only be considered starting points. However, considering the number of
1183research papers that include some type of reputation system, it is likely that a viable solution already
1184exists. However, this project takes a firm stance against the S/Kademlia "supernode" concept, which
1185includes a large number of supernodes that act as trusted arbiters of the network. In the opinion of
1186the authors, those supernodes would create the very weaknesses we are trying to avoid. However, it
1187may be possible to create a modified form of the supernode. Recall earlier that we recommended
1188drafting nodes into temporary onion router/VPN endpoint nodes. Perhaps a temporary cluster of high
1189bandwidth nodes, verified through repeated tests, could be elected for brief periods of time to
1190facilitate better traffic throughput and management while not allowing supernodes to become
1191dedicated attack points.
1192Mesh Network Fallback
1193In addition to building a scalable overlay network that secures communications over the top of
1194compromised and untrusted networks such as the Internet, the project should work to create a
1195fallback to a mesh network. Mesh networks are crucial to overcoming obstacles when a society's
1196centralized communication infrastructure is destroyed or so compromised through collusion with an
1197authoritarian power that it cannot be trusted under any circumstances.
1198Mesh networks are not a new idea. Many militaries rely almost exclusively on mesh networks,
1199because field forces simply cannot count on existing infrastructures in hostile territory. Utility 
120040
1201companies often use mesh networks to gather meter stats. A number of darknets exist in San
1202Francisco that are not internet connected and "invite only," in that you must know a member to be
1203asked to join the network. In war-ravaged countries a mesh network for running Cicada could
1204become essential, and so further exploration is needed on this topic.
1205A number of open source and commercial mesh networks are already coming to the marketplace,
1206such as FireChat from OpenGarden, so we will not explore this concept in-depth in this paper.
1207Instead, we would look to consume a well-written, transparent, and scalable mesh network from
1208other project first, before creating our own from whole cloth.
1209MixNet
1210Nodes will also be randomly drafted as tumblers for forwarding messages. MixNets are useful for
1211further obscuring information about the origin of a packet, vote, or message, by scrambling up those
1212messages with other messages such that the input and output are difficult to trace. MixNets are
1213particularly useful for voting systems.
1214Nodes are drafted randomly by the system, during the same round as the draft for the DPoW
1215election to secure the next block. For safety reasons, nodes for the MixNet are not the same as the
1216DPoW miners. The protocol would work to choose different nodes based on flags in the DHT.
1217Malware infected nodes or nodes with bad reputations are blacklisted by the reputation system and
1218not eligible for selection. Votes cast are tumbled with other votes to obscure who the original vote
1219caster was, in order to further protect privacy.
1220P2P Communication System
1221A fully end-to-end encrypted communication system for establishing peer-to-peer or multipeer
1222communications is essential for any society to be able to communicate freely and securely. Existing
1223systems expose everyone to mass surveillance, assault by malicious actors, and compromise of
1224their PII. In many countries, laws also mandate keeping backdoors in commercially provided
1225encryption systems, and this problem will only increase as ignorant legislators weaken our
1226communication systems under the guise of safety and security. An open system is the only answer.
1227It is also necessary to implement off-chain transactions, such as those proposed by The Lightning
1228Network, which uses a series of hashed, time-locked smart contracts to facilitate most transactions
1229off the Bitcoin blockchain, thereby reducing the eventual size of the blockchain blocks while
1230dramatically scaling the number of transactions per second to scales much bigger than even a
1231company like VISA is currently capable of. If there is no secure system to find people to transact
1232with, the Lightning Network does not work. 
123341
1234We can use David Chaum's PrivaTegrity as a template here. He proposes a scalable mixnet
1235called cMix to provide unlinkability and secure communication. In the Cicada network, nodes
1236are randomly drafted into MixNets, which differs from Chaum's design which relies on
1237centrally trusted servers.
1238Chaum also provides a novel but controversial universal decryption scheme. Universal
1239decryption keys are generated and sharded up among nine different server farms in different
1240geographies. If all nine servers agree, the sharded key is reconnected and we are able to
1241decrypt communications on the network.This is to prevent something "totally evil" from being
1242hidden. Once the keys are used, they are destroyed automatically, and new ones are created and
1243sharded up again, so that the nine servers must again universally agree to decryption.
1244Chaum's proposal sparked fierce debate, because there are some obvious problems with this
1245methodology. For example, the nine systems can collude, or if they are actively hostile and
1246cannot agree then nothing can be done, despite the vast majority of users agreeing to the
1247proposal.
1248A direct democracy and smart contracts provide a simple solution that is powered by the
1249people. Universal keys are created and encumbered with a script and stored in the keys
1250blockchain. Upon a 2/3rds majority vote, the keys can be released for a specific purpose,
1251written in the Legal XML language, as a part of the voting contract. Once the keys are used
1252once and the rights expressed in the contract are fulfilled, as enforced by the contract
1253parameters themselves, the keys are destroyed and new ones are created and reencumbered, requiring an additional vote to unlock.
1254In a traditional system, people must make a choice between full encryption or compromising
1255encryption for everyone. In our system, transactions are fully encrypted by default, but the
1256people can vote to decrypt certain transactions or audit transactions from a group.
1257The system may also allow for the creation of sub-master keys. These sub-master keys can be
1258given to an organization, such as a police department or central investigation unit, but can also be
1259revoked by the people in the event of abuse by that trusted organization. In the current real world
1260system, trust must be given, and if that trust is broken there is no method to revoke that trust. One
1261clear example is the mass surveillance system currently in place all over the world, with no
1262opportunity to hold those entities responsible for direct violations of the Constitution or law of the
1263land.
1264Additional Components of the System
126542
1266Now that we have outlined the major components of the system, it's time to address some of the
1267additional components necessary to make it work. These pieces will be covered only briefly, and this
1268list may not prove exhaustive once the project gets further along.
1269Stores of Value
1270Property deeds/intellectual property ownership rights/benefits/shares/contracts are all stores of value
1271that can be created, distributed, reclaimed, revoked, and dispersed to anyone in the organization.
1272Money
1273Currency, a store of value which can be exchanged for goods and services, is a part of the system.
1274Distribution of that currency is covered by the system. While it can be argued that money should be
1275lumped in as a "store of value," in actuality it is a special case in that it can be exchanged for things
1276perceived as valuable, be that value real or imagined.
1277Action Tokens
1278Action Tokens are distributed to IDs or sub-IDs to allow or disallow actions to take place. While they
1279are like currency, they have no actual store of value. We may choose to do this by handing out the
1280absolute smallest value of a particular currency, so that eight decimal places of Bitcoin aka a Satoshi
1281is one "action token" for voting, changing a ruleset, changing a law, enacting a law.
1282A much better choice is to simply create and distribute a completely separate set of blank tokens,
1283taking into account overall usage in the system to replenish the supply. Just as the Bitcoin
1284blockchain calculates the power of the network every few weeks, we can choose to track the overall
1285usage of action tokens and variably produce new ones to meet the demand. When a miner wins a
1286specific block round, the protocol would check the current action token blockchain tracker to see the
1287current number of new tokens to create. These action tokens would be stored in individual system
1288wallets, owned by nobody, controlled by smart contract, and used by the entire platform. An end
1289user node would request a new supply of tokens as they run down and their amount would be
1290enforced by the blockchain and released by these system wallets.
1291Action tokens with no monetary value are an important innovation in future decentralized apps,
1292because they allow for certain functions that simply should not cost money. A currency can always
1293fluctuate, raising the price of performing simple tasks, which is not desirable in a complex system.
1294Some actions, such as participating in the system through voting, should always be free. We do not
1295want participation limited to how much currency you can acquire. Current decentralized app
1296platforms have a chicken or egg problem. I need currency to use the system, but I have to acquire
1297that currency outside the system to use it. This is far from ideal. In addition, app designers may wish
1298to provide free services to people and paid services later. Action tokens make it easy to adopt the
1299platform, which should help to scale it rapidly and bring in less tech-savvy users. 
130043
1301Blind Tokens
1302These are tokens that utilize blind signatures and mixnets to keep transactions anonymous, such as
1303in voting systems.
1304Transactions
1305Transactions are any action taken by the collective or individuals within the collective, such as, but
1306not limited to:
1307• Distribution of value
1308• Transfer of ownership
1309• Votes
1310• Law creation/repeal
1311• Communications
1312• Smart contracts
1313• Off-chain payment chains
1314Proposal System
1315This is a system whereby people can put forth proposals to vote on.
1316The proposal system is two-fold. Expert groups can be called to put forth fast track proposals that
1317are given national votes. For example, a group of renowned economists might design the laws for
1318governing commerce, while a group of engineers might design safe operating limits for vehicles. This
1319has the strong advantage versus our current system of allowing people with actual knowledge of the
1320subject to put that knowledge to work, as opposed to what we have now, which is agenda-driven
1321non-experts (aka politicians) who make laws for other people without any understanding of what they
1322are doing.
1323The citizen proposal system is different. Anyone can put forward proposals. However, the system
1324routes any proposal through a random series of voters, starting small and going wide. A proposal
1325might be sent to 100 people, then 1,000 if it passes, then 10,000, and so on through a series of
1326defined thresholds designed to filter out useless/baseless/disingenuous proposals. An algorithmic
1327filter can analyze the proposals through something like Bayesian statistical inference to immediately
1328eliminate duplicates.
1329If a proposal does not meet a certain number of votes, it does not move forward. If people simply
1330don't vote on it, it does not have enough interest and it does not move ahead. If it is voted down, it
1331does not move ahead. 
133244
1333This graduated and filtered approach prevents spam to the system, as well as marginal and fringe
1334proposals from ever gaining steam.
1335This system in particular will require careful consideration and design. Additional methods of filtration
1336may need to be created to keep people from repeatedly submitting garbage proposals, such as
1337limiting the number of proposals per person, per month or year. If proposals are passed by an
1338individual, a reputation scoring system might allow them to put forth additional ideas, provided their
1339reputations stays at a certain threshold.
1340Deep learning systems may come into play here as well as they continue to develop. A system that
1341can learn common proposals, streamline them, and present them to the whole might prove very
1342valuable. Deep learning might also detect novel attacks on the system.
1343Rulesets
1344In a nation state, a ruleset could be a series of laws that govern citizenship or business relationships
1345or the rules for borrowing money. In a small organization it might be bylaws. In a corporation it could
1346be a mission statement or a series of rules governing behavior. These rulesets would be applied as
1347"connections" or "weights" to the HUID to identify people as a member of a group.
1348Rules/Law Framework
1349XML for law/rules, which exist in a given ruleset. Define a series of law allowed/disallowed
1350statements that all contracts/laws/systems must be defined as. These consist of variables,
1351conditionals, etc. Law must be expressed as a series of logical statements so that the system can
1352parse these laws.
1353Voting Framework
1354This encompasses voting integrity, voter intent, collecting and tabulating votes, determining result of
1355those votes. In short, this is an E2E framework or end-to-end voter verifiable framework.
1356The system must provide end-to-end integrity for all votes cast, while preserving anonymity with
1357blind signatures, mixnets and cryptographically verifiable voting records. Much research exists on
1358E2E, so this paper will not spend too much time discussing all of the ins-and-outs of this.
1359Vote Suggestion System
1360A system allows for suggestions on how to vote. Based on a question survey, such as demonstrated
1361by the "I Side With" website, a set of basic rules can be created about how a person would
1362particularly vote. The system would then examine the law XML and come to a conclusion, marking 
136345
1364the document/proposal/bill/rule change with green/yellow/red based on how likely you are to agree
1365with the majority of the provisions. This could eventually lead to an auto-voting system.
1366Auto-Voting system
1367A deep neural net can be trained over time on how you vote, learn your predilections, and predict
1368your votes. This would allow you to set up an auto-voting system for yourself that maintains
1369engagement with the system without manually having to vote on everything that happens in the
1370network, which can lead to voter fatigue. The system could have three possible defaults:
13711. Full auto voting, where the system votes on everything for you and sends you an auditable
1372receipt, with the option to change your vote within X number of hours or days.
13732. Semi-auto voting, where you retain manual votes on crucial issues to you as an individual,
1374such as guns or abortion, and the system votes on everything else.
13753. Full manual voting, where you vote on every issue presented to you.
1376Rewards
1377Leaderboards, rewards for participation, and reputation systems.
1378The system can "gamify" voting by rewarding and incentivizing certain behaviors while deincentivizing bad behaviors within the system.
1379Rewards should never be allowed for voting a specific way, only for continual, thoughtful
1380participation in the system.
1381Data Storage
1382This could be files, information, or anything else that a person or organization would like to
1383stored/hosted/distributed in the system. It could be a hybrid on-chain/off-chain system, such as the
1384one proposed by a group of researchers at MIT, called the Enigma system. Since there is plenty of
1385ongoing work in the field of distributed data storage, this will not be a focus for the system. A simple
1386keypair-based distributed storage system, with sharded, encrypted data and audit logs stored in a
1387blockchain, will be enough for basic transactions and state control. We will likely be able to consume
1388other projects for this purpose.
1389Sub-Organizations
1390Sub-organizations are dependent organizations (such as a cabinet department in a nation-state or
1391an engineering department in a corporation) that can exist in within a larger organization.
1392Information Post
139346
1394This could be an URL or BB service or forum that can people can share information on and which
1395they can collaborate.
1396Marketplace
1397This can be a model of a marketplace, such as a swap meet or a decentralized currency trading
1398exchange.
1399Modules/Extensions
1400An extension might be something like an auto-voting system, which is a can of worms. Modules can
1401be marked as experimental/alpha/beta/rc/prod.
1402Procedural Patterns of the Platform
1403In order to get the system up and running smoothly over the long haul, a number of methodologies,
1404rules, and protocols will be necessary to keep it error-free, secure, and functioning well.
1405System Bootstrap/System Instantiation
1406The system must have a protocol for bringing an organization online. What are the desired
1407steps/patterns that are necessary to bring the system online? This will not be closely addressed in
1408this paper, though it will require very careful consideration. For example, what are the steps
1409necessary to bootstrap the system and what are the first steps any person and/or group must take to
1410participate?
1411Founding a company requires very different actions from the birth of a nation. For example, a
1412company may acquire capital, create a mission statement and business plan, create a legal
1413framework, invite leaders, hire employees, etc. A series of basic steps would need to be outlined for
1414various types of uses for the system.
1415These use cases should be definable in YAML or another type of consumable text file and
1416usable/modifiable by anyone in the system.
1417An example of a nation state bootstrap might look like this:
1418• Form a provisional "working group" organization to help bootstrap the system
1419• Download the client/node
1420• Code an XML law framework or select from a provisional constitutional framework
1421• Call and organize a vote on a full constitution
1422• Create departments
1423• Choose heads of a department 
142447
1425Procedures of the DDD
1426Defining Citizenship by Linking HUID to Citizenship
1427IDs
1428What is a Citizen?
1429A citizen is a "person who is entitled to enjoy all the legal rights and privileges granted by a state to
1430the people comprising its constituency, and is obligated to obey its laws and to fulfill his or duties as
1431called upon. Also called national. See also domicile and resident," as defined by the business
1432directory.
1433Defining a citizen or non-citizen and associating those rights to a person's HUID is a multifaceted
1434issue, but one that is solvable. Unlike other voting or democracy systems, Cicada allows votes to
1435remain anonymous by have personally identifying information used once to ID a citizen before being
1436discarded, retaining only the public key of that information.
1437Citizenship is a human defined construct. Unlike DNA or fingerprints, which are immutable, unique to
1438the individual, and designed into our biology, citizenship is conditional, mutable, and revocable. As
1439such, there is no simple way to define it without artificially created documents (such as a birth
1440certificate), as opposed to naturally gifted attributes (DNA/Fingerprints). Countries are defined by
1441humans and as such are changeable in terms of borders and composition. They exist for a set
1442period of time before those boundaries change, or disappear altogether in the event of a country's
1443collapse. In short, they are ephemeral.
1444Citizenship is enshrined in the citizen blockchain. Additional sidechains can be created for
1445different types of information, since each chain is merely a different kind of data. All chains
1446are pointed to by the blockchain of blockchains. For example:
1447• HUID chain: HUID {human unique identifier}
1448o Backed by voiceprint, DNA and/or fingerprint chains
1449• Citizenship chain
1450• Crime chain: convictions {must be totally anonymous}
1451o Add a module for revoking or restoring based on criminal convictions, with a
1452blockchain for crime convictions that is anonymous/hashed and a check against that. 
145348
1454Vote tokens can be issued to most citizens by a DGO (Decentralized Governmental Organization),
1455as they are able to fulfill the following citizenship requirements. This can be one of the first DGOs
1456that is established by the system after it is bootstrapped and instantiated.
1457There are three types of people in a country:
14581) Current Citizens: We must be able to define current citizens, if the government is "rebooted" with
1459this system. Pre-existing citizens must be verified by looking at past evidence of citizenship. There
1460are two scenarios where the system would be implemented.
14611a) The government is replaced through displacement/revolution.
14621b) The existing government adopts the system and adapts to it or adapts it to its current system.
1463In both cases you would look at pre-existing documents, even if those documents do not have
1464current legal status {as in the case of revolution}. Those documents would not be stored in
1465unencrypted form. Instead, they would be hashed and encrypted, either through scanning (in public
1466terminals for those without regular digital access to scanners) or by putting in their unique number (in
1467the case of SSN or equivalent) and sending it to an appropriate storage chain for verification and
1468then stored in a local info-wallet. These are then attached via pointers to an anonymizing HUID subID to prevent attackers from using the information if they can successfully attack any of the
1469sidechains. Multiple documents attach weight to the ownership.
1470We must prevent against Identity theft. The simplest way is with a legal system that allows a person
1471to show up at a court and scan their iris and to verify their ownership of a HUID in the case of a
1472dispute. If not, the ownership is transferred back to the correct owner through a flag on any
1473alternative records made through the reputation system.
1474Stealing an online ID would become incredibly difficult as a birth certificate, once hashed, encrypted
1475and linked, cannot be applied to another HUID, so it is not something that is easily gamed.
1476Examples of pre-existing documents that can be hashed/attached to SIN.
1477• Birth certificate.
1478• Driver's license.
1479• Passport.
1480• SSN or equivalent.
1481• Property ownership in country. (Not necessarily a citizenship requirement, but may add
1482further weight to the system.)
1483• Hashed geolocation time stamps over a period of time.
14842) New Citizens: The second problem is how new citizens are added, i.e., how are immigrants,
1485refugees, etc., allowed into the country? 
148649
1487This would have to be through a DGO (Decentralized Governmental Organization).
1488A series of rules would define a citizen. This would be a pluggable system. As long as all of the
1489following criteria are met, a person would be granted automatic citizenship in a nation-state. For
1490example, they may need to:
1491• Pass a citizenship test. They could take this online, and the passing score would count as
1492one of the variables needed.
1493• Commit to investing a certain amount of money. A check against bank accounts or crypt-coin
1494wallet would ensure correct funds exist and are under the ownership of the individual.
1495• Live in the country for XYZ years. Property deeds (which could be traditional or blockchain
1496based) could be hashed along with a timestamp and a ticker. Once the number of years has
1497passed, the criteria are met.
1498• Not come from a country that citizens have prohibited immigration from or where immigration
1499is restricted and certain people are listed as prohibited. A blockchain of prohibited SINs {PSINs} would need to be checked against banned individuals.
1500o The system could request a human check for verification that a person is not from a
1501prohibited country or on a banned list in the event that the country does not use the
1502same system.
15033) Temporary Visitors and Worker Visas: Lastly, how are temporary non-citizens allowed into the
1504system?
1505These could be workers validated by their own tracking blockchain and gifted a temporary VID
1506(Visitor ID) that is attached to their SIN, which is then timestamped in the visitor's blockchain and
1507issued a countdown that indicates how long the person is allowed to stay. Once that timestamp is
1508passed, an officer of the law would be able to check their cryptographic timestamp against the
1509current date and decide whether they are legally allowed to continue their stay or if they must leave
1510or be deported.
1511Conclusion
1512Both decentralized application platforms and distributed direct democracies present numerous
1513complex and multifaceted design problems. They require novel solutions to existing problems and
1514solutions to previously unsolved problems. This white paper is by no means an exhaustive
1515exploration of the concept. It is merely a starting point for considering how people would begin to
1516build such a technology platform. 
151750
1518When author Daniel Jeffries conceived of the idea of a digital, distributed direct democracy twenty
1519years ago on his friend's balcony in New York, none of the technology to make it a reality existed.
1520Open Source as we know it today was in its infancy. None of the tools for massive, distributed
1521development, such as Git, existed. The Internet was a shadow of what it is today, with only about 36
1522million users, or 0.9% of the world's population. Smartphones were a glimmer in Steve Jobs' eye.
1523Even as late as 2008, much of the technology to make this theoretically possible had not been
1524developed. This changed in 2009, when the (possibly still unknown) creator of Bitcoin provided the
1525foundation of blockchain technology, which in turn created the possibility of designing DAPPS. However,
1526even with the breakthrough of blockchains, which are essentially trust machines, many concepts needed
1527to make Cicada a reality are still in the early stages of their development. Even the ones that are furthest
1528along have not fully crystallized around best practices.
1529Even worse, DAPPS lack many of the capabilities we've come to expect from client/server or centralized
1530cloud-based applications (which are really nothing but a client/server model extended to hyperscale).
1531Other technologies, such as revocable biometrics and biocryptics, exist in research paper form only and
1532will need to be implemented through trial and error. Many of these ideas may require significant
1533adaptation or prove entirely unworkable once they are committed to code and subject to the friction
1534and realities of everyday life.
1535Some technologies such as AI are just starting to evolve. Who knows what breakthroughs AI research
1536will bring? The field is currently going through a Cambrian explosion of development, receiving massive
1537amounts of investment that will only accelerate this trajectory.
1538Will CPU- and memory-intensive AI calculations ever be able to run on a distributed platform? Probably,
1539but who can say when? Certainly the project will benefit from the rapid developments in this sphere in
1540the coming years.
1541Lastly, it's also likely that some of the technology necessary to create this solution simply does not
1542currently exist in any form, and will require dependent technology to be developed first. For example,
1543nobody could possibly have conceived of the internet until computers were invented.
1544Nevertheless, after considering all of the research and working through the thought experiment of what
1545it would take to create a technology like this, the authors have concluded that the time to begin the
1546Cicada project is now. It offers the possibility of a better ID system, a more secure and scalable
1547application platform, a true universal basic income, as well as providing countries with little to no
1548successful governance a viable way to live and grow.
1549And that can change the world.