Deposit flows, deferred transactions, confidential communication channels
On the classical exchanges, you first need to make a deposit to the account of the exchange and then trade. We decided to add this type of deposit for making quick deals during the day. This will allow traders to perform thousands of transactions per day. At the same time, our platform will not have more than 5% of the total deposits on each depositary account in HMW, this is to minimize possible attacks on the blockchain infrastructure of the ESCB exchange. It will also serve as evidence that our exchange will not be able to control our customer deposits.
To maintain decentralization, we added a pending transaction. Under such a transaction, one of the participants makes a deposit for the transaction using HMW, and the second one fulfills the conditions of the transaction, after which it receives the deposited funds.
Consider an example of a transaction on the example of buying 1 ETH for $ 100. Seller 1 ETH has on deposit the amount that is reserved for the transaction. The buyer receives the details for the transfer of p2p, for example from card to card. After confirming the transfer, the amount of 1 ETH is transferred to the buyer. At this stage, there could be possible disputes between the parties of the transaction. To solve such situations there is a “Talks” section on the ESCB exchange, which allows you to exchange messages between the counterparties to the transaction. If the dispute cannot be resolved, then a moderator is added to the conversation.
A natural problem in such a situation is trust between the parties. To do this, all messages in the conversation will be confidential. We have developed our own confidential correspondence system based on the elliptic curves of the ETH keys of the blockchain.
Such a communication channel works in the following simplified way:
- Bob and Alice each have two keys — open, which is used to generate the ETH address of the wallet and closed, which is used to sign transactions.
- At the stage of forming a new communication channel, Bob generates a new key pair, public and private (identity), and encrypts this identity channel with Alice’s public key.
- At this stage in the database for two counterparties, there is an identity channel encrypted with the public key for Bob and Alice. This provides a confidential channel for their communication.
- To send a message, Bob decrypts with his private key the identity channel. Encodes the message with the public key of the identity channel and sends it.
- Alice and Bob use the identity channel private key to read all messages in a confidential channel.
If the process of the transaction requires assistance in resolving the dispute. Then Bob or Alice can invite other participants to the group through the following mechanism.
- One of the parties, for example, Alice, presses the button — to invite the moderator into the conversation.
- Identity channel is encrypted in Bob’s browser with the public key of the moderator and is recorded in the database.
- The moderator decrypts the private key of the identity channel and can use a confidential channel of communication with the parties to the transaction.
If in the course of the transaction it is necessary to provide evidence in the form of images or other media files, they are encrypted by the identity channel and recorded in ipfs. Such files can be obtained by a hash code by anyone who has it. But such files can only be decrypted using the identity channel.
The advantages of such a scheme for building a confidential communication channel:
- Only encryption keys available in the user’s browser are used. This eliminates a middle-man attack. All data is sent via end-to-end encryption. Generation of an identity channel does not require the participation of the server part or any other party, as is the case in the algorithm https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
- Identity channel is stored in an encrypted form for each participant in a confidential conversation. This eliminates the possibility of its leakage by hacking the database.
- The ability to add an unlimited number of participants in the conversation.
- The good speed of encoding and decoding messages, as one identity channel is used for all messages and files in a confidential conversation.
- For each communication channel a new identity channel is formed, so if one identity channel leaks, it is impossible to read other channels.
The only possible disadvantage of this construction scheme:
- In case of a leak of the private key of one of the participants in a confidential conversation, as it is possible to read all the messages in the channel.
- It is not possible to use the server performance for a search. Any string search can be performed only on the client side, but due to each deal in creating a new channel, the data length for a search will be limited.