Hierarchy multisignature 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 about each other reliable information, the risk of fraud increases. This abstraction allows programming in a decentralized network a dispute resolution model, a model for conducting automatic transactions, protected transactions, etc. At the same time, such a model of the trust system is open. All transactions conducted with the participation of the hierarchy of multisignature wallets allow you to rate the counterparty’s rating, as well as to protect against fraudulent schemes of new participants in economic relations.

Contents

Introduction

1 Description multisignature wallet

2 Ways of constructing hierarchy wallets

3 Interface hierarchy multisignature wallets

4 Flows interactions

4.1 Standard interaction flow

4.2 Protected interaction flow

4.3 Disputed flow interaction

5 Protocol ESCB9

6 Integration trust system and smart contracts ESCB9 implementing protocols

7 Examples of contracts that are implemented ESCB9

7.1 Smart contract for the rental market of private real estate, following the example of AirBnb

7.2 Smart contract for the exchange of any cryptocurrency for fiat money and back, in decentralized mode

8 Arbitration nodes

9 Developing your own network for the trust system

10 Glossary

Introduction

1 Description multisignature wallet

  1. the constructor accepts the addresses of the founding participants and the number of mandatory minimum confirmations for the execution of transactions

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

2. for interface with authorized parties

2.1 getting a list of participants

static getMembers() -> address[]:address

2.2 view address of participant

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

2.3 checking the address for belonging to the participant

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

2.4 obtaining the maximum number of participants for the wallet

static getMaxMemberCount() -> uint256:value

2.5 obtaining the minimum number of confirmations for consensus

static getRequiredConfirmationCount() -> uint256:value

2.6 new member event

event MemberAddition() -> address:member

2.7 event to delete a member

event MemberRemoval() -> address:member

2.8 event of a change in the mandatory number of confirmations to be performed

event RequiredConfirmationCountChange() -> uint256:count

2.9 add participant

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

2.10 removal of participant

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

2.11 replacement participants

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

2.12 change the number of mandatory confirmations to be performed

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

3. interface for working with transactions

3.1 verification of transaction confirmation at the participant’s address

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

3.2 obtaining information from a transaction

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

3.3 obtaining total number of transactions in this wallet

static getTransactionCount() -> uint256:value

3.4 receiving the status of transaction confirmation

static isConfirmed(uint256:transactionId) -> bool:value
3.5 obtaining the number of confirmations

static getConfirmationCount(uint256:transactionId) -> uint256:count
3.6 obtaining the number of transactions by type

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

3.7 receiving a list of participants who confirmed the transaction

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

3.8 receiving a list of transaction ids by type in a certain period of time

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

3.9 event for transaction confirmation by a participant

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

3.10 event of confirmation of a participant’s confirmation prior to the execution of a transaction

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

3.11 event of adding a transaction to the queue

event Submission() -> [uint256:transactionId]

3.12 transaction execution event

event Execution() -> [uint256:transactionId]

3.13 error event when the transaction is executed

event ExecutionFailure -> [uint256:transactionId]

3.14 charge event

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

3.15 adding a transaction to a member

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

3.16 transaction confirmation by the participant

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

3.17 confirmation of the participant’s confirmation

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

3.18 manual transaction execution

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

2 Ways of constructing hierarchy wallets

As we see the horizontal path of constructing may be a subspecies of the vertical way of building. Therefore, drop this approach without attention.

3 Interface hierarchy multisignature wallets

  1. The constructor takes the address of the parent wallet, the addresses of the founding members, the number of mandatory minimum confirmations for the transactions, the standard time for automatic acknowledgments in seconds

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

2. Interface for working with participants

2.1 getting a list of participants

static getMembers() -> address[]:address

2.2 function for viewing the address of the participant

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

2.3 checking the address for belonging to the participant

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

2.4 obtaining the maximum number of participants in the wallet

static getMaxMemberCount() -> uint256:value

2.5 obtaining the minimum number of confirmations for consensus

static getRequiredConfirmationCount() -> uint256:value

2.6 event of adding a new participant

event MemberAddition() -> address:member

2.7 event of removing a member

event MemberRemoval() -> address:member

2.8 event of changing in the mandatory number of confirmations to be performed

event requiredConfirmationCountChange() -> uint256:count

2.9 adding a participant

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

2.10 removal a participant

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

2.11 replacement a participant

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

2.12 change the number of mandatory confirmations to be performed

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

3. interface to work with the hierarchy

3.1 getting a list of child wallets

static getChildren() -> address[]:wallets

3.2 checking whether the wallet address is a child of the current

static isChild() -> bool:value

3.3 check whether the wallet address is parental to the current one through isChild by opposing.

3.4 child wallet attachment event

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

3.5 event removing the child wallet

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

3.6 The event is a change of address parental wallet

event childNewParent() -> [address:oldAddress, address:newAddress,uint256:timeStamp]

3.7 attach child wallet

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

3.8 removal of the child wallet

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

3.9 change one child wallet to another

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

4. interface for transactions

4.1 checking the status of the transaction for compliance

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

4.2 transaction status checking for compliance with

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

4.3 verification of transaction confirmation at the participant’s address

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

4.4 receiving information from a transaction

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

4.5 obtaining the total number of transactions in a wallet

static getTransactionCount() -> uint256:value

4.6 receiving the status of transaction confirmation

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

4.7 obtaining the number of confirmations

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

4.8 obtaining the number of transactions by type

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

4.9 receiving a list of participants who confirmed the transaction

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

4.10 receiving time for auto-confirmation

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

4.11 receiving a list of transaction ids by type in a certain period of time

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

4.12 transaction confirmation of a participant

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

4.13 automatic transaction confirmation event

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

4.14 event of confirmation of a participant’s confirmation prior to the execution of a transaction

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

4.15 event of adding a transaction to the queue

event Submission() -> [uint256:transactionId]

4.16 transaction execution event

event Execution() -> [uint256:transactionId]

4.17 event of an error during the transaction

event ExecutionFailure -> [uint256:transactionId]

4.18 change event transaction status to frozen

event TransactionFrozen -> [uint256:transactionId]

4.19 transaction status change event to the disputed

event TransactionDisputed -> [uint256:transactionId]

4.20 transaction status change event on the returned

event TransactionReverted -> [uint256:transactionId]

4.21 wallet replenishment event

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

4.22 adding a transaction for execution

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

4.23 confirmation transaction

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

4.24 revoke confirmation

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

4.25 change the transaction status to frozen

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

4.26 manual execution transaction

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

5. Rating management

5.1 getting a rating by address

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

5.2 getting the history of the rating by address and serial number

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

5.3 event of adding an entry to the rating by address

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

5.4 adding an entry to the rating by address

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

6. Integration with ESCB9 protocol

6.1 checking at the address whether the smart contract is attached to this wallet with a smart contract with ESCB9 implementation

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

6.2 checking the status of the deposit for a smart contract with ESCB9 attached to this wallet

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

6.3 event of attaching a smart contract with ESCB9 implementation to a wallet

event AttachingESCB9SmartContract -> [address:smartContract]

6.4 event of making a deposit for a smart contract with ESCB9 implementation attached to a wallet

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

6.5 attachment a smart contract with the implementation of ESCB9 to the wallet

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

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

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

4. Flows interactions

  1. Standard. This kind of transaction takes place automatically. Without the participation of authorized participants wallets hierarchy.
  2. Protected. In this form, the transaction may be increased from the standard time for automatic acknowledgment to the time necessary. In this case, the participation of authorized participants wallets hierarchy in the process is mandatory.
  3. Controversial. In this kind of transaction a participant may freeze a transaction. In this case, the participation of authorized participants wallets hierarchy wallets for consensus building is mandatory.

Each wallet in a trust system has a number of authorized participants, and they decree a verdict. For simple reasoning unite all authorized participants wallet in one concept — the arbitrator.

4.1 Standard interaction flow

Counterparty, the owner of the object enters into a transaction with the counterparty, the owner of the funds, in order to exchange. In this case, the object owner creates an intelligent escrow contract by sending a standardized transaction to one of the commissioners of wallets in the hierarchy multisignature wallets. In this case the registration of a third party to the transaction as a confidential system. On each transaction is determined by the standard time to carry it out. Counterparty, the owner of the fund makes a deposit transaction by transferring fund to the trust system. After that, the owner of the object passes an object owner fund. Owner fund checks the quality of the object. If before the end of time for carrying out the transaction, he/she did not confirm the quality, the funds are transferred to the owner of the object in the transaction. Both exhibit counterparty ratings of comfort to each other. Thus, the owner can change the flow means prior to closure of the transaction interaction. After the transfer of funds the owner of the object, the owner of the fund may seek a higher level of the hierarchy of the wallet to resolve disputes within the time limit specified time. After this time the ratings for the transaction are applied to both sides of the deal and it becomes irrecoverable.

4.2 Protected interaction flow

4.3 Disputed flow interaction

5 Protocol ESCB9

6 Integration trust system and smart contracts ESCB9 implementing protocols

7 Examples of contracts that are implemented ESCB9

7.1 Smart contract for the rental market of private real estate, following the example of AirBnb

7.2 Smart contract for the exchange of any cryptocurrency for fiat money and back, in decentralized mode

8 Arbitration nodes

To obtain the status of an authorized member of the arbitration unit, it is necessary to have a certain amount of tokens determined by consensus at the address of the authorized participant. Thus, it is guaranteed stable receipt of dividends by all participants of arbitration nodes. The higher the multi-signature wallet is in the hierarchy, the more required tokens should be present at the authorized member’s address.

9 Developing our own network for the trust system

10 Glossary

Smart contract — written in the language of Solidity, the logic that runs in the virtual machine Ethereum, which allows you to extend the logic of transactions.

A multi-signature wallet (arbitrator) — is a special smart contract controlled by a group of authorized participants who can confirm or cancel transactions. Using the mechanism of multi-signature wallets, you can create a chain of gateways for transactions and timely control the execution or return of funds.

The owner of the object — is the lessor, the supplier, the developer of the software product, etc. That is, the person who implements the object and ultimately receives the deposit as a reward.

The owner of the funds — is the tenant, the buyer, the customer of the software product, etc. That is, the person who places the deposit on the object to purchase the product or service.

The aim of the project is to create an EscrowBlock escrow platform for the Ethereum network blockchain.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store