This post is intended revise that proposal with my current notes and provide a digestible version that is a starting point for people to ask questions. I'm going to approach this with the same tactic as a famous gaming company and use The Four Pillars of Decrits as topic points.
Notes: Every time I use a number or a percentage, assume that figure is up for debate. I apologize for using a lot of acronyms, I hope it makes this easier to read. I am terrible at creating terminology, so please feel free to make suggestions. If you think an important detail is missing, please ask the question rather than pointing it out as a weakness or failure--I am glossing over a lot of details for brevity and to promote easier discussion.
1. Securing the Network Without Proof-of-Work: Reaching and Maintaining Proof-of-Consensus
- A. The Consensus Block (CB) The CB, at its core, is simply just a merkle-root hash? that 100% of Shareholders have agreed is the hash of the entire state of the network at a certain point in time. Disagreements are resolved by providing cryptographic proof. A CB point is locked in every 10 Consensus Days (CDs), which are periods of 87,660 seconds or 1/360th of 365.25 regular days. Network time will be roughly agreed on by using NTP pool.
- B. Consensus by Shareholders Consensus is determined by a group of peers called Shareholders (SH). Anyone may purchase shares in the network with Decrits using a special transaction? and become a SH. The price of each share will be a meaningful amount (intended to be in the range of 3,000-5,000 USD), and this money is locked for a period of at least 1 Consensus Year (CY - 360 CDs), automatically renewing unless a SH declines to renew. Each SH will be selected to provide a Transaction Block (TB) for a specific 10 second period during each CB. Each new TB will acknowledge the last seen TB, and the SH that created it will sign the CB along with a hash of the changes to the network state as of that moment. Note: When there are less than the number of SHs required to make a TB each 10 seconds each CB, SHs will have to make more than one during a CB. When there are more, some SHs will confirm the TBs of others.
- i. Shareholder Incentives SHs are primarily incentivized by receiving 50% of the transaction fees collected by the network. Transaction fees are 0.01 Decrits or 0.01% of the transaction amount, whichever is greater. SHs earn Shareholder Reputation (SR) as they perform their duty to the network without incident. This reputation is used to determine what percentage of transaction fees they will receive. The highest reputed SH will earn no more than double the lowest, and the SR system will only be on a scale of 2-3 CYs of service (e.g. after 3 years you are among the highest reputed).
- ii. Shareholder Disincentives Reaching 100% consensus is of utmost priority. If a SH misses his TB, he must sign the prior CB within the next 10-20 CDs (depending on when he needed to create a TB). If he does not, his share will be destroyed, including the money associated with it. Missing a TB but then signing the CB results in a soft strike. If three soft strikes are received in one CY, the SH will be removed from consensus with his share returned less a 25% penalty which is destroyed. Creating a bad block (a second TB for the same time period or one that contains a bad spend) will also result in the share and money being completely destroyed.
IMPORTANCE: Securing the network requires only the energy needed to validate transactions, the bandwidth needed to distribute them, and the storage to hold the network state. No proof of work is necessary, therefore the amount of energy required to secure the network is magnitudes lower than Bitcoin. Using an account ledger instead of a transaction ledger means that both storage and bandwidth requirements are also significantly reduced. Transactions will be typically confirmed in 5-15 seconds depending on network propagation lag, though if a TB is missed they may take an additional 10 seconds. As long as the TB chain is unbroken, these transactions are secure unless a massive network split occurs within the next 10-20 CDs before it has been accepted into the CB and signed by 100% of the consensus. Even then, as with bitcoin, unless your transaction is being specifically targeted, it should still be secure.
2. Decentralizing the Network: Incentivizing Network Propagation, Preserving Anonymity, and Checks and Balances
- A. Primary Network Propagation via the Cloudnet (CN) The Cloudnet is a group of peers called Cloudnet Peers (CNP). Anyone may become a CNP by creating a special transaction that includes an IP address (IPv4, IPv6, tor, i2p), an asymmetric encryption key, a public key, and a deposit of 1/20th of a share. This information is stored in the CB. A CNP will be able to retrieve his deposit fairly easily but with some restrictions to deter abuse. New CNPs will make efforts in connecting to several other CNPs, and they will accept and retransmit new transactions and network data as well as provide an access point for Cloudnet Clients (CNC - "light" clients) to retrieve (provable) portions of network data.
- i. Cloudnet Peer Incentives CNPs are primarily incentivized by receiving the other 50% of transaction fees collected by the network. A portion (10%?) of these fees will be distributed based on Cloudnet Peer Reputation (CNR) which is gained by being in the top 90% of credited CNPs during a random interval of the previous CB. CNPs receive credit by CNCs who use their identification code in a transaction. The other 90% of the fees will be distributed in a bracketed manner (slight bonus to the top, slight penalty to the bottom) towards those who were credited with transactions during that random interval.
- ii. Cloudnet Peer Disincentives CNPs are required to provide a public key so that their identity may be proven to a CNC. A CNC may request that a CNP sign information retrieved so that the CNPs deposit is destroyed for providing provable disinformation. CNPs will lose reputation over time if they are not credited during the random intervals.
- iii. Shadow Peers Shadow Peers (SP) are CNCs that dedicate some bandwidth to transmitting network activity between other SPs. SP information will be given out very sparingly by those that request it of CNPs. In the event of a major DDoS attack against the published CNP addresses, SPs will continue to transmit network activity.
- B. Preserving Anonymity of CNCs Providing an asymmetric encryption key allows CNCs to connect to CNPs in a completely encrypted handshake process, preserving anonymity against outside observers. The public key provided by the CNP will ensure that no man-in-the-middle attack can be taken against a CNC. The default CNC implementation will provide a weighted but random system for determining whom to credit to preserve CNC->CNP anonymity. CNCs can trade bandwidth for privacy and retrieve blocks of information rather than account-specific information. Support for tor and i2p should be part of the protocol from the start to allow for "preserved anonymity" connections that can operate with much less bandwidth and only send or retrieve necessary information.
- C. Preserving Anonymity of CNPs (and SHs) CNPs will often have to associate IP addresses with account numbers when joining or cashing out of the CN. This is terrible for privacy-minded people and they should not have to be forced to use some outside "laundry" service to disassociate this connection. To provide this, buy-ins and cash-outs may be performed with blind transactions (invented by Chaum). More detail here.
- D. Checks and Balances Transmitting network data is a voluntary activity by each CNP. If a significant group of SHs are intent on disrupting the network, CNPs do not have to transmit their TBs. This means, assuming enough CNPs agree that disruption is being attempted, honest SHs down the road are unlikely to see the disruptive blocks (e.g. ones that drop all transactions or do not include important transactions). This will cause strikes to be accrued against disruptive SHs and potentially destruction of their deposit. This is an effective and decentralized deterrent against malicious SH activity.
IMPORTANCE: Being a transmitting node pays dividends. This encourages as many people as is profitable to transmit data for the network. The group securing the network is balanced by a different and larger group transmitting for the network; the "powers" are separate. Bitcoin transaction fees can be lower if transmitting nodes are fewer because the miners are the source of approved transactions as well as the price of transaction fees. Because transaction fees are set with Decrits and the costs of securing and transmitting are low (no mining), the securing and transmitting parts of the network will expand as transactions increase. The Decrits network is encouraged to become more decentralized as it expands. The Bitcoin network is encouraged to become less decentralized as it grows because transaction fees can be reduced as less energy is required to secure the network. Since energy is not required for Decrits' security, many, many more people can participate. With Bitcoin, the more people that participate, the higher the transaction fees must be.
3. Creating Money: Making it Stable and Energy-Efficient
- A. Producing a Mint Block (MB) A Mint Block is a potential block of money that can be created by the network if several prerequisites have been met: 1) Sufficient transaction activity has occurred since the beginning of the last MB, 2) The current/prior MB has been completed, and 3) Between 5 and 10% of the MB's monetary award must be "burned" by potential minters in a limited time frame to join the Mint Block Queue (MBQ) to create new money. The MBQ is joined individually by those wishing to create currency and each queuer will be assigned to create 2-3 coins. A full MBQ proves to the network that sufficient demand for new currency exists and sufficient power is ready to create it. More details. These restrictions place a brake on unbound monetary creation.
- i. Adjusting Difficulty Difficulty is adjusted after each MB by dropping the 25% fastest and 25% slowest queuers to create currency, and comparing the middle 50% to the current difficulty. A speed increase will directly reduce the award of the MB (e.g. if speed increased 3%, each coin produced will award 3% less). This is so that technological advances that create profitability, not economic demand, are disincentivized. The next MB's difficulty will be adjusted based on a weighted scale of the last 10 MBs. This is so that it requires a sustained change in the power of the network to really increase the difficulty. Difficulty will never decrease; producing a block more slowly than expected will simply set the increase at 0%.
- ii. Minting Incentives and Disincentives To avoid difficulty stagnation and to penalize those who join the queue more times than their system can reasonably handle, queuers who create coins in the top 50% will receive additional money while those in the bottom 50% will take penalties. The initial idea for this is also described in this post. However, to avoid potential ways to game the system (including using ASICs), each queuer will be compared with a random sample of his peers rather than the whole MBQ. There are other designs that increase the profitability of being honest* (or reduce the profitability of being dishonest) that go a bit beyond the scope of this document.
- B. Producing Energy Efficient Currency All of the difficulties associated with minting are in place so that new currency is created only when the value of Decrits are profitably above their cost to produce. However, this is not at all energy efficient. To provide energy efficiency in currency creation, free money will be distributed to users of the network (not minters) based on minted money. 5x the MB award will be given to either the sender or receiver of a random set of transactions during a certain time frame before (and potentially after) the MB based on multiples of the tx fee; 5x will be awarded to a random selection of accounts based on each account's percentage of the total amount of currency in existence. If a second MB is started within a time window of the first, these multiples will increase to give out more free money in response to network expansion. More details: at the end of this post and here.
- C. Achieving Stability and Reducing the Hardware Tax The intent of the complicated process of minting currency is to provide a stable cost to produce new currency. This in turn, I believe, will result in a reasonably stable value when compared to other commodities--perhaps even providing a stabler value compared to the whole basket than many or most other individual commodities. This requires a deeper explanation for the reasoning behind the design decisions which will be provided in the next post.
* - I use the term "honest" to mean network users whose actions do not threaten the stability or security of the system. I use this in a very general sense--the network itself will not specifically identify or penalize users it thinks are dishonest, but it will make their actions more obvious and it will give time for honest users to respond. I will go into detail in the next post.
IMPORTANCE: To provide a strong base for a currency, people must want to use it as currency. People must also be able to create it as necessary in the face of economic expansion or manipulation. Hoarding can not manipulate the price upwards because minters can create new currency in response. During network expansion, transaction activity will receive a greater amount of new currency (in terms of award to volume) than minting or hoarding. This encourages both spending and accepting Decrits--and without the dire need for businesses to convert back to fiat. When the network is stable, hoarding offers no incentive over stuffing a non-price inflationary currency under a mattress.
4. Creating a Dynamic Network: Making it Scale and Adapt by Providing a Decentralized Foundation for Modifying the Network
- A. The Voting System SHs and CNPs will be allowed to propose changes from either a predefined list of voting options or by proposing changes to the core code. The core code will be part of the Consensus Block so that updating to new code "on the fly" will be possible. Core code changes will not pass unless a 90% majority of SHs and CNPs agree. If less than a 90% majority agrees, it is possible for the network to peacefully split and allow one way transactions from the old to the new network for some period of time. This is another extensive topic that will be detailed in a future post.
IMPORTANCE: A sufficiently large network simply cannot and should not rely on a core group of developers as the only source of the reference implementation. By providing the core code within the network, "hard forks" are an issue of the past. Those wishing to fork the network can do so peacefully and retain value from the existing network. If many people (not SHs or CNPs) agree that the idea is better, they may transfer currency over to the new network. Future, unforeseen changes in the world or in cryptography may require quick and decisive action from the network. Waiting for millions of clients to update to new software or thousands of miners (or maybe only tens or hundreds in the centralized way Bitcoin has gone so far) is not acceptable in the face of major problems.