Fix typos #1

HansHauge · 2017-01-10T20:56:05Z

There is also a broken link to http://enigma.media.mit.edu/

This diff is kind of hard to read in places. I will add comments to clarify.

There is also a broken link to http://enigma.media.mit.edu/

HansHauge · 2017-01-10T20:56:29Z

README.md


 # 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&#39;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&#39;s information, but still allowing the user&#39;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)](https://people.eecs.berkeley.edu/~sanjamg/mc/scribe/lec10.pdf), which prove ownership/identity without even having to prompt the user.


a MMORP => an MMORPG

HansHauge · 2017-01-10T20:57:01Z

README.md


 **This 1-to-1 ratio makes the protocol essentially evenly distributed forever, with no one pool of servers or people controlling the power of the platform. This essentially eliminates the 50% problem**.  **It also has the added benefit of creating a built-in ** [**Universal Basic Income**](https://en.wikipedia.org/wiki/Basic_income)** (UBI) as a reward for participation in the system.**

-How does it work? It builds on the idea of the distributed hash table of the  [Kademlia](http://xlattice.sourceforge.net/components/protocol/kademlia/specs.html) P2P network, popularized by 3rd gen P2P systems like BitTorrent. Each client/server is assigned a NodeID stored in the distributed hash table of all systems on the network. Now lets take something like the Bitcoin system, which updates its blockchain every 10 minutes with a new block, which we will call the &quot;block epoch.&quot; During those 10 minutes, transactions are broadcast to the network and miners gather them up into  [Merkle Trees](https://bitcoin.org/en/glossary/merkle-tree) and then compete against each to to solve a Proof of Work problem to win and release newly created coins and collect all the transaction fees from the last block epoch.


like BitTorrent. => like BitTorrent.

HansHauge · 2017-01-10T20:57:35Z

README.md


 It is also worth considering a reputation system for miners that allows reliable miners to be called on more regularly. However, any such system must be carefully weighted so as not to allow the same miners to consistently drive all traffic. Trust would be defined algorithmically, for example based on whether the node responded to all requests throughout time, whether it ever had malformed packets or out of date software, whether its binaries have ever been altered from standard hashes, the node&#39;s speed, dropped packets, etc. This idea is outlined in more detail in the Networking section. Nodes could be less likely to receive requests if they have issues or a low reputation rating or even blacklisted if they have repeated issues such as compromised software, altered binaries, etc.

-**Lastly, blockchains can grow very large, so how would a small client like a cell phone store the whole blockchain? The answer is none of them would need to at all. Instead, clients need to keep only a current subset of the most recent transactions and the rest of the blockchain is sharded up and replicated in pieces to all clients, so that each client is responsible for storing a small portion of the historical blockchain. ** If nodes drop out or go offline a shard may be replicating temporarily from an existing node to maintain a proper percentage of the chain to avoid losing any piece of it. Because other nodes contain redundant instances of that particular shard, all of the instances would have to be destroyed to destroy that part of the blockchain, which makes the protocol space efficient and able to run and be stored on a mobile device. In addition, the blockchains could be backed up by anyone or by a backup company to keep the system safe in the case of total disaster and to allow for restoration later, while providing evidence of their completeness. Lookups would use a DHT to find which nodes currently hold the necessary part of the blockchain for a lookup, should an old transaction need to be verified, and multiple clients would be checked to ensure accuracy.


very large, so how would a small client like a cell phone store => very large. So, how would a small client, like a cell phone, store

HansHauge · 2017-01-10T20:57:58Z

README.md


 Now that we have a general understanding of the essential Kademlia concepts, which you can dig further into at the design site, we can shift to how to enhance and improve the basically sound framework provided by the authors.

-Much of our thinking on how to improve the networking of the DD platform comes from the excellent research paper called &quot; [S/Kademlia: A Practical Approach Towards Secure Key Based Routing](http://www.tm.uka.de/doc/SKademlia_2007.pdf).&quot; The authors go a long way to creating a secure version of Kademlia, outlining a number of attacks (briefly summarized below), as well as excellent though incomplete solutions to these attacks. However, this project deviates from the thinking of the paper in one key aspect:


" [S/Kademlia: => "[S/Kademlia:

HansHauge · 2017-01-10T20:58:24Z

README.md


 Lastly, because new nodes cannot be very efficiently evaluated beyond software version, IP address reputation, etc, the Cicada platform includes a grace period for new nodes.

-The ratings for nodes must be continual. As Kohnen notes in the TrustedKAD paper, it is necessary to continually &quot;rate the behavior of a node and to avoid interaction with it if it does not behave correctly,&quot;


correctly," => correctly."

HansHauge · 2017-01-10T20:59:04Z

README.md


 **We can use David Chaum&#39;s ** [**PrivaTegrity**](https://eprint.iacr.org/2016/008.pdf) ** as a template here. He proposes a scalable mixnet called cMix to provide unlinkability and secure communication. In the Cicada network, nodes are randomly drafted into MixNets, which differs from Chaum&#39;s design which relies on centrally trusted servers.**

-**Chaum also provides a novel but controversial universal decryption scheme. Universal decryption keys are generated and sharded up among nine different server farms in different geographies. If all nine servers agree, the sharded key is reconnected and we are able to decrypt communications on the network.** [This is to prevent something &quot;totally evil&quot; from being hidden](https://www.wired.com/2016/01/david-chaum-father-of-online-anonymity-plan-to-end-the-crypto-wars/). Once the keys are used, they are destroyed automatically, and new ones are created and sharded up again, so that the nine servers must again universally agree to decryption.


in different geographies. => in different geographical areas.

HansHauge · 2017-01-10T20:59:28Z

README.md


 **Vote Suggestion System**

-A system allows for suggestions on how to vote. Based on a question survey, such as demonstrated by the &quot; [I Side With](https://www.isidewith.com/)&quot; website, a set of basic rules can be created about how a person would particularly vote. The system would then examine the law XML and come to a conclusion, marking the document/proposal/bill/rule change with green/yellow/red based on how likely you are to agree with the majority of the provisions. This could eventually lead to an auto-voting system.


by the " [I Side => by the "[I Side

Fix typos

54a12a4

There is also a broken link to http://enigma.media.mit.edu/

HansHauge commented Jan 10, 2017

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fix typos #1

Fix typos #1

Uh oh!

HansHauge commented Jan 10, 2017

Uh oh!

HansHauge Jan 10, 2017

Uh oh!

HansHauge Jan 10, 2017

Uh oh!

HansHauge Jan 10, 2017

Uh oh!

HansHauge Jan 10, 2017

Uh oh!

HansHauge Jan 10, 2017

Uh oh!

HansHauge Jan 10, 2017

Uh oh!

HansHauge Jan 10, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant


		# 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)](https://people.eecs.berkeley.edu/~sanjamg/mc/scribe/lec10.pdf), which prove ownership/identity without even having to prompt the user.


		This 1-to-1 ratio makes the protocol essentially evenly distributed forever, with no one pool of servers or people controlling the power of the platform. This essentially eliminates the 50% problem. It also has the added benefit of creating a built-in [Universal Basic Income](https://en.wikipedia.org/wiki/Basic_income) (UBI) as a reward for participation in the system.

		How does it work? It builds on the idea of the distributed hash table of the [Kademlia](http://xlattice.sourceforge.net/components/protocol/kademlia/specs.html) P2P network, popularized by 3rd gen P2P systems like BitTorrent. Each client/server is assigned a NodeID stored in the distributed hash table of all systems on the network. Now lets take something like the Bitcoin system, which updates its blockchain every 10 minutes with a new block, which we will call the "block epoch." During those 10 minutes, transactions are broadcast to the network and miners gather them up into [Merkle Trees](https://bitcoin.org/en/glossary/merkle-tree) and then compete against each to to solve a Proof of Work problem to win and release newly created coins and collect all the transaction fees from the last block epoch.


		It is also worth considering a reputation system for miners that allows reliable miners to be called on more regularly. However, any such system must be carefully weighted so as not to allow the same miners to consistently drive all traffic. Trust would be defined algorithmically, for example based on whether the node responded to all requests throughout time, whether it ever had malformed packets or out of date software, whether its binaries have ever been altered from standard hashes, the node's speed, dropped packets, etc. This idea is outlined in more detail in the Networking section. Nodes could be less likely to receive requests if they have issues or a low reputation rating or even blacklisted if they have repeated issues such as compromised software, altered binaries, etc.

		Lastly, blockchains can grow very large, so how would a small client like a cell phone store the whole blockchain? The answer is none of them would need to at all. Instead, clients need to keep only a current subset of the most recent transactions and the rest of the blockchain is sharded up and replicated in pieces to all clients, so that each client is responsible for storing a small portion of the historical blockchain. If nodes drop out or go offline a shard may be replicating temporarily from an existing node to maintain a proper percentage of the chain to avoid losing any piece of it. Because other nodes contain redundant instances of that particular shard, all of the instances would have to be destroyed to destroy that part of the blockchain, which makes the protocol space efficient and able to run and be stored on a mobile device. In addition, the blockchains could be backed up by anyone or by a backup company to keep the system safe in the case of total disaster and to allow for restoration later, while providing evidence of their completeness. Lookups would use a DHT to find which nodes currently hold the necessary part of the blockchain for a lookup, should an old transaction need to be verified, and multiple clients would be checked to ensure accuracy.


		Now that we have a general understanding of the essential Kademlia concepts, which you can dig further into at the design site, we can shift to how to enhance and improve the basically sound framework provided by the authors.

		Much of our thinking on how to improve the networking of the DD platform comes from the excellent research paper called " [S/Kademlia: A Practical Approach Towards Secure Key Based Routing](http://www.tm.uka.de/doc/SKademlia_2007.pdf)." The authors go a long way to creating a secure version of Kademlia, outlining a number of attacks (briefly summarized below), as well as excellent though incomplete solutions to these attacks. However, this project deviates from the thinking of the paper in one key aspect:


		Lastly, because new nodes cannot be very efficiently evaluated beyond software version, IP address reputation, etc, the Cicada platform includes a grace period for new nodes.

		The ratings for nodes must be continual. As Kohnen notes in the TrustedKAD paper, it is necessary to continually "rate the behavior of a node and to avoid interaction with it if it does not behave correctly,"


		We can use David Chaum's [PrivaTegrity](https://eprint.iacr.org/2016/008.pdf) as a template here. He proposes a scalable mixnet called cMix to provide unlinkability and secure communication. In the Cicada network, nodes are randomly drafted into MixNets, which differs from Chaum's design which relies on centrally trusted servers.

		Chaum also provides a novel but controversial universal decryption scheme. Universal decryption keys are generated and sharded up among nine different server farms in different geographies. If all nine servers agree, the sharded key is reconnected and we are able to decrypt communications on the network. [This is to prevent something "totally evil" from being hidden](https://www.wired.com/2016/01/david-chaum-father-of-online-anonymity-plan-to-end-the-crypto-wars/). Once the keys are used, they are destroyed automatically, and new ones are created and sharded up again, so that the nine servers must again universally agree to decryption.


		Vote Suggestion System

		A system allows for suggestions on how to vote. Based on a question survey, such as demonstrated by the " [I Side With](https://www.isidewith.com/)" website, a set of basic rules can be created about how a person would particularly vote. The system would then examine the law XML and come to a conclusion, marking the document/proposal/bill/rule change with green/yellow/red based on how likely you are to agree with the majority of the provisions. This could eventually lead to an auto-voting system.

Fix typos #1

Are you sure you want to change the base?

Fix typos #1

Uh oh!

Conversation

HansHauge commented Jan 10, 2017

Uh oh!

HansHauge Jan 10, 2017

Choose a reason for hiding this comment

Uh oh!

HansHauge Jan 10, 2017

Choose a reason for hiding this comment

Uh oh!

HansHauge Jan 10, 2017

Choose a reason for hiding this comment

Uh oh!

HansHauge Jan 10, 2017

Choose a reason for hiding this comment

Uh oh!

HansHauge Jan 10, 2017

Choose a reason for hiding this comment

Uh oh!

HansHauge Jan 10, 2017

Choose a reason for hiding this comment

Uh oh!

HansHauge Jan 10, 2017

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant