Whitepaper


DOWNLOAD THE WHITEPAPER



DAGRA  v. 1.0 (Inception) — IS A CRYPTO CURRENCY FOR MASS USE WORKING ON THE SYSTEM OF DELEGATED NODES (MASTERNODS) WITH UNIQUE TECHNOLOGY OF DEVELOPMENT. CRYPTO CURRENCY CREATED ON THE BASIS OF THE OWN PLATFORM BLOKCHEIN

Artem Gurin –  president@dagrsol.ru


Abstract:

DAGRA – is a cryptocurrency with a built-in system of decentralized management based on delegate servers, extended PoSe (Proof of Service) model, instant and anonymous transactions.


 

Introduction.

Bitcoin – is a crypto currency, which became the first digital currency attracted by a significant number of users. Since its inception in 2009 Bitcoin has been developing rapidly in terms of mass use and commerce. The main problem with the adoption of Bitcoin in purchase and sale situations is the complexity of using by ordinary users and technical limitations in the form of a long time for the network to confirm the transaction. Some payment companies have created methods that allow sellers to accept transactions without their confirmation, but these decisions use a third party as a trusted partner to confirm the validity of the transaction and severely reduces the reliability of the system.

Bitcoin provides pseudonymous transactions in a public register with a single connection between the sender and the recipient. This ensures that all transactions that have ever occurred on the network are permanently recorded. Bitcoin is widely known in academic circles as a cryptocurrency with a low level of confidentiality,  although with  this limitation many people still trust their financial history to its blockchain.

All current cryptocurrencies that ensure the privacy of payment history are extremely difficult to use and therefore do not have a mass application.

DAGRA is the first cryptographic currency that implements private payments and high availability to all the benefits of cryptocurrency for the majority of the population due to extreme simplicity of use. In this article, we offer a number of improvements for Bitcoin leading to a decentralized, strictly anonymous cryptocurrency, with instant transactions protected against unauthorized access and a secondary P2P network of servers encouraged to provide services on the DAGRA network.

Network of delegate nodes (servers)

The full nodes are the servers working in the peer-to-peer network, which allows peers to use them to receive updates about events on the network. These nodes require significant amounts of traffic and other resources that carry a significant cost. As a result, Bitcoin network for some time there was a steady decrease in the number of these nodes, as a result of which the distribution of blocks was more  than  40  seconds.  Many solutions  have been  proposed,  such as the  new  Microsoft Research award system and the Bitnodes promotion program.

Figure 1: Number of full nodes in the Bitcoin network in the spring of 2014

These nodes are very important for the health of the network. They provide customers with the ability to synchronize and quickly distribute messages across the entire network. We propose to add a secondary network, known as the Delegates network. These nodes will have high availability and provide the  required level  of network  service in  order to participate  in the  Delegate  Reward program.

 

 

 

Delegate Reward Program – Costs and Payments

Most of the reasons for the decrease in the number of full nodes in the Bitcoin network is due to the lack of incentive to run them. Over time, the cost of running the full node increases as the network is used more, creating a greater load on the network bandwidth and increasing the cost of node maintenance for the site operator. As the cost increases, operators consolidate their services to be cheaper to maintain or run a light client, which does not help the network at all.

Delegate nodes are complete nodes, as in the Bitcoin network, except that they must provide a level of network service and have a mandatory deposit for participation. The pledge is never withdrawn from the operator and is safe while the delegate node is operating. This allows investors to provide network services, receive interest from their investments and reduce the volatility of the currency.

To run the delegate node, the node must store 1000 DGR (DAGRA). When they are active, the nodes provide services to customers on the network and, in turn, are paid in the form of a dividend. This allows users to pay for services and profit from the investment. Delegates are paid out of the same pool of money, about 45% (see footnote) of the total award of each block.

Due to the fact that the Delegate Reward program is a fixed percentage and the delegates network is subject to change, the expected reward of each delegate will vary depending on the current total number of active nodes. Daily payments for running a delegate node can be calculated using the following formula:

 

(n/t) * r * b * a

 

Where:

n – is the number of delegate nodes controlled by the operator t is the total number of delegate nodes

r – current block reward for (currently an average of about 25 DGR)

b – is the average number of blocks per day. For a Dagra network, this is usually 576 a is the average fee for all delegate nodes (45% of the average award per block)

 

Return on investment for launching delegate nodes can be calculated as:

((n/t) * r * b * a * 365) / 1000

 

Where the variables are the same as above.

 

The costs associated with running the delegate nodes create a hard and soft limit for the active nodes in the network. Currently, there are 3.3 million DGR in circulation, and only 3300 nodes can work in the network. The soft limit is determined by the acquisition price of the node, and limited liquidity on exchanges due to the use of DAGRA as a means of payment, and not just investments.

 

Deterministic order

 

A special deterministic algorithm is used to create a pseudo-random order of delegate nodes. Using a hash of proof-of-work for each block, the safety of this function will be provided by the network of miners.

Pseudocode, to select a delegate node:

For(delNode in delNodes){

n = delNode.CalculateScore();

if(n > best_score){ best_score = n; winning_node = delNode;

}

} CDelNode::CalculateScore(){

n1 = GetProofOfWorkHash(nBlockHeight); // get the hash of this block n2 = Hash(n1); //hash the POW hash to increase the entropy

n3 = abs(n2 – delNode_vin);

return n3;

}

 

The example code can be extended further to ensure that delegate nodes are ranked, also to select the “second”, “third”, “fourth” node in the list.

Trustless Quorums

Currently, there are ~50 active delegate nodes in the DAGRA network, and this number will grow strongly after the launch of the budgeting system. If 1000 DGR collateral is required to become an active delegate, we will create a system in which no one can manage the entire network of delegate nodes. For example, if someone wants to control 50% of the network of delegate nodes of 1000 nodes, he will have to buy 500 thousand DGR on the exchange. This will significantly increase the price, and it will become impossible to acquire the required amount of DGR.

With the addition of a network of delegate nodes and collateral requirements, we can use this secondary network to perform highly sensitive tasks without trust, when no subject can control the outcome. By selecting N pseudo-random delegate nodes from a common pool to perform the same task, these nodes can act as an oracle without loading the entire network.

For an implementation without a trusted quorum, see the article on InstantX, which uses quorums to approve transactions and blocking entries or implementing proof-of-service.

Another example of the use of distrustful quorums can be the use of a network of delegates as a decentralized Oracle for financial markets, which makes possible secure decentralized contracts. As an example of a contract, if a stock of a certain company is more than $ 300 as of December 31, 2017, public key A pays, otherwise pay public key B.

 

Roles and Proof-Of-Service

Delegate nodes can provide any number of additional services for the network. As proof of our concept, we have included Darksend and InstantX. Using what we call proof-of-service, we can require that these nodes are on the network, answer queries and even maintain the correct block height.

Attackers can also run a delegate server, but do not provide any high-quality service that is required by the rest of the network. To reduce the possibility that people use the system to their advantage, the nodes must ping the rest of the network to ensure that they remain active. This work is performed by a network of delegate servers, selecting 2 quorums per block. The quorum A checks the quorum B service for each block. The quorum A is the closest node to the current hash of the block, while the Quorum B is the farthest node from the specified hash.

 

Delegate node A (1) checks Delegate Node B (rank 2300)

Delegate node A (2) checks Delegate Node B (rank 2299)

Delegate node A (3) checks Delegate Node B (rank 2298)

 

All network verification work to prove that the nodes are active are performed by the network of delegate nodes themselves. Approximately 1% of the network will be scanned each block. This leads to the fact that the whole network is checked about six times a day. In order for this system to work without trust, we randomly select nodes through a quorum system, and at least six violations are required to deactivate the node.

To deceive this system, the attacker will need to choose six times in a row. Otherwise, violations will be canceled by the system, since other systems will be selected by the quorum system.

 

Table 1. The probability of success of the fraud system by submitting one individual delegate to the terminated service.

Where:

n – is the total number of nodes controlled by the attacker t is the total number of delegates in the network

r – is the depth of the chain

 

The choice of delegate nodes is pseudo-random based on the quorum system.

 

Delegate-node Protocol

Delegate hosts distribute messages over the network using a number of protocol extensions, including the delegate announcement messages and the delegation node ping message. These two messages are all that’s needed to make the node active on the network, although in addition there are other messages for performing proof-of-service requests, Darksend and InstantX.

Initially, the delegate node is formed by sending 1000 DGR to a specific address in the purse that “activates” the node, making it capable of propagating across the network. A secondary private key is created, which is used to sign all subsequent messages. The last key allows you to completely lock your wallet when you are offline. Cold model became possible due to the use of a secondary closed key on two separate machines. The main “hot” client signs the 1000 DGR input, including the private secondary signing key in the message. Soon after the “cold” client sees the message, including its secondary key, and is activated as a delegate. This allows you to deactivate the hot client (the client is turned off) and does not allow the attacker to gain access to 1000DGR, having access to the delegate node after activation.

On startup, the delegate node sends a “Delegate Announce” message to the network, containing:

 

Message: (1 thousand DGR input, available IP address, signature, signature time, public key

1 thousand DGR, secondary public key, public pay key, payout percentage)

 

Every 15 minutes thereafter, a communication check message is sent, verifying that the node is still alive.

Message: (1 thousand DGR input, signature (using secondary key), signature time, stop) After a TTL expiration, the network will remove the inactive node from the network, as a result of

which the node will not be used by customers or paid for. Nodes can also ping the network constantly, but if they do not have open ports, they will be marked as inactive and will not be paid.

 

Distribute a list of delegate servers

New clients who are part of the DAGRA network should be aware of the currently active delegate nodes on the network in order to be able to use their services. Once they join the mesh network, they send their peers a command, requesting a known list of delegate nodes. The cache is used by clients to write delegate nodes and their current status, so when clients are restarted, they simply download this file and do not request a full list of delegate nodes.

 

Payments using mining and enforcement

To ensure that each delegate node is paid for by the honest part of the block reward, the network must ensure that the blocks are paid to the correct delegate nodes. If the miner does not meet the requirements, their blocks should be rejected by the network, otherwise, fraud will be promoted.

We propose a strategy in which delegate nodes form quorums, select a winning delegate node and broadcast their message. After N messages have been sent to select the same recipient, a consensus will be formed, and this block will be obliged to pay this delegate node.

When running on the network, the pool software (websites combining the efforts of individual miners) use the API RPC interface to obtain information on how to create a block. To pay delegate hosts, this interface must be extended by adding a secondary recipient to the GetBlockTemplate.

 

Then the pools distribute their successfully mined blocks with a split payment between themselves and the delegate node.

Darksend

We believe it’s important to have a standard trustless implementation for improving the privacy of its users in the reference client that provides a high degree of privacy. Other clients such as electrum, Android and iPhone will also have the same anonymity layer implemented directly and utilize the protocol extensions. This allows users a common experience anonymizing funds using a well-understood system.

Darksend 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.

The greatest challenge when improving privacy and fungibility of a cryptocurrency is doing it

in a way that does not obscure the entire blockchain. In Bitcoin based crypto currencies, one can tell which outputs are unspent and which are not, commonly called UTXO, which stands for unspent transaction output. This results in a public ledger that allows any user to act as guarantor of the integrity of transactions. The Bitcoin protocol is designed to function without the participation of trusted counterparties, in their absence, it is critical that auditing capabilities remain readily accessible to the users through the public blockchain. Our goal is to improve privacy and fungibility without losing these key elements that we believe make a successful currency.

By having a decentralized mixing service within the currency we gain the ability to keep the currency itself perfectly fungible. Fungibility is an attribute of money, that dictates that all units of a currency should remain equal. When you receive money within a currency, it shouldn’t come with any history from the previous users of the currency or the users should have an easy way to disassociate themselves from that history, thus keeping all coins equal. At the same time, any user should be able to act as an auditor to guarantee the financial integrity of the public ledger without compromising others privacy.

To improve the fungibility and keep the integrity of the public blockchain, we propose using an ahead-of-time decentralized trustless  mixing strategy.  To be  effective at  keeping the  currency fungible, this service is directly built into the currency, easy to use and safe for the average user.

 

Tracing Coinjoin By Amounts

A common strategy in existing Bitcoin implementations of Coinjoin is simply merging transactions together. This exposes the users to various methods of following the user’s coins through these joined transactions.

Figure 2: An example Coinjoin transaction with 2 users

In this transaction, 0.05BTC was sent through the mixer. To identify the source of the money, one

simply has to add up the values on the right until they match one of the values on the left. Breaking apart the transaction:

0.05+0.0499+0.0001(fee) = 0.10BTC.

0.0499+0.05940182+0.0001(fee) = 0.10940182BTC.

This gets exponentially more difficult as more users are added to the mixer. However, these sessions can be retroactively deanonymized at any point in the future.

 

Through linking and Forward Linking

In other proposed implementations of Coinjoin, it’s possible that a user anonymizer money then eventually sends change from that transaction to an exchange or other entity that knows the user’s identity. This breaks the anonymity and allows the entity to walk back through that user’s transactions. We call this type of attack “Forward Linking”

 

Figure 3: Forward Change Linking

 

In this example, Alice anonymizer 1.2BTC, which goes to 2 outputs, 1BTC and 0.2BTC. She then spends .7BTC from the 1BTC output, receiving the change of 0.3BTC. That 0.3BTC then goes to an identifiable source, confirming Alice also spent the .7BTC in the prior transaction.

To identify the sender of the anonymous transaction, start at the “exchange” transaction and go backward  in the  blockchain till  you get  to the  “Alice sends  0.7BTC  anonymously”. As the exchange, you know it was your user who just recently bought something anonymously, thus breaking the anonymity completely. We call this type of attack “Through Change Linking”.

 

Figure 4: Through Change Linking

In the second example, Alice buys 1.2 BTC from coin base, then anonymizes this amount into a

1BTC output. She then spends the 1BTC, receives change in the amount of 0.3BTC and then combines that with her 0.2BTC earlier change.

By combining the change from the anonymous transaction (0.3BTC) and the change she received from the CoinJoin transaction, you can link the entire history before and after, completely breaking the anonymity.

 

 

 

Improved Privacy and DOS resistance

Darksend 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 using DarkSend requires at least 3 participants.

 

 

Figure 5: Three users submit denominated funds into a common transaction. Users pay themselves back in the form of new outputs, which are randomly ordered.

 

chaining approach is employed, To improve the privacy of the system as a whole we propose using common denominations of

0.1DGR, 1DGR, 10DGR AND 100DGR. 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.

To address the possible DOS attacks, we propose all users submit a transaction as collateral to the pool when joining. This transaction will be made out to themselves and will pay a high fee to miners. In the case when a user submits a request to the mixing pool, they must provide collateral at the beginning of this exchange. If at any point any user fails to cooperate, by refusing to sign, for example, the collateral transaction will automatically be broadcasted.

This will make it expensive to do a sustained attack on the private network.

 

Passive Anonymization of funds and chaining

Darksend is limited to   1000   DGR   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, Darksend runs in a passive mode. At set intervals, a user’s client will request to join with other clients via a delegate-node. Upon entry into the delegate-node, 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 Darksend 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 which funds are sent through multiple delegate-nodes, one after another.

 

 

Table 2. How many users could possibly be involved in N mixing sessions.

 

Security Considerations

As transactions are merged,  delegate-nodes can possibly “snoop” on users funds as they pass through. This is not considered a serious limitation due to the requirement for delegate’s to hold

1000 DGR and the fact that users utilize random delegate-nodes that they select to host their joints. The probability of following a transaction throughout a chaining event can be calculated as follows

 

Table 3. The probability of following a Darksend transaction on the network given the attacker controls N Nodes.

 

Where:

n – is the total number of nodes controlled by the attacker t is the total number of delegate-nodes in the network

r – is the depth of the chain

The selection of delegate-nodes is random

 

Considering the limited supply of DAGRA (5.3 million at the time of writing) and the low liquidity available on the market, it becomes an impossibility to attain a large enough number of delegate- nodes to succeed at such an attack.

Extending the system by blinding delegate-nodes to the transactions taking place on their node will also greatly enhance the security of the system.

 

Delegate-node Blinding via Relay System

In section  «Passive  Anonymization of funds and chaining,»  we describe the probabilities of following a single transaction through multiple sessions of Darksend mixing. This can further be addressed by blinding delegate-nodes, so they can’t see which inputs/outputs belong to which users. To do this we propose a simple relay system that users can use to protect their identity.

Instead of a user submitting the inputs and outputs directly into the pool, they will pick a random delegate-node from the network and request that it relays the inputs/outputs/signatures to the target delegate-nodes. This means that the delegate-node will receive N sets of inputs/outputs and N sets of signatures. Each set belongs to one of the users, but the delegate-node can’t know which belongs to which.

 

Instant Transactions via InstantX

By utilizing delegate-node quorums, users are able to send and receive instant irreversible transactions. Once a quorum has been formed, the inputs of the transaction are locked to only be spendable in a specific transaction, a transaction lock takes about 4 seconds to be set currently on the network.  If consensus  is reached  on a lock by the delegate-node network,  all conflicting transactions or conflicting blocks would be rejected thereafter, unless they matched

the exact transaction ID of the lock in place.

This will allow vendors to use mobile devices in place of traditional POS systems for real world commerce and users to quickly settle face-to-face non-commercial transactions as with traditional cash. This is done without a central authority. An extensive overview of this feature can be found in the InstantX white paper.

 

Additional Improvements

X11GOST

x11GOST  is a  widely used hashing algorithm,  which takes a  different approach,  known as algorithm chaining. x11GOST consists of 10 SHA3 contestants and Stribog hash-function, each hash is calculated then submitted to the next algorithm in the chain.  By utilizing multiple algorithms, the likelihood that an ASIC is created for the currency is minimal until a later part of its life cycle.

In the life cycle of Bitcoin, mining began with hobbyists which used CPUs to mine the currency, then shortly after GPU software was created, which quickly replaced the CPUs.

Years after the GPUs cycle, ASICs or Application Specific Integrated Circuits were created, which quickly replaced the GPUs.

Due to the complexity and die size required to create an ASIC for mining x11GOST, we expect that it will take considerably longer than it did in Bitcoin, allowing for hobbyists to take part in the mining for a longer period of time. We believe this is highly important for good distribution and the growth of a cryptocurrency.

Another benefit of the chaining hashing approach is high-end CPUs give an average return similar to that of GPUs. Also, GPUs have been reported to run 3050% cooler, with less wattage than the Scrypt algorithm used by most current crypto currencies.

Mining Supply

A different approach to restricting the inflation of mining is taken in DAGRA, using a 7% reduction of the supply per year. This is done as opposed to having implemented by other currencies. In addition supply, each block is directly tied to a number of miners on the network; more miners result in lower mining rewards.

The emission of DAGRA is planned to continue until about 2038 by the above formula, after the reward for the block according to the formula will be less than the one Dagra this reward to the miners will be set at 1 DAGRA per block forever.

Thus, we are trying to avoid increasing commissions for transactions and will provide the market with a liquidity inflow to avoid a rigid deflationary model, but keep inflation at a minimum level.

Dagra Currency Supply and Mining Reward Schedule

 

Conclusion

This paper introduces various concepts to improve the design of Bitcoin resulting in improved privacy and fungibility for the average user, less price volatility and quicker message propagation throughout the network. This is all accomplished by utilizing an incentivized twitter model, rather than the existing single tire model in other cryptocurrencies such as

Bitcoin. By utilizing this alternative network design it becomes possible to add many types of services such as decentralized mixing of coins, instant transactions and decentralized oracles using delegate-node quorums.