Popularis: A Distributed Direct Democracy and Decentralized Application Platform

(To view whitepapers without having to download please go to the /PDFs/ folder in this repo as Github doesn't support web viewing of .docx files)

This project is temporarily on hold, however we plan to resume work on it in the near future.

github.com/cameronball

[popularis [AT] iampopularis.com]

Version 2021.09.16.GA.001

(Copyright Notice: This project is a fork of the Cicada project, as they decided to retire the project we have decided to carry on the project while hopefully making headway with the code, the whitepapers are adapted from them, all code is proprietary intellectual property until we open source it.)

Important Note

We are working on the code and have been for several years our current release date is set at 2027. We have taken the decision to postpone our initial open source release due to security concerns. But we assure you the source will be available by the time the final release ships, however part of Popularis, Stronghold (The currency implementation), is currently open source: here. Here is the original whitepaper:

Abstract

This paper outlines a revolutionary, open source, decentralized application platform (DAPP) along with its first major application, a distributed direct democracy (DDD). To create something scalable enough to run an entire nation with no representatives, we created two cutting edge technologies to serve as the foundation of the platform:

1] A decentralized, privacy guaranteeing Human Unique Identifier (HUID) unique to every person on the planet that returns control of personally identifying information (PII) back to individuals, allowing for revocable role based access control to that data.

2] A new Distributed Proof of Work (DPoW) backed blockchain that is immune to centralization because of a unified client/miner with only one miner allowed per person, linked anonymously to a HUID. Miners are randomly drafted into built-in pools, meaning everyone contributes yet nobody dominates. The system provides a workable UNIVERSAL BASIC INCOME (UBI), i.e., it pays users to participate, since everyone is drafted to secure the network. It is incredibly energy efficient because it does not mine all the time and it is also storage efficient because it uses a Distributed Hash Table (DHT) of historical blockchain transactions, allowing it to fit and run on a cell phone.

Motivation

A true Direct Democracy (DD) requires representativeless government. The concept is so new that the word representativeless does not even exist. We had to invent it. Think of a digital DD as true algorithmic government. It holds the potential to unleash the true will of the people, while being a natural evolution from current governmental systems. While Direct Democracies have been tried in the past, in limited scope, such as in Athens and pre-republic Rome, there was simply no practical way to make such a system work with pure analog technology. A Direct Democracy absolutely requires mass communication and digitization. It almost certainly requires Artificial Intelligence.

The main inspiration for the idea came from the Arab Spring. Beginning in Tunisia in Dec 2010, a revolutionary wave swept the Arab world as the people rose up and finally managed to throw off generations of brutal and oppressive regimes. After the heady and hopeful early days of these revolutions, the results were dismally predictable: Tunisia remains unstable and, at the time of writing, unable to adopt a constitution. The Egyptians have replaced one military dictatorship with another. Syria has devolved into the brutal and horrifying civil war that gave rise to the vicious and fanatical ISIS, while creating a refugee crisis that threatens to rip the civilized world apart.

Thus people are worse off than when they started.

This result is sadly the norm throughout history. Even when people manage to peacefully overthrow decades of dictatorship, with very, very few exceptions, they wind up with yet another one. Communist China is another perfect example. The Chinese people rose up and replaced five thousand years of dynastic rule with a dynasty by yet another name: the People's Republic of China, a communist "people's dictatorship" that is essentially just a minor evolution of their dynastic system.

This problem of replacing one bad government with another stems from various organizational and systemic issues. After the Egyptian revolution, the only people sufficiently prepared and organized enough to gather votes were the Muslim Brotherhood, who had been organizing underground for years. More liberal and secular minded parties were left scrambling to make their voice heard. This led to the Muslim Brotherhood getting elected with a majority despite their relative unpopularity. Once in power, they sought to create a constitution bent to the will of religion. This was no surprise, since their primary worldview is that religion should be supreme in governing people's lives. People's worldviews directly shape and limit their ability to create solutions. Unfortunately, since the Brotherhood's view was not shared by everyone in the system, and they failed to account for and give voice to alternative viewpoints, which is the very foundation of a democracy, their swift collapse was inevitable. Within a year they were overthrown by the only other organized group: the military. So in just three years Egypt wound up right back where it started, trading one military junta with 40 years of "emergency executive powers" for another military junta masquerading as a democracy.

A properly developed Distributed Direct Democracy that runs from everyone's phones and/or the personal electronics of tomorrow has the potential to break this cycle forever.

In its idealized state, a Direct Democracy is self organizing, self-booting, self-replicating system that provides, instantiates, or automates all functions of government. It is able to sustain itself indefinitely, provided sufficient communications infrastructure still exists within the country or sufficient client devices still exist to power a mesh network.

Creating such a platform may take ten years. It will require cutting edge programming, critical thinking, and a willingness to solve a string of currently unsolved problems. But the potential rewards are vast and manifold, easily making it worth the huge engineering effort required to make it a reality.

If there is one goal for this project, above all others, it is this:

The next time there is an Arab Spring, the people will be able to replace their leaders with code.

Defining Distributed Direct Democracy

Before we dive into the technical details, let's discuss what a Distributed Direct Democracy is and why it is even needed?

To start with, a DD is not another digital democracy initiative that focuses on augmenting or streamlining current representative systems of government. A DD is a representativeless government, where every idea is voted on by every citizen.

This, of course, creates a number of new challenges, such as driving voter participation, avoiding voter fatigue, and the average voter's imperfect understanding of essential issues. There is also the problem of preventing the system from being overwhelmed by irrelevant, impractical, or disingenuous proposal, an issue which plagues existing frameworks such as California's ballot primary system or the UK government's petition website.

A later section addresses many of these issues via automated voting, gamification of voting, and the ability to call expert private groups to create fast tracked proposals for complex topics such as economics, technology, and the sciences, rather than relying on politicians with no experience or meaningful understanding these disciplines. We will also provide a filtration system that dramatically limits the amount of proposals presented to the entire nation for voting, ensuring only the cream rises to the top.

In short, we propose creating:

• Algorithmic government
• Representativeless government

We are also focused on building something that is:

• Entirely decentralized and serverless, with no central choke points

Existing projects and initiatives, such as DemocracyOS, Liquid Feedback, and BitCongress, while interesting, innovative, and admittedly further along than this project in some respects, are primarily about providing an easy way to talk to elected representatives.

The problem is that those representatives are under no obligation whatsoever to care about that feedback.

And we already have a robust platform for debate and learning about issues. It's called the Internet.

Representatives are not interested in constant feedback from those they represent. They are interested in their own views and agendas, which is why these platforms have seen very limited adoption and likely never will.

A representative system is flawed because representatives don't really have to care what people think. They are elected as proxies, not as a direct reflection of the people's ideas and opinions. They are there to govern for us. If their views begin to widely diverge from popular opinion, there is no patch for that flaw in the system. The people are out of luck, doomed to watch as their "representatives" begin to implement policies that work against them, with no way to slow or stop the slide. While the United States still remains the standard bearer for democratic success in world history, the policy positions of elective representatives significantly diverge from those of the average "man on the street." The now famous Princeton Study, which looked at 40 years of lawmaking, found that if a policy had a 100% approval rating from the people it had only a 30% chance of passing. Conversely if a policy had 0% support it STILL had a 30% chance of passing. These divergences are intrinsic to a representative system. Thus any system that looks to provide feedback will not change much at all.

By contrast, a Direct Democracy creates a powerful framework for continuous voting that reflects the changing will of the people, exactly as they intend. While there are certainly challenges and weaknesses to solve for in this type of system, we believe the system can be crafted in such a way that it will be strongly resistant to distortions while providing powerful checks and balances at an algorithmic level, making it less prone to subversion when elected representatives decide to erode or ignore constitutional and legal checks and balances on their power for personal gain.

Technology Introduction

Making such an audacious idea a reality requires a fundamental rethinking of DAPP platforms. While it is possible that Bitcoin and Ethereum, the two major contenders to the DAPP throne, will one day be ready to scale the heights needed to securely run an entire nation, that day is not now. Bitcoin is almost exclusively focused on the limited use case of creating a cryptocurrency and has major scalablity issues that the debate over 2MB or 8MB blocks barely addresses. If the Lighting Network project creators' calculations are correct, then 8MB doesn't even come close to solving the problem. To grow to a planet scale, Bitcoin will require a radical re-architecture or the successful implementation of an off-blockchain payment system, where the blockchain merely functions as a dispute mitigator. To put the problem in perspective: if 7 billion people perform 2 transactions a day, that alone gives us 24 GB blocks, generating a blockchain of 3.5 TB a day, or 1.27 PB per year.

Ethereum has different challenges. It is a truly ambitious project, run by a brilliant and visionary founder in Vitalik Buterin, and it may yet prove successful and revolutionary in the long run. But today it is still in its infancy. It recently because of a security vulnerability in its smart contracts, allowing a hacker to steal $60 million in Ether from a Decentralized Autonomous Organization (DAO), forcing a hard fork in the blockchain to restore the stolen currency. This precipitated a kind of civil war inside the platform, with Ethereum Classic maintaining the original blockchain and the official project working off a forked blockchain, a civil war that is still raging to this day.

In truth, Ethereum is really an extension and evolutionary iteration of the ideas of Bitcoin. It was built to enable some technology that Bitcoin refused to support, such as a Turing-complete scripting language. However, it maintains many of the limitations of Bitcoin, such as its proof of work (POW), which is prone to heavy centralization, and its reliance on a wildly fluctuating currency.

We need a new way of thinking about DAPPs to create the platform that will run the next generation of decentralized, autonomous applications and give us the Internet we deserved in the first place, instead of the increasingly brittle, insecure, and centrally controlled system we have today.

There are several crucial technologies necessary to build this new system, each of which will be explored in turn.

1] A HUID generated through the intersection of revocable biometrics and cryptography. Revocable biometrics improves biometrics by allowing systems to revoke a biometric token without revoking the underlying biometric. This is further improved with the addition of cryptography. By using biometric markers (initially utilizing both irises as inputs) to create public/private keypairs, we can generate a unique ID for each person on the planet. This ID is not centrally controlled, which will virtually eliminate all Sybil attacks, along with the vast majority of problems in peer to peer networks. The HUID also allows for blind signature/ zero-knowledge proof sub-IDs that allow role-based access control to personally identifiable information (PII).

2] A peer-to-peer network based on a modified version of the Kademlia protocol. By using a special, single-use sub-ID of the HUID to generate the Node IDs in the system, we can prevent Sybil attacks and allow for a new PoW system. This special purpose sub-ID has no access to even the basic ID numbers of the HUID, and thus provides unlinkablilty and unobservability. This in turn provides the kind of capabilities we are already used to in our democracy, such as anonymous voting and the principle of one person, one vote.

3] By linking the HUID to the Node ID, we can then move on to create a powerful new Distributed Proof of Work (DPoW) for securing our blockchain. The key is to eliminate the split between client and miner that currently exists in all cryptocoin systems. Instead, we unify both client and miner, meaning every client is a miner and vice versa. Each person is allowed exactly one miner. To secure the system, miners are randomly drafted into built-in mining pools to compete against each other. This has the happy benefit of providing a workable and practical Universal Basic Income (UBI), since everyone is drafted to secure the network. However, since only a fraction of the network is required at any time to secure the network, it remains energy efficient enough to run on a cell phone, since expensive and battery-draining operations are not running constantly. In addition, this system eradicates the current plague of centralized mining in Bitcoin and other cryptocurrencies, where private companies build ASICs secretly and never release them to the public, trading one form of centralization (government-sanctioned banks) for another, more pernicious one (private, unaccountable, and ultra-secret corporations/organizations). Lastly, we make the platform storage efficient by storing only the most recent transactions in the program, likely only the past few months' worth, and then shard up the historical blockchain via a Distributed Hash Table (DHT), which is then redundantly distributed to all miner/client participants so that it can fit on any tiny device.

We will also outline other technologies specific to the functioning of the DDD and the underlying DAPP platform. But before diving into each of these fundamental building blocks in detail, let's take a quick look at the design philosophy behind those ideas to understand why they matter and why they are necessary.

Philosophy of the Project

Our philosophy is simple:

There is always a solution.

Just because a problem is challenging or people have not previously discovered a solution, does not mean no such solution exists. It means the problem is not being looked at correctly.

In order to create solutions for as-yet-unsolved problems, we do the following:

• First, we identify ideal characteristics for the system.
• Next, we develop a solution that meets all of these criteria. Solutions with known flaws are not acceptable unless those flaws are mitigated completely or extensively minimized.
• We then create these solutions by taking an interdisciplinary approach, uniting ideas from multiple areas of human knowledge, taking inspiration from seemingly disconnected fields. But no field is truly disconnected. Separateness is an illusion. All things in the known universe share similar patterns, and when studied together, offer insight into difficult or seemingly impossible problems.

Many people and teams are prone to saying "there is no solution to that problem" and then defaulting to known, flawed solutions. This is nothing but lazy thinking and unacceptable in the Popularis project. An example is using "trusted" central authorities, a system with extensive flaws and known weaknesses. Reliance on central trust doomed attempts to create digital currencies, such as e-gold, before Bitcoin solved the problem of decentralized trust and consensus.

Where possible, we favor the following characteristics for our system , with any deviations needing to offer significant benefits:

• No single organization, business, or person can control or alter the system without extensive consensus
• Completely decentralized and distributed

- Reliant on no centralized trusted entity for its core functions - However, it is worth noting that pluggable modules, outside of the basic infrastructure plumbing of the system, may be open to relying on the services of centralized entities for highly specific functions, such as current web APIs

• Privacy and the right of a person to be in control of their personally identifying information
• Openness

- In methodology, source code, protocols and security measures, upgradeability

• Security of the system based on emerging "trusted computing" practices

- Though the term "trusted computing" is controversial because of its use by corporations to limit what users can do with their personally owned systems, in this case the power of the concept will be inverted and used to return the power to the individual. Its ideas will be leveraged to protect the user and the system from malware and centralized attempts to subvert the platform.

• Strongly resistant to coercion and subversion
• Usability/Simplicity

- Easily adoptable by a broad group of people with no technical skill to advanced technical skills.

• As much of the technology we propose relies on encryption, we stand absolutely against key escrow or weakening of cryptography in any form. Ultimately, this is the only true threat to the system
• End-to-end verifiable and auditable
• Resistant to hostile actors

If a proposed solution fails to solve for any of these principles, it is inadequate.

The philosophy behind a project directly corresponds to the code that is created. Starting with an incorrect perspective leads to broken results that do not serve all the people in a system. The philosophy of this project is to build an "agnostic" or "universal" system. To serve as many people as possible it must be agnostic and immune to attempts to take control of it and force a particular worldview or agenda on it.

The history of the world is a battle of ideologies. Each of those ideologies believes that if they could just gain complete control, everyone would be happy. Nothing could be further from the truth. There is literally no way for a single worldview, be it capitalism, socialism, communism, or any other "ism," to satisfy all the people all the time. If the system is not agnostic, in that it serves the needs of everyone, it serves no one, and it will not be widely adopted. To be agnostic it must be open and unlimited in its use, fostering competition among ideas, with a system of underlying checks and balances that keep it all organized and operating fairly.

Many of these core principles will create unique challenges. Some of the principles seem at odds with each other, making it hard to solve for all of them at once. When people design a system with such challenges, they run across hard or seemingly intractable problems. This often leads them to compromise. For instance, in voting systems, strong identity management and anonymity seem to be starkly opposed. As such, the architects often decide one of these principles must fall by the wayside. This leads to flawed and broken platforms that do not meet the needs of all the actors in the system. For example, Democracy OS " simply does away with secret ballots." For this project, that stance is unacceptable. It indicates that the designers did not iterate enough through the challenges to come up with a truly revolutionary concept, instead settling for a partial solution.

Partial solutions are no solutions at all.

Many problems seem totally unsolvable. This happens when systems are required to have traits that are in seeming opposition to one another. For example, before Satoshi Nakamoto created Bitcoin, all systems were believed to be subject to Zooko's triangle, which states that systems cannot have the following three characteristics simultaneously:

• Human meaningful
• Decentralized
• Secure

Before Bitcoin, people were able to solve for two of those properties but not all three.

Before Roger Bannister broke the four-minute mile in 1954, it was thought to be physically impossible. After he broke it, multiple people were able to break it in short order, simply because they now realized it was possible. They now had the correct frame of reference to actually achieve their goal. When we assume that something is impossible, we start with an incorrect framework for solving hard problems. We are starting at a deficit. It often takes one person to prove something is possible to enlarge the problem domain.

Unfortunately, solving a previously unsolvable problem tends to lead to a new problem that we call the "Satoshi box." We often jump out of one box, right into a slightly bigger box. People quickly adopt the solution, but are unable to think outside the framework it provides. Instead of finding additional solutions to the challenge, they iterate on the same solution over and over, even when it is not appropriate. We have seen this with almost every other cryptocoin to come after Bitcoin. With a few notable exceptions, all of them are but tiny variations on the same idea, with little to no divergence or original thinking.

This project will require both building on the past and completely new and undiscovered solutions. It requires big-picture, ambitious thinking. Tiny iterations are not enough.

Finally, it is also the position of this project that this technology is inevitable. Either we create it ourselves, or someone/something will do it for us and we will not like the results. It's as simple as that.

Already banks and foreign governments are creating huge, weakly secure, non-revocable biometric identification systems in centralized databases that we have no control over. Companies like GenKey are already working with the Indian government to create universal IDs for billions of people, using a proprietary, copyrighted algorithm that people have no insight into whatsoever.

These systems should be replaced with universally vetted, secured, and designed systems.

We simply can't allow this to be a private, closed system locked away from public scrutiny.

It must be open source, and it must run on a blockchain, to ensure no single entity controls it.

Why? Because, human history has demonstrated again and again that centralized trust is an oxymoron.

If we allow private companies to create this technology, you won't know where or how it is stored, what info is stored with it, whether the proprietary algorithms used to create it are any good, or even if it's really secure at all. You won't know most of this until it is inevitably hacked and all of your personal data spills out onto the nets, including your iris or fingerprint template or your DNA, which is now useless as an ID because you can't take it back or change it.

Architecture

In this section we discuss the high level architecture of the system.

First, let's list the primary components of a DDD:

Key Parts of the System

• Human Unique Identifier (HUID)

- Controllable by the user - Not stored in a centralized database of any kind - Deeply resistant to coercion and corruption - Nearly impossible to duplicate or steal

• Organizational IDs
• Organizational and personal RBAC
• Decentralized DNS such as the system designed by Blockstack
• End-to-End Verifiable Voting framework
• Groups
• Routing protocol

- Based on next-gen Kademlia distributed hash table design for P2P networks - Relies on the HUID to prevent Sybil attacks and uses a genetic learned trust algorithm among peers for routing and reliability ratings of nodes and peers

• P2P fully encrypted communication system
• Law framework encompassing:

- Parsable XML based law - Proposal and initiative system

• Smart contracts
• Participant and Group Entity Reputation system
• Decentralized Message Bus
• Distributed code repository
• Distributed Proof of Work (DPoW)
• AI/Machine Learning/Deep Learning system (Potentially as the tech develops to work on less powerful chips)

- An AI system would be used for - Auto-vote casting - Arbitration - Simplifying voting descriptions - Improving voting gamification - Budget distribution and analysis

Cryptography Technologies

• Zero-Knowledge Proofs
• Multi-signature transactions
• Blind Signatures
• Mixnets
• Public/private keys
• One way, non-invertible hash functions

Abstracts/Primitives of the System

Before discussing each of these components in turn, let's look at some metapatterns of the platform. The protocols designed for such a system would have broad applicability to a huge number of other types of systems, not just voting/government. Therefore, it is best to outline these protocols in generic, reusable terms so they can function as a complete DAPP platform.

We are creating a method to define social interactions at the planetary scale. Social interactions are links between various groups or individuals. Think of these groups as a series of spheres connected by strings. A society is nothing but a huge sphere encompassing smaller spheres, like states, counties, cities, companies, local clubs, volunteer groups, reading groups, movie lovers meetups, and sewing circles. Humans voluntarily form and drop out of spheres all the time. The interactions between those groups are nothing but a series of social protocols. A society is nothing more than a series of implicit protocols for how we organize, connect, agree, and disagree. Agreement and disagreement, connecting and severing ties are transactions in the system of human experience. Think of this system as a human interaction modeling platform. These are what we refer to as "grouping primitives."

While the project starts off as a direct democracy engine, a democracy is merely a subset use case of these abstracts/primitives. It should be noted that the direct democracy engine is a particularly unique use case, and as such will have some abstracts designed specifically for its use (e.g., action tokens and unlinkability to prevent vote tracking).

The system is also completely scalable. A local charity or social club could limit their sphere of votes to members of that group. This would allow the platform to work for everything from a gamers' hub to a nation state.

The system rests on the back of an open, totally decentralized universal ID system that uniquely identifies every human on the planet, is highly resistant to compromise and coercion, and is not controlled by any single corporate, group, or government entity. And yet those corporate and government and group entities can consume the ID system to attach an individual to their sphere or organization. However, the ID might be a unique sub-ID that simply grants limited access to only a subset of the what the very human owner of that ID wants them to see.

For example, Nielsen may want to make you a member of their rating team and they might want access to a subset of data that you have stored in a PII database or Info Wallet, which is described in detail later. You might generate a sub-ID that is cryptographically linked to your primary ID, but that only gives them access to a small subset of those interests.

We are looking to model every aspect of how humans interact and form bonds. How do they exchange value, do business, put forth ideas, create laws, enforce laws, join groups, leave groups, agree, disagree?

Individual Component Outlines

Here we outline the various critical foundations of the system. They form the framework for constructing the specific use case of a distributed voting system, but they can be used to govern many, many types of human interactions, such as joining or leaving a company, creating a decentralized autonomous organization (DAO), ensuring trusted computing, and decentralizing privacy, to name but a few.

Human Unique Identifier - HUID/SID/SIN

We have already broadly discussed the HUID, but this section will dive into it in detail.

The "Human Unique Identifier" (HUID) or "Single Identifier" or "Secure Identity Number" is an ID unique to each human on the planet. This allows us to prevent Sybil attacks and ensure everyone has a voice in the system. The HUID must be unique, incontrovertible, incorruptible, and not centrally stored or administered.

The system's integrity rests on this ID, so it must be the most well-designed part of the system. No previous ID effort is an acceptable stand-in here. As such, consider this only the most basic framework for such a system.

The HUID uses biometric markers to create public/private key pairs, guarded by passwords, which in turn are used to create IDs and linked sub-IDs. To be very clear, what we are talking about here is biocryptics NOT biometrics. Biocryptics are the intersection of biometrics and cryptography. Biocryptics holds the promise of solving for all of the problems that biometric systems create.

Traditional, non-revocable biometrics has a long history of insecurity and compromise. In the general public they often incite fear and uncertainty, a fear and uncertainty that is justified. However, in the past five to ten years, cutting edge researchers have spent countless hours considering revocable biometrics, biometric security, and using biometrics in combination with cryptography to create strong ID systems that mitigate the flaws of earlier systems.

Biocryptics will be the focus of this system, as there is currently no better methodology to create a universal identifier than to start with the markers that make us all unique: our biology. The primary difference between biometrics and biocryptics is that biomarkers, such as fingerprints, irises, retinas, DNA, and/or spectrometer readings, are used as inputs to cryptographic key functions.

There may still be hidden flaws in the implementation of this idea that will come out as other researchers consider it. Nevertheless, even if the specific parameters outlined here are found to be flawed or incorrect in some way, the underlying idea of creating a unique ID for each person, linked to their biometric markers, remains crucial and foundational to the system, and designers should look to iterate until they have found a perfect one with no known weaknesses.

To start with, the Popularis project will focus on using double-eye iris scans as the foundation of its identity system. Iris scans appear to be the best current candidate for the HUID, because they are fast, reliable, and have a very low false positive rate. With the release of the Samsung Galaxy 7, the technology is about to become widely available, and may eventually become a standard feature of end user devices.

Unlike retina scans, iris scans don't require you to be too close to the scanner. Lastly, because the scan can be done from a distance, it makes it easy to identify both eyes at once. This is an essential feature, as we want to keep people from making multiple IDs for themselves.

However, just because we have outlined the prototype system with iris scans does not mean this is the only possible solution or that better ones will not come along in the future. The system should be pluggable and allow for upgrades/replacements/sunsetting as the technology develops along these lines. DNA holds the strongest possibility as a perfect ID system, considering that the problem of telling twins apart is now largely considered solved. Unfortunately, DNA testing at the time of writing still involves taking blood or saliva and sending it off to an external lab, which makes it vulnerable to numerous layers of compromise. In the future, we foresee systems, such as a watch or bracelet, that can extract imperceptible amounts of blood and synthesize that DNA without the data ever leaving your wrist. At that time the technology will be reconsidered.

The HUID is created by generating a public/private key pair from an iris scan and storing that ID in an identity blockchain, known as the HUID chain.

The HUID has the special advantage of being largely immune or at least incredibly resistant to Sybil attacks, because it is unique to each person and cannot be reused in the system. This is an essential trait for a system where one person, one vote applies.

To create the public/private key pair, we scan for biometric markers known as " minutiae points." We identify these critical minutiae points to create a " template" of the points, convert them into a hash, and use them as seeds for a pseudo-random number generator to create a public/private key pair , along with salt to create additional randomness.

This public private/key pair will then be used to create an "info wallet." This is similar to a bitcoin wallet, but used for storing personally identifiable information (PII). The public key is run through a function to create a unique numerical ID for a person.

The public/private key pair will include a built-in requirement to create a strong password, utilizing a rainbow table of prohibited weak passwords, enforced by the blockchain, to ensure good security practices. A password is necessary to prevent coercion, as a person could be forced to use their biometric markers to do something they don't want to do, such as unlock a phone. Without a password, that phone simply unlocks.

It is also possible for a user to create a "coercion password" that can be used if they are threatened or under duress. This password would appear to perform all the actions requested by the attacker but allow them to be rolled back at a later time. This creates some problems, as it could be used to scam legitimate transactions in a system, so this will not be considered in the rest of this paper. However, it should be addressed at a later design stage.

The system will also include a blockchain-driven challenge/response system for resetting passwords, re-enrolling keys, or changing keys, which marks old keys as blacklisted/unusable. People forget passwords. With no friendly web company to reset it for you, there must be a secure, powerful, decentralized method built into the protocol to make it easy for people to do this without compromising overall security.

To secure the template, yet prevent repeated use of the biometric signature, we delete random sections of the data and store it in a different biohash/fingerprint blockchain that is not linked to the HUID chain in any way. To do this we use a "Blockchain of Blockchain" approach, as outlined later in the paper. By deleting random chunks of the template, we can use that data to check if an person is already enrolled, but not simply take that template and attempt to create a new key.

It's critical to note that a number of template security protocols have been defined in recent years, and this method may not be ideal. For the purposes of this paper it is considered at best a working design. It is also possible to consider homomorphic encryption for the template, a method where data is encrypted and never decrypted as part of the verification process. Homomorphic encryption is undergoing extensive R&D currently and may prove the best method in the future for securing biohash templates.

The design of the system also allows for the creation of various special purpose (used for one purpose only once) and non-special purpose (used for anything) sub-IDs linked to the primary ID, which will be outlined in the next section.

The protocol must (eventually, though not in the initial POC design) allow for alternative biometric markers as a backup, should a person have only one eye or none. This creates unique and difficult challenges in that it allows for various attacks by using Hollywood style makeup, which could allow a user to attempt to create two IDs. These will not be discussed in great detail, however. There are also other potential attacks on the system such as constructing fake eyes, but these may be mitigated by " liveness tests and/or anti-spoofing tests" and will require further considerations, perhaps requiring a user to show their face and wave their hands, etc., as well as various fuzzy logic and reputation-based algorithmic defenses. Since we are also building a legal framework, we may choose to empower a government organization with the power to repudiate or test biometric markers in court.

We will sidestep these limited scope attacks for now and assume there are sufficient defenses against them, since researchers have been addressing these type of techniques for years. Our concentration is on making a robust ID system that utilizes both eyes.

A private, bonded, proof of stake agency may be the key to allowing alternative biomarkers as an option in the future, which can verify that a person is missing the required biometric markers and issue a one-time code to create an alternative ID based on different biometric markers. However, other biometric markers have a number of problematic characteristics. For example, a person's fingers can be swollen, cut, damaged, sweaty, etc, all of which creates variance, which in turn creates different inputs and hence different keys. In addition, all of a person's fingerprints would need to be entered to prevent multiple IDs being created, which is cumbersome and time consuming.

For the time being, we will simply say that the system may choose to allow for additional and/or replacement biometric markers to provide weight and "reputation" to the original ID or to replace a non-recoverable or stolen ID by flagging a lost ID as permanently blacklisted. Candidates for secondary biomarkers include, but are not limited to:

• Voiceprint
• Retinas
• DNA
• Palm prints
• Fingerprints

Again, all of these present special problems and will not be considered further here, although they may be addressed by the project at a later time as good solutions become available through research and development.

Diagram of Proposed Iris Enrollment/Creation Procedure

Outline of Proposed Ste

ps for Enrollment in the System

• Enrollment software boots an encrypted microkernel that checks for live network connectivity through a series of tests, using randomly generated secret information, challenge/response, pings, time checks against the blockchain, and TLS-connected NTP servers
• After ensuring network connectivity, the microkernel checks the software blockchain to ensure its binary hash matches, as well as the correct, current protocol version, and any other checks deemed necessary to ensure the system is running the latest, unmodified code
• If a pair of Irises is already enrolled, the system should check the user's password with challenge/response and refuse to boot if the password is incorrect after a series of n failures
• Should any of these checks fail, the system should refuse to boot
• System boots and is ready to scan the irises
• Irises are lined up and scanned
• Additional anti-spoofing tests are conducted
• The protocol enhances the raw image through filters
• Critical unique "minutiae" points are extracted
• The center or core point of the image and its corresponding radii are identified
• The type, angle and position for each minutiae point with respect to this coordinate system are calculated
• The entire iris print configuration is mapped into a string of bits known as a biohash.
• The biohash is tested against the Biohash blockchain to check whether it already exists, to prevent double enrollment

• If the biohash does not exist:

2A. Random bits of the biohash are deleted. Homomorphic double encryption techniques may be used to create a secure biohash iris (SBIOH-I) 2B. The SBIOH-I is projected into the biohash blockchain 2C. HUID creation begins 1. The user is prompted to create a password, using a rainbow table blacklist to prevent easily guessable passes and enforce password complexity 2. The user is also (potentially) prompted for a secondary "coercion resistance" password, which can be given in the event of violence against the individual and which gives the appearance of having reset the ID, but which silently discards the new data 3. A random set of challenge questions for resetting the ID and password is also generated 2. Answers and a one-way, non-invertible hash of the password are stored with the biohash in the biohash blockchain 3. The biohash is used to seed a PRNG, which in turn is used to generate a main public/private key pair (PUBID,PRIVID) 4. An "info wallet" is created for local storage of keys 5. The public ID is created from a secondary hash function against the public key, just as with Bitcoin. The PUBID is NOT the HUID. 6. The public key and HUID are projected into the HUID blockchain, separate from the biohash blockchain.

• If the biohash already existd in the biohash blockchain

3A. The user is asked whether they are attempting to reset or recover their biohash IF NO End 3B If YES: 3B1. Start reset process 3B2. Prompt for password

3D. IF COERCION PASSWORD RECEIVED: 3D1. Silently discard updates but provide identical messages and confirmations to the users to ensure their safety in the face of an attack 3E. IF RESET PASSWORD RECEIVED 3E1. Allow new biohash data to be projected into the biohash blockchain and start the process of generating and replacing a new public/private key 3E2. Do not delete old biohash data, simply add the new data to a new spot in the chain and set to flag any bit that labels previous biometric data as obsolete/defunct 3E3. RETURN TO NEW ENROLLMENT PROCEDURE

Use of the HUID in the System

The HUID is immutable to the individual and cannot be changed. It is unique, even in twins. It can be augmented or potentially replaced with additional biometric markers such as voiceprints, spectrum readings, DNA hashing, iris scans, and the like, which would add additional "weight" or "reputation" to the initial ID as the ID is used over time, as a backup for proving ownership. As defined by this system it can even be resilient to changing characteristics such as age or scarring.

The HUID underpins the system and allows arbitrary capabilities to be tied to the HUID, through linking to additional tokens or capabilities, without being reliant on a central authority to secure an unsecurable number such as an SSN, which must be given to those authorities. This creates a weakness whereby any compromise of that authority is a compromise of the number itself.

The HUID allows for a 1-to-1 voting token to be assigned to a person and rights and capabilities to be assigned to an HUID, such as the rights and protections of citizenship in a particular country or the rights of an individual in a company or collective/co-operative.

In the Direct Democracy system, a voting token is taken from an anonymous pool of voting tokens and assigned temporarily each time the citizen votes. This token is then routed through a decentralized mix-net and released, preserving voter anonymity. The token is assigned on a one-to-one basis to the anonymous voting sub-ID linked to the HUID. The voting right represented by this token can be taken by a centralized law body, or automated law entity, but the ID itself remains with the individual indefinitely and cannot be taken or corrupted. The voting token is separate and associated on a 1:1 basis with the HUID.

Some research into using biometrics for cryptography allow for the deletion of the private key, which prevents it from needing to be stored by the end user and keeps it from being compromised. This method does create some challenges though in that it likely removes the essential password component and requires the person to continually scan their biometrics to use it. While this method holds some promise, unless an answer to the password problem is discovered it is likely unworkable. However, if it is feasible, and an attacker does manage to spoof the system, then they will not be able to do it for long, as only the person with the actual biomarker that made the HUID can prove their right to that HUID in court. This will virtually eliminate fraud.

Sub/IDs

A crucial component to the privacy of the system is that it allows the creation of sub-IDs. These sub-IDs (SIDs), linked to a HUID/SID, enable people to join or leave a group. They could be an ID that marks you as a citizen or an employee or as one of the Nielson raters, or as a game player in a MMORP. These sub-IDs also provide anonymization or unlinkability through blind signatures and/or zero-knowledge proofs. The signature is a single piece of secret data that can prove that someone's primary ID is linked to the sub-ID without revealing the primary ID. The sub-IDs should also allow for RBAC (role-based access control) to personal data. For example, a sub-ID may grant access to only a phone number, name, and email address but not an HUID or SSN. The sub-IDs can also be generated with zero privileges, allowing access to none of the user's information, but still allowing the user's identity to be verified via an embedded secret that can be verified via challenge response. So an application could demand that a user prove who they say they are and the client could then reveal that they know the secret information via a prompt, proving their identity but not revealing their PII. The system may also choose to use non-interactive zero-knowledge proofs (NIZK), which prove ownership/identity without even having to prompt the user.

The system will also require single-use sub-IDs (SUSIDs). For example, to link an HUID to a NodeID (which IDs a client to the network) while simultaneously protecting the identity of the user and preventing that user from creating multiple nodes for themselves, we create a protocol for single use sub-IDs that, once generated, cannot be generated again without revoking the original HUID and banning the original NodeID on the network, rendering the client unusable. A flag is set in the HUID blockchain that this single-purpose sub-ID slot is filled with a Boolean yes/no. If the flag is marked "no," the program will not allow the creation of a new sub-ID. In the event of compromise, the sub-ID can be deleted and generated again. This sub-ID presents some serious design challenges and the authors may not have worked out all major attacks against it, but the general concept should allow for solving the unique ID + anonymity problem if all attacks are considered carefully and appropriate countermeasures are created from the beginning.

RBAC sub-IDs have the potential to revolutionize our current, overly centralized, and brittle system of keeping everyone's PII on web servers and private databases for verification purposes. Our current system of information security is a house of cards. In order to prove that you are who you say you are, an entity such as a bank or a website has to keep lots of data on you. They have to keep that data secure and you have to trust that they can keep it secure. And yours is just a speck in the data they have to store, so they become a target-rich environment for attackers, be they individual hackers or a nation state. Why rob one man on the street when you can rob a bank? This is why we see major data breaches in the news virtually every day.

Anyone who has worked in the field of IT for any length of time knows a dirty secret: it's virtual impossible to keep an IT environment entirely secure, even when you have massive amounts of capital and human resources and a culture that respects security. Very few entities are Google or VISA, with the ability to effectively manage all of their systems. The chances of most big companies securing everyone's data are essentially zero. Modern systems are too complex, with too much code and too many variables, be they people or systems. The solution to this is not better security for central stores of data. The real solution is simple: Don't store that data centrally in the first place.

Organizational Identities

The system also uses identities for "spheres" or groups within the system, borrowing the concept of "compound identities" from the paper Decentralizing Privacy: Using Blockchain to Protect Personal Data . It assigns a single general purpose ID to an entity, such as country, state, company, local sewing circle, etc.

Each organization would have its own public and private keys, its Organizational ID made from a hash of the public key, as well as its own signatures for message transmission, as will be described in the Networking section. An organizational structure might require Multisignature Keys for specific types of transactions, such as access to the corporation's various cryptocurrency wallets. Additional actions may require the fulfillment of smart contract rules in order to complete a transaction, such as transferring shares of ownership between members in a corporation.

Those entities can then create provable but unlinkable RBAC sub-IDs, just as individuals can, for individual parts of an entity, such as a department or individual set of employees or for transacting privately with other businesses or other organizations in a private fashion.

Administrators are linked to organizational spheres. They control who can join or access certain spheres and their functions and privileges. Joining a sphere may be manual or automatic. For instance, an automatic system might require you to pass a test or provide proof of some particular bit of ownership, knowledge of a passphrase, or maybe even simple geolocation data over time to prove you exist in a specific area. This is discussed later in the creation of citizenship tests that can automatically grant people rights within a nation state.

For smaller spheres, such as a club or corporate entity, administrators can be designated during and after the entity's creation. Sub-IDs or HUIDs are granted access over the various functions of that sphere, which allows administrators to control who can and cannot join.

For example, a private comic book collecting group might have a simple structure whereby the creator of the sphere designates himself and a second ID as the administrators with "yes" or "no" access when a HUID or sub-ID requests to join. They may also have additional capabilities, such as the power to grant voting rights or take them away.

A company might have a more complex governing RBAC structure. The initial creation of the structure might designate board members or founding members as admins, with varying tiers of power, and give them the rights to grant administrator rights to other employees, such as HR staff. The admins would bring on or terminate employees through their administration console. Admins can also use that power to grant rights to various employee HUIDs, such as stock allocations, percentage of voting rights in the organization, pay tiers, access to various systems/documents/data, access to VPNS, and other day-to-day rights and privileges of company employees.

Backup keys or universal keys to ownership of an organizational entity can be held in a smart contract that has rules to follow in the event that no more administrators are available, critical employees are terminated, or ownership is transferred. Careful analysis of the design of such a framework will need to be carried out during the project's design session so there is a simple, reusable methodology that can be adopted by other organizations.

The organizational templates should be stackable, or able to draw from various baseline templates in a layered fashion, making the drag-and-drop creation of new entities easy. The rulesets governing such a template could be hierarchical, with custom rules at the top overriding generic language at a lower level.

Even more complicated organizations like a nation state might have designated trust groups that can grant or remove rights from its citizens, such as for violations of the law. A nation-state organizational entity might have the power to rescind voting rights under specific circumstances or to reinstate those rights, which would set flags in the blockchain that allow or disallow certain actions.

Info Wallets

Info wallets are encrypted private information stores that are held offline. This information wallet might store personal details which can be selectively shared with an organization or not, based on their sub-IDs, which can grant role-based access control to personally identifiable information (PII) OR the individual can share proof that they own a particular piece of data WITHOUT sharing that data through a blind signature and/or zero-knowledge proof. This allows for strong security in that centralized entities no longer have to keep vast troves of personally identifiable information. They can be backed up and additionally secured as necessary. A great deal of clever thinking on Bitcoin wallet security will benefit this effort as well. It seems that every day people are coming up with easy to manage Bitcoin wallets from hardware wallets to brain wallets that harken back to the cyberpunk masters of yore.

Distributing the PII back to the individual forces attackers to attack millions of small areas instead of a large, target-rich environment. Web companies and other centralized entities will no longer have information on site to steal.

Blockchain/Distributed Ledger

A central ledger is a blockchain, such as Hyperledger, Bitcoin's blockchain, or Ethereum's blockchain, which is similar to hashchain technology but has several unique properties. Whereas a hashchain is a method of consensus among parties that already know and trust each other, a blockchain is a distributed cryptographic chain of record in a system that is used by untrusted entities to form agreement. A hashchain requires that everyone generally trust each other, such as a local charity group that wishes to vote on where to have their next party. A blockchain is a trust machine, to be used as a way to drive consensus between parties that may not always see eye-to-eye. Parties in the transactions may be friends, rivals, enemies, but the chain acts as a way to govern the protocol of their interaction. In essence it acts as a trust mitigator in the event of a dispute. Nodes in a blockchain decide on consensus for canonical transactions to the system. Transactions may be conducted off-chain such as outlined by the Lightning Networks, a cascading, time-locked smart contract system, with the chain acting as an arbiter of disputes. The system will utilize multiple blockchains, with a primary "blockchain of blockchains" with pointers to smaller chains that can be archived for retrieval later.

Blockchain of Blockchains

This project uses a central, established blockchain as a source of truth to store pointers to other blockchains. This could be a custom blockchain crafted for this project alone. It could be built upon the rapidly expanding codebase of an existing project such as Hyperledger or Ethereum. Or i

---

README truncated. View on GitHub