Liberdyne messenger

1. Nodes selected to mint the next block receive the current master-block from its minters.
2. Nodes split into shards depending on the current master-block hash and the current system load.
3. Users send transactions to the minters of the particular shard, which is selected according to a transaction sender’s public key or username.
4. The minters of each shard synchronize the transaction pool with each other.
5. Each minter within the shard signs and proposes their own shard-block. All shard-blocks within the shard should be identical since the minters have synchronized all necessary data beforehand.
6. Shard-blocks are propagated among all the minters of the current block. The minters validate all the shard-blocks and sign a master-block, which consists of the whole set of shard-blocks.
7. The master-block is propagated throughout the network as a new block of the blockchain.

For minting new blocks and delivering offline messages, users are paid with newly minted coins, while for providing storage space and serving as a relay, payments are made by other users, who wish to use those optional features.

The reward distribution system is also adapted to serve as a powerful marketing feature. With each new block, a predefined amount of dynes is distributed fairly among all participants. This means that the fewer users involved in the process, the greater the reward for each of them. And this, in turn, is a great motivation to start using Liberdyne as soon as possible. Considering that users who will support Liberdyne from the start will earn much greater rewards, this may lead to an explosive growth in the user base.

When node N run by user U is connected to the network, it chooses two chains of 3–6 relay nodes for incoming and outgoing messages.

Sending a message

1. When user U on node N wants to send a message to recipient account R, he gets information about which node is associated with user R from DHT. Say it is node C. U chooses three relay nodes for an output chain (X, Y, Z), sequentially encrypts the message, along with the metadata about the route, with the public keys of user R and of nodes C, Z, Y, X, and sends the encrypted data to node X.
2. X receives the message and decrypts it with its private key. It sees that the message contains some encrypted data and instructions to send the data to node Y, which it does.
3. Nodes Y and Z do the same as X.
4. C receives the message from Z and decrypts it with its private key. It learns that this is a message for account R. Since the owner of the node has the private key of account R, he decrypts the message and reads it.

None of the relaying nodes knows which particular nodes and which user accounts are the sender or the recipient of the message.

The owner of X may suppose that node N is the sender node; therefore, user U is the sender of the message, but it may also be just a relaying node, like X itself.

The owner of Z may suppose that C is the recipient, but it may also be just a relaying node, like Z itself.

Since nobody knows how many nodes U has actually chosen as relays, even if the adversary runs all nodes in the chain (X, Y, Z), he still cannot be sure that U is the sender of the message.

Receiving a message

If user R, along with user U, is using SATAN, then after exiting U’s output chain, a message does not go directly to the node of R but enters his input chain instead.

In this case, R puts into DHT the information that he can be found not on the node on which he actually is (M) but on the first node of his input chain (C). Then, using his output chain, user R sends the following messages:

1. He tells node C that he can be found on B.

2. He tells node B that he can be found on A.

3. He tells node A that he can be found on M.

The message travels through his input chain and is finally delivered to node M, where R decrypts it with his private key.

Relay nodes from R’s input chain know only that they are delivering some data to R, but they do not know the sender of the message or what node R is actually on. Node A may suppose that node M is the recipient node, but it may also be just a relaying node, like A itself.

Therefore, with the help of the SATAN protocol, any user can stay fully anonymous regardless of whether his or her interlocutor also uses the SATAN protocol.

1. Nodes selected to mint the next block receive the current master-block from its minters.
2. Nodes split into shards depending on the current master-block hash and the current system load.
3. Users send transactions to the minters of the particular shard, which is selected according to a transaction sender’s public key or username.
4. The minters of each shard synchronize the transaction pool with each other.
5. Each minter within the shard signs and proposes their own shard-block. All shard-blocks within the shard should be identical since the minters have synchronized all necessary data beforehand.
6. Shard-blocks are propagated among all the minters of the current block. The minters validate all the shard-blocks and sign a master-block, which consists of the whole set of shard-blocks.
7. The master-block is propagated throughout the network as a new block of the blockchain.

For minting new blocks and delivering offline messages, users are paid with newly minted coins, while for providing storage space and serving as a relay, payments are made by other users, who wish to use those optional features.

The reward distribution system is also adapted to serve as a powerful marketing feature. With each new block, a predefined amount of dynes is distributed fairly among all participants. This means that the fewer users involved in the process, the greater the reward for each of them. And this, in turn, is a great motivation to start using Liberdyne as soon as possible. Considering that users who will support Liberdyne from the start will earn much greater rewards, this may lead to an explosive growth in the user base.

When node N run by user U is connected to the network, it chooses two chains of 3–6 relay nodes for incoming and outgoing messages.

Sending a message

1. When user U on node N wants to send a message to recipient account R, he gets information about which node is associated with user R from DHT. Say it is node C. U chooses three relay nodes for an output chain (X, Y, Z), sequentially encrypts the message, along with the metadata about the route, with the public keys of user R and of nodes C, Z, Y, X, and sends the encrypted data to node X.
2. X receives the message and decrypts it with its private key. It sees that the message contains some encrypted data and instructions to send the data to node Y, which it does.
3. Nodes Y and Z do the same as X.
4. C receives the message from Z and decrypts it with its private key. It learns that this is a message for account R. Since the owner of the node has the private key of account R, he decrypts the message and reads it.

None of the relaying nodes knows which particular nodes and which user accounts are the sender or the recipient of the message.

The owner of X may suppose that node N is the sender node; therefore, user U is the sender of the message, but it may also be just a relaying node, like X itself.

The owner of Z may suppose that C is the recipient, but it may also be just a relaying node, like Z itself.

Since nobody knows how many nodes U has actually chosen as relays, even if the adversary runs all nodes in the chain (X, Y, Z), he still cannot be sure that U is the sender of the message.

Receiving a message

If user R, along with user U, is using SATAN, then after exiting U’s output chain, a message does not go directly to the node of R but enters his input chain instead.

In this case, R puts into DHT the information that he can be found not on the node on which he actually is (M) but on the first node of his input chain (C). Then, using his output chain, user R sends the following messages:

1. He tells node C that he can be found on B.

2. He tells node B that he can be found on A.

3. He tells node A that he can be found on M.

The message travels through his input chain and is finally delivered to node M, where R decrypts it with his private key.

Relay nodes from R’s input chain know only that they are delivering some data to R, but they do not know the sender of the message or what node R is actually on. Node A may suppose that node M is the recipient node, but it may also be just a relaying node, like A itself.

Therefore, with the help of the SATAN protocol, any user can stay fully anonymous regardless of whether his or her interlocutor also uses the SATAN protocol.