Hierarchy of multi-subscription wallets (Trust System)

This text describes the abstraction of a trust system that allows you to integrate escrow services into any sphere of economic relations.
Depositing funds is a fundamental part of any transaction. If counterparties do not know reliable information about each other, the risk of fraud increases. This asbraction allows you to program a dispute resolution model, a model for conducting automatic transactions, secure transactions, etc. in a decentralized network. This model of trust system is open. All transactions conducted with the participation of the hierarchy of multi-subscription wallets allow you to update the counterparty rating, as well as protect yourself from fraudulent schemes of new participants in economic relations.

Content

1 Introduction
2 Multi-signature Wallet Description
3 Ways to build a hierarchy of wallets
4 Hierarchy Interface of Multi-Purpose Wallets
5 Interaction flows
5.1 Standard interaction flow
5.2 Protected Interaction
5.3 The controversial interaction flow
6 ESCB9 protocol
7 Integration of the trust system and smart contracts implementing the ESCB9 protocol
8 Examples of contracts that implement ESCB9
8.1 Smart contract for the private property rental market following the example of AirBnb
8.2 Smart contract for the exchange of any cryptocurrency for fiat money and back in a decentralized mode
9 arbitration nodes
10 Dictionary

1. Introduction

The main problem for escrow services is the creation of a trust relationship between all participants. At the same time, the participants themselves should not necessarily be known to each subject of the relationship. To summarize all cases, we will take into account that they are all anonymous. For such a trusting system of relations, it is important to regulate the relations of new participants with old ones. Older participants already have a certain rating in the system of relationships and thus cause more confidence. Since nobody knows anyone in the trust system, this causes verification problems of the previous rating. This document provides a description of the trust system based on multi-subscription cryptographs. Such a system can be programmed into a smart contract. In view of the wide distribution of the Ethereum platform, we will choose this platform as the platform for describing all the smart contracts in this document.

2. Description of multi-signature wallet

The abstraction that allows you to confirm or cancel transactions only under the condition that a consensus is reached between the authorized participants to make such a decision is called a multi-subscription purse. A transaction in this context is an atomic operation programmed to execute a method in another or the same smart contract.

The interface for the Smart Contract of such an abstraction can be represented as:

1. the designer accepts the addresses of the founding members and the number of required minimum confirmations for the execution of transactions
   

   constructor(address[]:members, uint256:requiredConfirmationCount) 

   
   
2. Interface to work with authorized members
   
   1. getting the list of participants
      

       static getMembers() -> address[]:address 

      
      
   2. view member address
      

       static getMember(uint256:indexNumber) -> address:address 

      
      
   3. checking the address of membership
      

       static isMember(address:address) -> bool:value 

      
      
   4. getting the maximum number of participants for the wallet
      

       static getMaxMemberCount() -> uint256:value 

      
      
   5. getting a minimum amount of evidence for consensus
      

       static getRequiredConfirmationCount() -> uint256:value 

      
      
   6. event of adding a new member
      

       event MemberAddition() -> address:member 

      
      
   7. event delete member
      

       event MemberRemoval() -> address:member 

      
      
   8. event change required number of confirmations to execute
      

       event RequiredConfirmationCountChange() -> uint256:count 

      
      
   9. adding member
      

       execute addMember(address:member) -> void:value 

      
      
   10. remove member
       

        execute removeMember(address:member) -> void:value 

       
       
   11. member replacement
       

        execute replaceMember(address:currentMember, address:newMember) -> void:value 

   12. change the number of required confirmations to perform
       

        execute changeRequiredConfirmationCount(uint256:count) -> void:value 

       
       
   
   
3. Transaction Interface
   
   1. verification of transaction confirmation at the participant’s address
      

       static getConfirmationByAddress(uint256:indexNumber, address:addressMember) -> bool:value 

      
      
   2. getting information from a transaction
      

       static getTransactionInfo(uint256:indexNumber) -> [address:destination, uint256:value, bytes:data, bool:executed] 

   3. getting total transactions in this wallet
      

       static getTransactionCount() -> uint256:value 

   4. getting transaction confirmation status
      

       static isConfirmed(uint256:transactionId) -> bool:value 

   5. getting confirmation amount
      

       static getConfirmationCount(uint256:transactionId) -> uint256:count 

   6. getting the number of transactions by type
      

       static getTransactionCount(bool:pending, bool:executed) -> uint256:count 

   7. getting the list of participants who confirmed the transaction
      

       static getConfirmations(uint256:transactionId) -> address[]:confirmations 

   8. getting a list of transaction id by type in a certain period of time
      

       static getTransactionIds(uint256:from, uint256:to, bool:pending, bool:executed) -> uint256[]:transactionIds 

   9. event confirming transaction by member
      

       event Confirmation() -> [address:sender, uint256:transactionId, uint256:timeStamp] 

   10. event of a member confirmation revocation before a transaction
       

        event Revocation() -> [address:sender, uint256:transactionId, uint256:timeStamp] 

   11. event of adding a transaction to the queue
       

        event Submission() -> [uint256:transactionId] 

   12. transaction execution event
       

        event Execution() -> [uint256:transactionId] 

   13. error event during transaction
       

        event ExecutionFailure -> [uint256:transactionId] 

   14. wallet replenishment event
       

        event Deposit -> [address:sender, uint256:amount] 

   15. add transaction by member
       

        execute submitTransaction(address:destination, uint256:value, bytes:data) -> uint256:transactionId 

   16. confirmation of transaction by member
       

        execute confirmTransaction(uint256:transactionId) -> void:value 

   17. member confirmation feedback
       

        execute revokeConfirmation(uint256:transactionId) -> void:value 

   18. manual execution of a transaction
       

        execute executeTransaction(uint256:transactionId) -> void:value 

   
   

3 Ways to build a hierarchy of wallets

There are two main ways to build a trust system. Vertical and horizontal. The horizontal path of construction involves the creation by one main parent of the list of subsidiary wallets. The vertical path of construction implies a chain consisting of child wallets with reference to the parent. In this case, the parent wallet can be a child of another parent wallet.
As we see the horizontal path of construction can be a subtype of the vertical path of construction. Therefore, we will further disregard this approach.

4 Hierarchy Interface of Multi-Purpose Wallets

To build a trusting system, it is necessary to expand the simple interface of the multi-subscription purse described above, by adding mechanisms for regulating hierarchy and automatic execution of confirmations, as well as the possibility of deferred execution.

1. The designer accepts the address of the parent wallet, the addresses of the founding members, the number of required minimum confirmations for the execution of transactions, the standard time for automatic confirmations in seconds
   

    constructor(address:parent, address[]:members, uint256:requiredConfirmationCount, uint256:standardTimeAutoConfirmation) 

   
   
2. Interface to work with participants
   
   1. getting the list of participants
      

       static getMembers() -> address[]:address 

      
      
   2. function to view member address
      

       static getMember(uint256:indexNumber) -> address:address 

      
      
   3. checking the address of membership
      

       static isMember(address:address) -> bool:value 

      
      
   4. getting the maximum number of wallet participants
      

       static getMaxMemberCount() -> uint256:value 

      
      
   5. getting a minimum amount of evidence for consensus
      

       static getRequiredConfirmationCount() -> uint256:value 

      
      
   6. event of adding a new member
      

       event memberAddition() -> address:member 

      
      
   7. event delete member
      

       event memberRemoval() -> address:member 

      
      
   8. event change required number of confirmations to execute
      

       event requiredConfirmationCountChange() -> uint256:count 

      
      
   9. adding member
      

       execute addMember(address:member) -> void:value 

      
      
   10. remove member
       

        execute removeMember(address:member) -> void:value 

       
       
   11. member replacement
       

        execute replaceMember(address:currentMember, address:newMember) -> void:value 

       
       
   12. change the number of required confirmations to perform
       

        execute changeRequiredConfirmationCount(uint256:count) -> void:value 

       
       
   
   
3. Hierarchy Interface
   
   1. getting a list of child wallets
      

       static getChildren() -> address[]:wallets 

      
      
   2. checking whether the wallet address is a child of the current one
      

       static isChild() -> bool:value 

      
      
   3. checking whether the address of the wallet is parental to the current one is done through isChild by contrast.
      
   4. child wallet attach event
      

       event childAttachment() -> [address:address,uint256:timeStamp] 

      
      
   5. child wallet deletion event
      

       event childRemoval() -> [address:address,uint256:timeStamp] 

      
      
   6. child wallet attachment
      

       execute attachChild(addres:child) -> void:value 

      
      
   7. removal of child wallet
      

       execute removeChild(address:address) -> void:value 

      
      
   8. change one child wallet to another
      

       execute replaceChild(address:newAddress) -> void:value 

      
      
   
   
4. Transaction Interface
   
   1. transaction status check
      

       static getTransactionStatus(uint256:transactionId) -> enum:{submitted,completed,frozen,disputed,reverted} 

      
      
   2. checking the status of a transaction for compliance
      

       static isTransactionStatus(uint256:transactionId, uint256:enumStatusNumber) -> bool:value 

      
      
   3. verification of transaction confirmation at the participant’s address
      

       static getConfirmationByAddress(uint256:transactionId, address:addressMember) -> bool:value 

      
      
   4. getting information from a transaction
      

       static getTransactionInfo(uint256:transactionId) -> [address:destination, uint256:value, bytes:data, bool:executed] 

      
      
   5. getting the total number of transactions in the wallet
      

       static getTransactionCount() -> uint256:value 

      
      
   6. getting transaction confirmation status
      

       static isConfirmed(uint256:transactionId) -> bool:value 

      
      
   7. getting confirmation amount
      

       static getConfirmationCount(uint256:transactionId) -> uint256:count 

      
      
   8. getting the number of transactions by type
      

       static getTransactionCount(bool:pending, bool:executed) -> uint256:count 

      
      
   9. getting the list of participants who confirmed the transaction
      

       static getConfirmations(uint256:transactionId) -> address[]:confirmations 

      
      
   10. getting time to auto-confirm
       

        static getTimeAutoConfirmation(uint256:transactionId) -> uint256:timestamp 

       
       
   11. getting a list of transaction id by type in a certain period of time
       

        static getTransactionIds(uint256:from, uint256:to, bool:pending, bool:executed) -> uint256[]:transactionIds 

       
       
   12. event confirming transaction by member
       

        event Confirmation() -> [address:sender, uint256:transactionId, uint256:timeStamp] 

       
       
   13. automatic transaction confirmation event
       

        event AutoConfirmation() -> [uint256:transactionId, uint256:timeStamp] 

       
       
   14. event of a member confirmation revocation before a transaction
       

        event Revocation() -> [address:sender, uint256:transactionId, uint256:timeStamp] 

       
       
   15. event of adding a transaction to the queue
       

        event Submission() -> [uint256:transactionId] 

       
       
   16. transaction execution event
       

        event Execution() -> [uint256:transactionId] 

       
       
   17. error event during transaction
       

        event ExecutionFailure -> [uint256:transactionId] 

       
       
   18. transaction status change event frozen
       

        event TransactionFrozen -> [uint256:transactionId] 

       
       
   19. Transaction Status Change Event
       

        event TransactionDisputed -> [uint256:transactionId] 

       
       
   20. transaction status change event returned
       

        event TransactionReverted -> [uint256:transactionId] 

       
       
   21. wallet replenishment event
       

        event Deposit -> [address:sender, uint256:amount] 

       
       
   22. add transaction to execute
       

        execute submitTransaction(address:destination, uint256:value, uint256:TimeAutoConfirmation, bytes:data) -> uint256:transactionId 

       
       
   23. transaction confirmation
       

        execute confirmTransaction(uint256:transactionId) -> void:value 

       
       
   24. revocation confirmation
       

        execute revokeConfirmation(uint256:transactionId) -> void:value 

       
       
   25. change transaction status to frozen
       

        execute setTransactionStatus(uint256:transactionId, uint256:enumStatusNumber) -> void:value 

       
       
   26. manual execution of a transaction
       

        execute executeTransaction(uint256:transactionId) -> void:value 

       
       
   
   
5. Rating Management
   
   1. getting a rating at
      

       static getRatingByAddress(address:agent) -> [uint256:negativeRating, uint256:positiveRating, uint256:countRatingRecords] 

      
      
   2. getting rating history by address and order number
      

       static getRatingRecordForAddress(address:agent, uint256:indexNumber) -> void:value 

      
      
   3. event of adding an entry to the rating at
      

       event RatingRecordAdded -> [address:author, address:agent, bytes32:smartContractAddress, bool:positiveOrNegative, uin256:ratingNumber, bytes:comment, uint256:indexNumber] 

      
      
   4. adding an entry to the rating for the address
      

       execute addRatingRecord(address:agent, bytes32:smartContractAddress, bool:positiveOrNegative, uin256:ratingNumber, bytes:comment) -> void:value 

      
      
   
   
6. Integration with ESCB9 protocol
   
   1. Checking whether the smart contract is attached to this wallet is a smart contract with ESCB9 implementation
      

        static isAttachedESCB9SmartContract(address:smartContract) -> bool:result 

      
      
   2. check the status of the deposit for a smart contract with ESCB9 attached to this wallet
      

        static getDepositStatusForESCB9SmartContract(address:smartContract) -> enum:{awaiting,founded,returned} 

      
      
   3. smart contract attach event with ESCB9 implementation to wallet
      

       event AttachingESCB9SmartContract -> [address:smartContract] 

      
      
   4. deposit event for smart contract with ESCB9 implementation attached to wallet
      

       event ConfirmationForDepositESCB9SmartContract -> [address:smartContract, uint256:sum, bytes:notice] 

      
      
   5. attaching a smart contract with the implementation of ESCB9 to the wallet
      

       execute attachESCB9SmartContract(address:smartContract) -> void:value 

      
      
   6. deposit confirmation for smart contract with implementation of ESCB9. If the deposit is in the external system, then notice will be marked. If the deposit is in ETH, then the deposit amount is sent when the method is executed.
      

       execute fundDepositForESCB9SmartContract(address:smartContract, uint256:sum, bytes:notice) -> void:value 

      
      
   
   

5 Interaction flows

Any smart contract can be integrated into the hierarchy of multi-subscription wallets. Such integration will have interaction flows. In general, select several types of streams:

• Standard . In this type of transaction takes place in automatic mode. Without the participation of plenipotentiaries in the purse hierarchy.
• Protected . In this view, the time of the transaction can be increased from the standard to automatically confirm the time to the required. In this case, the participation of authorized members of the purse hierarchy is necessary.
• Controversial . In this form, the party to the transaction may freeze the transaction. In this case, the participation of plenipotentiaries of the purse hierarchy is necessary in order to develop a consensus.

Each wallet in the trust system has a number of authorized participants, who make a verdict. For simple reasoning, we will unite all the authorized participants of the wallet into one concept - the arbitrator .

5.1 Standard interaction flow

For simplicity, we will bring the concepts of goods and services to the concept of the object of transfer (object), and the concept of fiat money, cryptocurrency to the concept of means of transfer (means).
The counterparty, the owner of the object makes a deal with the counterparty, the owner of the funds, for the purpose of exchange. In this case, the object owner creates a smart escrow contract by sending a standardized transaction to one of the authorized wallets in the hierarchy of multi-subscription wallets. In this case, the transaction is registered by a third party as a trust system. For each transaction is determined by the standard time for its implementation. The counterparty, the owner of the funds, makes a deposit on the transaction by transferring the funds to the trust system. After that, the object owner transfers the object to the owner of the funds. The owner of the funds checks the quality of the object. If, before the end of the transaction time, he did not confirm the quality, the funds are transferred to the owner of the object as part of the transaction. Both counterparties assign comfort ratings to each other. Thus, the owner of the funds can change the interaction flow until the end of the transaction. After the transfer of funds to the owner of the object, the owner of the funds may apply to the purse higher in the hierarchy level for resolving disputes within a certain time limit. After the expiration of this time, the ratings for the transaction are applied to both parties and the transaction becomes non-refundable.

5.2 Protected Interaction

If for some reasons independent of counterparties it is necessary to extend the deadline for making a transaction, then, by agreement of the parties, the multi-signature hierarchy's purse (arbitrator) can change the time allotted for the transaction. After changing the time, the interaction flow that is diverted to the transaction returns to the logic level of the standard flow.

5.3 The controversial interaction flow

If the quality of the object during the transaction does not suit the counterparty, the owner of the funds he brings to the trust system of the multi-subscription purses hierarchy, the transaction can be frozen. In this case, the deposit is not transferred to the counterparty, the owner of the object before the verdict on the transaction. The party holding the funds must provide solid evidence to the arbitrator of the transaction. After that, the arbitrator renders a verdict in favor of one of the counterparties. If any party to the transaction is not satisfied with the verdict, it turns into a higher purse in the order in the hierarchy of multi-subscription purses. Having passed all instances in the hierarchy, either of the parties may request a public vote. This exceptional measure can only be assigned to a purse of absolute authority.

6 ESCB9 protocol

An example of the ESCB9 protocol in the Solidity language as an abstract smart contract (the protocol is under development and can be changed)

 contract ESCB9 { /** * Modificator for arbitrage */ modifier onlyArbitrage() { require(msg.sender == arbitrage()); _; } /** * Modificator for checking deposit status */ modifier isDeposited { uint i; bytes memory _funcName = bytes4(keccak256("getDepositStatusForESCB9SmartContract(address)")); bytes memory _concat = new bytes(_funcName.length + 32); for(i=0; i < address(this).length; i++) { _concat[i] = address(this)[i]; } require(arbitrage().call.value(0)(_concat) == 1); // “founded” for enum _; } event confirmed(uint256 unixtimestamp, bytes32 notice); event frozen(uint256 unixtimestamp, bytes32 notice); event disputed(uint256 unixtimestamp, bytes32 notice); event canceled(uint256 unixtimestamp, bytes32 notice); /** * @notice Function to approve escrow deal and confirm success * @return Success of operation **/ function confirm(notice) public onlyArbitrage returns(bool); /** * @notice Function to freeze escrow deal * @return Success of operation **/ function freeze(notice) public onlyArbitrage returns(bool); /** * @notice Function to dispute escrow deal * @return Success of operation **/ function dispute(notice) public onlyArbitrage returns(bool); /** * @notice Function to cancel escrow deal and confirm fail * @return Success of operation **/ function cancel(notice) public onlyArbitrage returns(bool); /** * @notice Function to get seller's address * @return Seller's address **/ function seller() public returns(address); /** * @notice Function to get custom type for ESCB9 smart contract * @return Type **/ function type() public returns(bytes); /** * @notice Function to get buyer's address * @return Buyer's address **/ function buyer() public returns(address); /** * @notice Function to get sum for deal * @return Sum of deal in wei **/ function depositedSum() public returns(uint256); /** * @notice Function to get arbitrage's address * @return Arbitrage's address **/ function arbitrage() public returns(address); } 

7 Integration of the trust system and smart contracts implementing the ESCB9 protocol

To use the trust system of the multi-signature wallets hierarchy in your own project, you need to create a smart contract that implements the ESCB9 standard and attach such a smart contract to one of the arbitrators who does not have any subsidiary wallets. Such wallets in the multi-subscription hierarchy are called “input nodes”. All upstream multi-subscription wallets are called “arbitration nodes”.

8 Examples of contracts that implement ESCB9

8.1 Smart contract for the private property rental market following the example of AirBnb

 // Don't use this code, it can be not working or contain the vulnerability, for demonstration purpose only pragma solidity ^0.4.21; /// @title rentMyApartmentESCB9 - Allows rent object on market with escrow service. The safe way to do deal for counterparties. /// @author Konstantin Viktorov - <ceo@escrowblock.net> contract rentMyApartmentESCB9 is ESCB9 { // 2018-05-10 18:25 in unix timestamp uint256 constant public checkInTime = 1525965900; // 2018-05-20 18:25 in unix timestamp uint256 constant public checkOutTime = 1526829900; // Coordinates in bytes format. For example 56.865129,35.881540 bytes constant public coordinates = "0x35362e3836353132392c33352e383831353430"; // Google maps link, as example, but better add Url to landing page bytes constant public externalUrl = "0x68747470733a2f2f676f6f2e676c2f6d6170732f6e783563396b6737384170"; /** * Encrypted information, see https://github.com/ethereumjs/ethereumjs-wallet and * https://github.com/pubkey/eth-crypto/blob/master/tutorials/encrypted-message.md * For example you can leave here information about pin-code for smart lock **/ bytes constant private privateInformation = '0x0dfef623523483245687234'; modifier only_before_check_in { require(getNow() < checkInTime); _; } modifier only_after_check_out { require(getNow() > checkOutTime); _; } modifier only_during_renting { require(getNow() > checkInTime && getNow() < checkOutTime); _; } modifier only_not_in_during_renting { require(getNow() < checkInTime && getNow() > checkOutTime); _; } /** * @notice ESCB9 interface * @notice Function to get address of apartment owner * @return Seller's address **/ function seller() public returns(address) { return "0x27a36731337cdee360d99b980b73e24f6e188618"; } /** * @notice ESCB9 interface * @notice Function to get custom type for ESCB9 smart contract * @return Type **/ function type() public returns(bytes) { return "rent"; } /** * @notice ESCB9 interface * @notice Function to get address of renter * @return Buyer's address **/ function buyer() public returns(address) { return "0xb582baaF7e749d6aA98A22355A9d08B4c4d013C8"; } /** * @notice ESCB9 interface * @notice Function to get sum for deal * @return Sum of deal in wei **/ function depositedSum() public returns(uint256) { return 1000000000000000000; //1 ETH in weis } /** * @notice ESCB9 interface * @notice Function to get arbitrage's address * @return Arbitrage's address **/ function arbitrage() public returns(address) { return "0xe91065d8bb2392121a8fbe6a81e79782fbc89dd4"; } /** * @notice ESCB9 interface * @notice Function to approve escrow deal and confirm success * @param Some comment * @return Success of operation **/ function confirm(notice) public onlyArbitrage only_after_check_out returns(bool) { confirmed(getNow(), notice); } /** * @notice ESCB9 interface * @notice Function to freeze escrow deal * @param Some comment * @return Success of operation **/ function freeze(notice) public onlyArbitrage only_during_renting returns(bool) { frozen(getNow(), notice); } /** * @notice ESCB9 interface * @notice Function to dispute escrow deal * @return Success of operation **/ function dispute() public onlyArbitrage only_after_check_out returns(bool) { disputed(getNow(), notice); } /** * @notice ESCB9 interface * @notice Function to cancel escrow deal and confirm fail * @return Success of operation **/ function cancel() public onlyArbitrage only_not_in_during_renting returns(bool) { canceled(getNow(), notice); } /** * @notice Get current unix time stamp **/ function getNow() constant public returns (uint) { return now; } /** * @notice Get private information when renter will pay deposit **/ function getPrivateInformation() constant isDeposited public returns (bytes) { return privateInformation; } } 

8.2 Smart contract for the exchange of any fiat money cryptocurrency and back in a decentralized mode

The following example of a smart contract allows you to exchange BTC for fiat money directly, without the participation of exchangers and third-party services. The BTC seller transfers the sum in the smart contract to the BTC blockchain. The buyer, after the deposit is confirmed by the arbitrator, automatically transfers the amount pledged in the contract to the invoice or plastic card number entered in the contract. The arbitrator may intervene in the transaction process after the appeal of one of the participants. Initially, the deposit will be frozen and if the parties do not agree by consensus, then such a contract will become controversial with further resolution along the flow of the disputed interaction.

 // Don't use this code, it can be not working or contain the vulnerability, for demonstration purpose only pragma solidity ^0.4.21; /// @title p2pExchangeESCB9 - Allows exchanging any cryptocurrencies on fiat money and back, directly between users. The safe way to do deal for counterparties. /// @desc This example shows as exchange fiat money on BTC (forward flow) /// @author Konstantin Viktorov - <ceo@escrowblock.net> contract p2pExchangeESCB9 is ESCB9 { // in minimal decimals, for example, 500.000 rubles is equal 50000000 kopeks uint256 constant public inputAmount = 50000000; // RUR in bytes bytes constant public inputCurrency = "0x525552"; // in minimal decimals, for example, 1 BTC is equal 100000000 satoshi uint256 constant public outputAmount = "100000000"; // BTC in bytes bytes constant public outputCurrency = "0x425443"; // Deposit can be place only before this time const bytes public closeTime = "1526829900"; // use "forward" way, when output currency will be deposited or "backward" if input currency will be deposited uint256 constant public depositWay = "forward"; /** * Encrypted information, see https://github.com/ethereumjs/ethereumjs-wallet and * https://github.com/pubkey/eth-crypto/blob/master/tutorials/encrypted-message.md **/ /** * Encrypted information for placing deposit, for example BTC address **/ bytes private externalDepositAddress = "0x3139333978476346484d6f464b465845564754415761706b3537694e6a3579556b52"; /** * Encrypted information for the amount of deposit, for example for BTC 8 decimals can be added 2-3 chars from 0-9 as pin-code for deal. See more in EscrowBlock WhitePaper * If output amount is equal 100000000, then deposited amount can be 100000123 **/ bytes private externalDepositAmount = "0x5f5e17b"; /** * Encrypted information for sending amount to seller, for example credit card number or bank account, for example 4242424242424242 **/ bytes private externalIncomingAddress = "0xf12765df4c9b2"; modifier only_before_close_time { require(getNow() < closeTime); _; } modifier only_after_close_time { require(getNow() > closeTime); _; } /** * @notice ESCB9 interface * @notice Function to get address of apartment owner * @return Seller's address **/ function seller() public returns(address) { return "0x27a36731337cdee360d99b980b73e24f6e188618"; } /** * @notice ESCB9 interface * @notice Function to get custom type for ESCB9 smart contract * @return Type **/ function type() public returns(bytes) { return "exchange"; } /** * @notice ESCB9 interface * @notice Function to get address of renter * @return Buyer's address **/ function buyer() public returns(address) { return "0xb582baaF7e749d6aA98A22355A9d08B4c4d013C8"; } /** * @notice ESCB9 interface * @notice Function to get sum for deal * @return Sum of deal in minimal decimals **/ function depositedSum() public returns(uint256) { rerurn outputAmount; } /** * @notice ESCB9 interface * @notice Function to get arbitrage's address * @return Arbitrage's address **/ function arbitrage() public returns(address) { return "0xe91065d8bb2392121a8fbe6a81e79782fbc89dd4"; } /** * @notice ESCB9 interface * @notice Function to approve escrow deal and confirm success * @param Some comment * @return Success of operation **/ function confirm(notice) public onlyArbitrage only_after_close_time returns(bool) { confirmed(getNow(), notice); } /** * @notice ESCB9 interface * @notice Function to freeze escrow deal * @param Some comment * @return Success of operation **/ function freeze(notice) public onlyArbitrage only_after_close_time returns(bool) { frozen(getNow(), notice); } /** * @notice ESCB9 interface * @notice Function to dispute escrow deal * @return Success of operation **/ function dispute() public onlyArbitrage only_after_close_time returns(bool) { disputed(getNow(), notice); } /** * @notice ESCB9 interface * @notice Function to cancel escrow deal and confirm fail * @return Success of operation **/ function cancel() public onlyArbitrage only_before_close_time returns(bool) { canceled(getNow(), notice); } /** * @notice Get current unix time stamp **/ function getNow() constant public returns (uint) { return now; } /** * @notice Get private information for buyer when seller sent deposit **/ function getExternalIncomingAddress() constant isDeposited public returns (bytes) { return externalIncomingAddress; } /** * @notice Get private information about amount for seller for sending deposit **/ function getExternalDepositAmount() constant public returns (bytes) { return externalDepositAmount; } /** * @notice Get private information about address for seller for sending deposit **/ function getExternalDepositAddress() constant public returns (bytes) { return externalDepositAddress; } } 

9 arbitration nodes

To maintain the operation of the trust system, a hierarchy of multi-subscription wallets is introduced. Arbitrage nodes, that is, such purses in the hierarchy, which has a child purse under it act as guarantors of dispute resolution. Plenipotentiary participants for such nodes can only be appointed by the arbitrator superior in the hierarchy. Each plenipotentiary participant receives a reward by distributing dividends and bonuses for working with controversial interaction flows. The size of bonuses is determined by consensus.
To obtain the status of an authorized participant in an arbitration node, you must have a consensus sum of tokens at the address of an authorized participant. Thus, stable receipt of dividends is guaranteed by all participants of arbitration nodes. , .

10

Ethereum – , . , .
– Solidity, , Ethereum, .
() – , , . , .
– , , . . , .
– , , . . , .