You can find the whitepaper here.

• Release date: 11PM EST, 18th January 2014 / No premine
• X11 hashing algorithm: 11 rounds of scientific hashing functions (blake, bmw, groestl, jh, keccak, skein, luffa, cubehash, shavite, simd, echo)
• Block reward is controlled by: 2222222/(((Difficulty+2600)/9)^2)
• CPU/GPU mining
• Block generation: 2.5 minutes
• Difficulty Retargets using Dark Gravity Wave
• 7.1% decrease in the number of coins generated per year
• Est. ~18.9M Max Coins
• Decentralized Masternode Network
• Superior Transaction Anonymity using PrivacySend
• Decentralised Governance
• Instantaneous Transactions via InstantSend

In addition to traditional Proof of Work (PoW) rewards for mining Dash, users are also rewarded for running and maintaining special servers called masternodes. Thanks to this innovative two tier network, Dash can offer innovative features in a trustless and decentralized way.

Masternodes primary function is to carry out the anonymization phase of the Darksend protocol and to validate transactions almost instantly. In the future, there will be more services performed by the masternodes network.

In return for providing this services, one masternode is selected by the network to receive a part of the reward of each mined block.

In order to run a masternode, a user must put up 1000 DASH as something akin to collateral, though unlike traditional collateral, the Dash never leaves the user’s possession. It can be moved or spent at any time by the user – doing so simply removes the masternode from service and makes it ineligible to receive rewards.

PrivateSend is the feature that gives Dash users full privacy when they use it. It is an improved and extended version of the CoinJoin. In addition to the core concept of CoinJoin, we employ a series of improvements such as decentralization, strong anonymity by using a chaining approach , denominations and passive ahead­of­time mixing.

By having a decentralized mixing service within the currency we gain the ability to keep the currency itself perfectly fungible. At the same time, any user is able to act as an auditor to guarantee the financial integrity of the public ledger without compromising others privacy.

PrivateSend uses the fact that a transaction can be formed by multiple parties and made out to multiple parties to merge funds together in a way where they can’t be uncoupled thereafter. Given that all Darksend transactions are setup for users to pay themselves, the system is highly secure against theft and users coins always remain safe. Currently to mix usingPrivacyProtect requires at least 3 participants.

To improve the privacy of the system as a whole we propose using common denominations of 0.1DASH, 1DASH, 10DASH AND 100DASH. In each mixing session, all users should submit the same denominations as inputs and outputs. In addition to denominations, fees should be removed from the transactions and charged in bulk in separate, sporadic unlinkable transactions.

PrivateSend is limited to 1000 DASH per session and requires multiple sessions to thoroughly anonymize significant amounts of money. To make the user experience easy and make timing attacks very difficult, PrivateSend runs in a passive mode. At set intervals, a user’s client will request to join with other clients via a Masternode. Upon entry into the Masternode, a queue object is propagated throughout the network detailing the denominations the user is looking to anonymize, but no information that can be used to identify the user. Each PrivateSend session can be thought of as an independent event increasing the anonymity of user’s funds. However each session is limited to three clients, so an observer has a one in three chance of being able to follow a transaction. To increase the quality of anonymity provided, a chaining approach is employed, which funds are sent through multiple Masternodes, one after another.

For a more detailed explanation, please refer to the Dash Whitepaper.

This paper introduces a new concept called InstantSend (transaction locking and Masternode consensus). This technology will allow for cryptocurrencies such as Dash to compete with nearly instantaneous transaction systems such as credit cards for point-of-sale situations while not relying on a centralized authority. If successful, such an idea could revolutionize cryptocurrency, by shortening the delay in confirmation of transactions from as long as an hour (with Bitcoin) to as little as a few seconds.

Download the paper here or read below.

Transaction Locking and Masternode Consensus: A Mechanism for Mitigating Double Spending Attacks

X11 is a widely used hashing algorithm created by Dash core developer Evan Duffield. X11’s chained hashing algorithm approach utilizes a sequence of eleven scientific hashing algorithms for the proof-of-work. This is so that the processing distribution is fair and coins will be distributed in much the same way Bitcoin’s were originally. ASICs will be much more difficult to make for these algorithms and should take years.

With chained hashing, high end CPUs give an average return similar to that of GPUs. An added benefit of the algorithm is that GPUs require approximately 30% less wattage and run 30-50% cooler than they do with Scrypt.

Dark Gravity Wave (DGW) is a widely used mining difficulty adjustment algorithm created by Dash core developer Evan Duffield to address flaws in Kimoto’s Gravity Well.

In response to unforeseen issues with the rollout of RC3, the Dash development team created a mechanism by which updated code is released to the network, but not immediately made active (or “enforced”).

Communication is sent out to users informing them of the change and the need for them to update their clients. Those who update their clients run the new code, but in the event of errors occurring with that new code, the client’s blocks are not rejected by the network and unintended forks are avoided. Data about the error can then be collected and forwarded to the development team. Once the development team is satisfied with the new code’s stability in the mainnet environment – and once acceptable network consensus is attained – enforcement of the updated code can be activated remotely. Should problems arise, the code can be deactivated in the same manner, without the need for a network-wide rollback or client update.

This innovation allows for far smoother transitions than in the traditional hard fork paradigm, as well as the collection of test data in the live network environment. We set out with the intention of calling this method of updating the “Soft Fork”, but the Dash community quickly dubbed it the “Spork” and the name seems to have stuck.