The PrivateSend uses the fact that a transaction can be formed by various inputs and outputs, and sent to several parties to merge funds in a way that cannot be separated later.
Like all transactions of PrivateSend, they are configured to be paid by own users, the system is highly secure against theft and user’s currencies always remain secure.
Currently, the mixing of PrivateSend requires at least three participants.
To avoid any possible DoS attacks, we propose that all users have to submit a transaction as collateral for the pool to join. This transaction will be made to them and pay a high fee to the miners. In the event that a user sends a request to the mixing pool, it must provide warranty at the beginning of this Exchange.
If, at any time, any user does not cooperate, refusing to sign, for example, the warranty transaction will be transmitted automatically. This will make it expensive to perform a continuous attack on the privacy network.
PrivateSend is limited to 1000 LQX per session and requires several sessions to anonymize completely significant amounts of money. To make the user experience easy and very difficult for attacks, PrivatSend it executes on passive mode. With defined intervals, a user’s client will request membership with other clients through a masternode.
After entry into the Masternode, a queue object is propagated through the network, detailing the denominations that user is looking to anonymize, but there is no information that can be used to identify the user.
Each private session can be considered as independent event. However, each session is limited to three clients, therefore, an observer has a three-power chance to follow a transaction. To increase the quality of anonymity provided, a chaining approach is used, whose funds are sent through multiple masternodes, one after the other.
As transactions are merged, Masternodes can “Snoop” the funds of the users as they pass. That is not considered a serious limitation due to the requirement of 1000 LQX storage of masternode, and the fact that users using random masternodes that select to host your joints.
The probability of following a transaction over a chaining event can be calculated from the following way:
n: total number of nodes controlled by the attacker
t: total number of masternodes on the network
r: is the depth of the current
The selection of Masternodes is random.
Extend the system by blinding Masternodes for transactions that occur in your node, will also greatly increase the security of the system.
When using Masternode quorums, users can send and receive instant
irreversible transactions. When a quorum is formed, the transaction entries are blocked to be spent only in a specific transaction, a transaction lock takes about four seconds to be currently set on the network.
If consensus is reached in a blocking by the Masternode network, all conflicting transactions or conflicting blocks will be rejected from then on, the unless they correspond to the exact transaction ID of the lock in place. This will allow suppliers to use Mobile devices in place of traditional POS systems for real world trade and users to quickly resolve non commercial transactions face to face, as is the case with traditional money.
This is done without a central authority. A comprehensive view of this feature can be found in the InstantSend White Paper.
Previously, we describe the odds of following a single transaction through multiple mixed sessions of the PrivateSend.
This can still be resolved by concealment of Masternodes, so they can’t see which inputs/outputs belong to which users. To do this, we propose a system of simple relay that users can use to protect your identity.
Instead of a user sending the inputs and outputs directly to the pool, they select a random masternode Network and request that it retransmit the inputs/outputs/ signatures for the target masternode.
This means that the Masternode will receive N sets of inputs/outputs and N sets of signatures. Each set belongs to one of the users, But the masternode doesn’t know what it belongs to.