Hierarchy of multi-subscription wallets (Trust System)
- Transfer
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 the 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 a trust system is open. All transactions carried out with the participation of the multi-subscription purses hierarchy allow to revise the counterparty rating, as well as protect against fraudulent schemes of new participants in economic relations.
1 Introduction
2 Description of a multi-subscription wallet
3 Ways of building a hierarchy of wallets
4 Hierarchy interface of multi-subnet wallets
5 Interaction flows
5.1 Standard interaction flow
5.2 Protected interaction flow
5.3 Disputed interaction flow
6 ESCB9 protocol
7 Integration of trust system and ESCB9 smart contracts
8 ESCB9 examples of contracts that implement ESCB9
8.1 Smart contract for the private property rental market following the example of AirBnb
8.2A smart contract to exchange any cryptocurrency for fiat money and back in decentralized mode
9 Arbitrage nodes
10 Vocabulary
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,
The abstraction that allows you to confirm or cancel transactions only under the condition that a consensus is reached between 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:
There are two main ways to build a trust system. Vertical and horizontal. The horizontal path of construction involves the creation of one main parent list of subsidiary wallets. The vertical construction path 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 construction path may be a subtype of the vertical construction path. Therefore, further we leave this approach without attention.
To build a trusting system, it is necessary to extend the simple interface of the multi-subscription purse described above, by adding mechanisms for regulating the hierarchy and automatic execution of confirmations, as well as the possibility of deferred execution.
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:
Each wallet in the trust system has a number of authorized participants, who make a verdict. For simple reasoning, we will unite all the plenipotentiaries of the wallet into one concept - the arbitrator .
For simplicity, we will bring the concepts of goods and services to the concept of an object of transfer (object), and the concept of fiat money, cryptocurrency to the concept of a 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 time to conduct the transaction, he did not confirm the quality, then 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 that is higher in the hierarchy level for resolving disputes within a certain time limit. After this time has elapsed, the ratings for the transaction are applied to both parties and the transaction becomes non-refundable.
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 a change in time, the transaction flow that is diverted to the transaction returns to the logic level of the standard 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.
An example of the ESCB9 protocol in the Solidity language as an abstract smart contract (the protocol is under development and can be changed)
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”.
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.
To support the operation of the trust system, a hierarchy of multi-subscription wallets is introduced. Arbitrage nodes, that is, such wallets in the hierarchy, which has a child wallets, act as guarantors of dispute resolution. Plenipotentiary participants for such nodes can be appointed only 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, a stable receipt of dividends is guaranteed by all participants of arbitration nodes. The higher in the hierarchy is a multi-subscription purse, the more necessary tokens must be present at the address of the authorized participant.
Ethereum is an open source technology that allows you to create a decentralized, unchanging chain of transactions. Each transaction can be executed with certain conditions recorded in a smart contract.
Smart contract - written in the language of Solidity, the logic that runs in the Ethereum virtual machine, which allows you to expand the logic of transactions.
A multi-subscription purse (arbitrator) is a special smart contract controlled by a group of authorized participants who can confirm or cancel transactions. Using the mechanism of multi-subscription purses, you can create a chain of gateways for transactions and timely monitor the execution or return of funds.
The owner of the object is the landlord, supplier, developer of the software product, etc. That is, the person who realizes the object and ultimately receives a deposit as a reward.
The owner of the funds is the tenant, buyer, customer of the software product, etc. That is, the person who places a deposit on the object to purchase a product or service.
Depositing funds is a fundamental part of any transaction. If the 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 a trust system is open. All transactions carried out with the participation of the multi-subscription purses hierarchy allow to revise the counterparty rating, as well as protect against fraudulent schemes of new participants in economic relations.
Content
1 Introduction
2 Description of a multi-subscription wallet
3 Ways of building a hierarchy of wallets
4 Hierarchy interface of multi-subnet wallets
5 Interaction flows
5.1 Standard interaction flow
5.2 Protected interaction flow
5.3 Disputed interaction flow
6 ESCB9 protocol
7 Integration of trust system and ESCB9 smart contracts
8 ESCB9 examples of contracts that implement ESCB9
8.1 Smart contract for the private property rental market following the example of AirBnb
8.2A smart contract to exchange any cryptocurrency for fiat money and back in decentralized mode
9 Arbitrage nodes
10 Vocabulary
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,
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 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:
- The constructor accepts the addresses of the founding members and the number of required minimum confirmations for the execution of transactions.
constructor(address[]:members, uint256:requiredConfirmationCount) - Interface for working with authorized members
- getting the list of participants
static getMembers() -> address[]:address - view member address
static getMember(uint256:indexNumber) -> address:address - checking the address of membership
static isMember(address:address) -> bool:value - getting the maximum number of participants for the wallet
static getMaxMemberCount() -> uint256:value - getting a minimum amount of evidence for consensus
static getRequiredConfirmationCount() -> uint256:value - event of adding a new member
event MemberAddition() -> address:member - event delete member
event MemberRemoval() -> address:member - event change required number of confirmations to execute
event RequiredConfirmationCountChange() -> uint256:count - adding member
execute addMember(address:member) -> void:value - remove member
execute removeMember(address:member) -> void:value - member replacement
execute replaceMember(address:currentMember, address:newMember) -> void:value - change the number of required confirmations to perform
execute changeRequiredConfirmationCount(uint256:count) -> void:value
- getting the list of participants
- Transaction Interface
- verification of transaction confirmation at the member's address
static getConfirmationByAddress(uint256:indexNumber, address:addressMember) -> bool:value - getting information from a transaction
static getTransactionInfo(uint256:indexNumber) -> [address:destination, uint256:value, bytes:data, bool:executed] - getting total transactions in this wallet
static getTransactionCount() -> uint256:value - getting transaction confirmation status
static isConfirmed(uint256:transactionId) -> bool:value - receipt of confirmations
static getConfirmationCount(uint256:transactionId) -> uint256:count - getting the number of transactions by type
static getTransactionCount(bool:pending, bool:executed) -> uint256:count - getting the list of participants who confirmed the transaction
static getConfirmations(uint256:transactionId) -> address[]:confirmations - 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 - event confirming transaction by member
event Confirmation() -> [address:sender, uint256:transactionId, uint256:timeStamp] - event of a member confirmation revocation before a transaction
event Revocation() -> [address:sender, uint256:transactionId, uint256:timeStamp] - event of adding a transaction to the queue
event Submission() -> [uint256:transactionId] - transaction execution event
event Execution() -> [uint256:transactionId] - error event during transaction
event ExecutionFailure -> [uint256:transactionId] - wallet replenishment event
event Deposit -> [address:sender, uint256:amount] - add transaction by member
execute submitTransaction(address:destination, uint256:value, bytes:data) -> uint256:transactionId - confirmation of transaction by member
execute confirmTransaction(uint256:transactionId) -> void:value - member confirmation feedback
execute revokeConfirmation(uint256:transactionId) -> void:value - manual execution of a transaction
execute executeTransaction(uint256:transactionId) -> void:value
- verification of transaction confirmation at the member's address
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 of one main parent list of subsidiary wallets. The vertical construction path 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 construction path may be a subtype of the vertical construction path. Therefore, further we leave this approach without attention.
4 Hierarchy Interface of Multi-Purpose Wallets
To build a trusting system, it is necessary to extend the simple interface of the multi-subscription purse described above, by adding mechanisms for regulating the hierarchy and automatic execution of confirmations, as well as the possibility of deferred execution.
- 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) - Interface to work with participants
- getting the list of participants
static getMembers() -> address[]:address - function to view member address
static getMember(uint256:indexNumber) -> address:address - checking the address of membership
static isMember(address:address) -> bool:value - getting the maximum number of participants in the wallet
static getMaxMemberCount() -> uint256:value - getting a minimum amount of evidence for consensus
static getRequiredConfirmationCount() -> uint256:value - event of adding a new member
event memberAddition() -> address:member - event delete member
event memberRemoval() -> address:member - event change required number of confirmations to execute
event requiredConfirmationCountChange() -> uint256:count - adding member
execute addMember(address:member) -> void:value - remove member
execute removeMember(address:member) -> void:value - member replacement
execute replaceMember(address:currentMember, address:newMember) -> void:value - change the number of required confirmations to perform
execute changeRequiredConfirmationCount(uint256:count) -> void:value
- getting the list of participants
- Hierarchy Interface
- getting a list of child wallets
static getChildren() -> address[]:wallets - checking whether the wallet address is a child of the current one
static isChild() -> bool:value - checking whether the wallet address is parental to the current one is done through isChild by contrasting.
- child wallet attach event
event childAttachment() -> [address:address,uint256:timeStamp] - child wallet deletion event
event childRemoval() -> [address:address,uint256:timeStamp] - child wallet attachment
execute attachChild(addres:child) -> void:value - removal of a child wallet
execute removeChild(address:address) -> void:value - change one child wallet to another
execute replaceChild(address:newAddress) -> void:value
- getting a list of child wallets
- Transaction Interface
- transaction status check
static getTransactionStatus(uint256:transactionId) -> enum:{submitted,completed,frozen,disputed,reverted} - checking the status of a transaction for compliance
static isTransactionStatus(uint256:transactionId, uint256:enumStatusNumber) -> bool:value - verification of transaction confirmation at the member's address
static getConfirmationByAddress(uint256:transactionId, address:addressMember) -> bool:value - getting information from a transaction
static getTransactionInfo(uint256:transactionId) -> [address:destination, uint256:value, bytes:data, bool:executed] - getting the total number of transactions in the wallet
static getTransactionCount() -> uint256:value - getting transaction confirmation status
static isConfirmed(uint256:transactionId) -> bool:value - receipt of confirmations
static getConfirmationCount(uint256:transactionId) -> uint256:count - getting the number of transactions by type
static getTransactionCount(bool:pending, bool:executed) -> uint256:count - getting the list of participants who confirmed the transaction
static getConfirmations(uint256:transactionId) -> address[]:confirmations - getting time to auto-confirm
static getTimeAutoConfirmation(uint256:transactionId) -> uint256:timestamp - 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 - event confirming transaction by member
event Confirmation() -> [address:sender, uint256:transactionId, uint256:timeStamp] - automatic transaction confirmation event
event AutoConfirmation() -> [uint256:transactionId, uint256:timeStamp] - event of a member confirmation revocation before a transaction
event Revocation() -> [address:sender, uint256:transactionId, uint256:timeStamp] - event of adding a transaction to the queue
event Submission() -> [uint256:transactionId] - transaction execution event
event Execution() -> [uint256:transactionId] - error event during transaction
event ExecutionFailure -> [uint256:transactionId] - transaction status change event frozen
event TransactionFrozen -> [uint256:transactionId] - transaction status change event at issue
event TransactionDisputed -> [uint256:transactionId] - transaction status change event returned
event TransactionReverted -> [uint256:transactionId] - wallet replenishment event
event Deposit -> [address:sender, uint256:amount] - add transaction to execute
execute submitTransaction(address:destination, uint256:value, uint256:TimeAutoConfirmation, bytes:data) -> uint256:transactionId - transaction confirmation
execute confirmTransaction(uint256:transactionId) -> void:value - confirmation feedback
execute revokeConfirmation(uint256:transactionId) -> void:value - change transaction status to frozen
execute setTransactionStatus(uint256:transactionId, uint256:enumStatusNumber) -> void:value - manual execution of a transaction
execute executeTransaction(uint256:transactionId) -> void:value
- transaction status check
- Rating Management
- getting a rating at
static getRatingByAddress(address:agent) -> [uint256:negativeRating, uint256:positiveRating, uint256:countRatingRecords] - getting rating history by address and order number
static getRatingRecordForAddress(address:agent, uint256:indexNumber) -> void:value - 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] - adding an entry to the rating for the address
execute addRatingRecord(address:agent, bytes32:smartContractAddress, bool:positiveOrNegative, uin256:ratingNumber, bytes:comment) -> void:value
- getting a rating at
- Integration with ESCB9 protocol
- Checking whether the smart contract is attached to this wallet is a smart contract with ESCB9 implementation
static isAttachedESCB9SmartContract(address:smartContract) -> bool:result - check the status of the deposit for a smart contract with ESCB9 attached to this wallet
static getDepositStatusForESCB9SmartContract(address:smartContract) -> enum:{awaiting,founded,returned} - smart contract attach event with ESCB9 implementation to wallet
event AttachingESCB9SmartContract -> [address:smartContract] - deposit event for smart contract with ESCB9 implementation attached to wallet
event ConfirmationForDepositESCB9SmartContract -> [address:smartContract, uint256:sum, bytes:notice] - attaching a smart contract with the implementation of ESCB9 to the wallet
execute attachESCB9SmartContract(address:smartContract) -> void:value - 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
- Checking whether the smart contract is attached to this wallet is a smart contract with ESCB9 implementation
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 transaction time can be increased from the standard time for automatic confirmation of the time to the required one. 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 to reach 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 plenipotentiaries 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 an object of transfer (object), and the concept of fiat money, cryptocurrency to the concept of a 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 time to conduct the transaction, he did not confirm the quality, then 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 that is higher in the hierarchy level for resolving disputes within a certain time limit. After this time has elapsed, 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 a change in time, the transaction 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
**/functionconfirm(notice) publiconlyArbitragereturns(bool);
/**
* @noticeFunctiontofreezeescrowdeal
* @returnSuccessofoperation
**/
functionfreeze(notice) publiconlyArbitragereturns(bool);
/**
* @noticeFunctiontodisputeescrowdeal
* @returnSuccessofoperation
**/
functiondispute(notice) publiconlyArbitragereturns(bool);
/**
* @noticeFunctiontocancelescrowdealandconfirmfail
* @returnSuccessofoperation
**/
functioncancel(notice) publiconlyArbitragereturns(bool);
/**
* @noticeFunctiontogetseller'saddress
* @returnSeller'saddress
**/
functionseller() publicreturns(address);
/**
* @noticeFunctiontogetcustomtypeforESCB9smartcontract
* @returnType
**/
functiontype() publicreturns(bytes);
/**
* @noticeFunctiontogetbuyer'saddress
* @returnBuyer'saddress
**/
functionbuyer() publicreturns(address);
/**
* @noticeFunctiontogetsumfordeal
* @returnSumofdealinwei
**/
functiondepositedSum() publicreturns(uint256);
/**
* @noticeFunctiontogetarbitrage'saddress
* @returnArbitrage'saddress
**/
functionarbitrage() publicreturns(address);
}
7 Integration of a 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
**/functionseller() publicreturns(address) {
return"0x27a36731337cdee360d99b980b73e24f6e188618";
}
/**
* @notice ESCB9 interface
* @notice Function to get custom type for ESCB9 smart contract
* @return Type
**/functiontype() publicreturns(bytes) {
return"rent";
}
/**
* @notice ESCB9 interface
* @notice Function to get address of renter
* @return Buyer's address
**/functionbuyer() publicreturns(address) {
return"0xb582baaF7e749d6aA98A22355A9d08B4c4d013C8";
}
/**
* @notice ESCB9 interface
* @notice Function to get sum for deal
* @return Sum of deal in wei
**/functiondepositedSum() publicreturns(uint256) {
return1000000000000000000; //1 ETH in weis
}
/**
* @notice ESCB9 interface
* @notice Function to get arbitrage's address
* @return Arbitrage's address
**/functionarbitrage() publicreturns(address) {
return"0xe91065d8bb2392121a8fbe6a81e79782fbc89dd4";
}
/**
* @notice ESCB9 interface
* @notice Function to approve escrow deal and confirm success
* @param Some comment
* @return Success of operation
**/functionconfirm(notice) publiconlyArbitrageonly_after_check_outreturns(bool) {
confirmed(getNow(), notice);
}
/**
* @notice ESCB9 interface
* @notice Function to freeze escrow deal
* @param Some comment
* @return Success of operation
**/functionfreeze(notice) publiconlyArbitrageonly_during_rentingreturns(bool) {
frozen(getNow(), notice);
}
/**
* @notice ESCB9 interface
* @notice Function to dispute escrow deal
* @return Success of operation
**/functiondispute() publiconlyArbitrageonly_after_check_outreturns(bool) {
disputed(getNow(), notice);
}
/**
* @notice ESCB9 interface
* @notice Function to cancel escrow deal and confirm fail
* @return Success of operation
**/functioncancel() publiconlyArbitrageonly_not_in_during_rentingreturns(bool) {
canceled(getNow(), notice);
}
/**
* @notice Get current unix time stamp
**/functiongetNow()
constantpublicreturns (uint) {
return now;
}
/**
* @notice Get private information when renter will pay deposit
**/functiongetPrivateInformation()
constantisDepositedpublicreturns (bytes) {
return privateInformation;
}
}
8.2 Smart contract to exchange any cryptocurrency for fiat money 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 timeconst 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
**/functionseller() publicreturns(address) {
return"0x27a36731337cdee360d99b980b73e24f6e188618";
}
/**
* @notice ESCB9 interface
* @notice Function to get custom type for ESCB9 smart contract
* @return Type
**/functiontype() publicreturns(bytes) {
return"exchange";
}
/**
* @notice ESCB9 interface
* @notice Function to get address of renter
* @return Buyer's address
**/functionbuyer() publicreturns(address) {
return"0xb582baaF7e749d6aA98A22355A9d08B4c4d013C8";
}
/**
* @notice ESCB9 interface
* @notice Function to get sum for deal
* @return Sum of deal in minimal decimals
**/functiondepositedSum() publicreturns(uint256) {
rerurn outputAmount;
}
/**
* @notice ESCB9 interface
* @notice Function to get arbitrage's address
* @return Arbitrage's address
**/functionarbitrage() publicreturns(address) {
return"0xe91065d8bb2392121a8fbe6a81e79782fbc89dd4";
}
/**
* @notice ESCB9 interface
* @notice Function to approve escrow deal and confirm success
* @param Some comment
* @return Success of operation
**/functionconfirm(notice) publiconlyArbitrageonly_after_close_timereturns(bool) {
confirmed(getNow(), notice);
}
/**
* @notice ESCB9 interface
* @notice Function to freeze escrow deal
* @param Some comment
* @return Success of operation
**/functionfreeze(notice) publiconlyArbitrageonly_after_close_timereturns(bool) {
frozen(getNow(), notice);
}
/**
* @notice ESCB9 interface
* @notice Function to dispute escrow deal
* @return Success of operation
**/functiondispute() publiconlyArbitrageonly_after_close_timereturns(bool) {
disputed(getNow(), notice);
}
/**
* @notice ESCB9 interface
* @notice Function to cancel escrow deal and confirm fail
* @return Success of operation
**/functioncancel() publiconlyArbitrageonly_before_close_timereturns(bool) {
canceled(getNow(), notice);
}
/**
* @notice Get current unix time stamp
**/functiongetNow()
constantpublicreturns (uint) {
return now;
}
/**
* @notice Get private information for buyer when seller sent deposit
**/functiongetExternalIncomingAddress()
constantisDepositedpublicreturns (bytes) {
return externalIncomingAddress;
}
/**
* @notice Get private information about amount for seller for sending deposit
**/functiongetExternalDepositAmount()
constantpublicreturns (bytes) {
return externalDepositAmount;
}
/**
* @notice Get private information about address for seller for sending deposit
**/functiongetExternalDepositAddress()
constantpublicreturns (bytes) {
return externalDepositAddress;
}
}
9 arbitration nodes
To support the operation of the trust system, a hierarchy of multi-subscription wallets is introduced. Arbitrage nodes, that is, such wallets in the hierarchy, which has a child wallets, act as guarantors of dispute resolution. Plenipotentiary participants for such nodes can be appointed only 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, a stable receipt of dividends is guaranteed by all participants of arbitration nodes. The higher in the hierarchy is a multi-subscription purse, the more necessary tokens must be present at the address of the authorized participant.
10 Dictionary
Ethereum is an open source technology that allows you to create a decentralized, unchanging chain of transactions. Each transaction can be executed with certain conditions recorded in a smart contract.
Smart contract - written in the language of Solidity, the logic that runs in the Ethereum virtual machine, which allows you to expand the logic of transactions.
A multi-subscription purse (arbitrator) is a special smart contract controlled by a group of authorized participants who can confirm or cancel transactions. Using the mechanism of multi-subscription purses, you can create a chain of gateways for transactions and timely monitor the execution or return of funds.
The owner of the object is the landlord, supplier, developer of the software product, etc. That is, the person who realizes the object and ultimately receives a deposit as a reward.
The owner of the funds is the tenant, buyer, customer of the software product, etc. That is, the person who places a deposit on the object to purchase a product or service.