From 49970073663413473ed9d9abc05535dfe594696e Mon Sep 17 00:00:00 2001 From: Taconator Date: Mon, 16 Apr 2018 10:25:52 -0400 Subject: [PATCH 01/11] Initial draft of escrow BSIP --- bsip-0040.md | 235 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 235 insertions(+) create mode 100644 bsip-0040.md diff --git a/bsip-0040.md b/bsip-0040.md new file mode 100644 index 0000000..7a95888 --- /dev/null +++ b/bsip-0040.md @@ -0,0 +1,235 @@ + BSIP: 0040 + Title: Escrow Feature + Authors: taconator + Status: Draft + Type: Informational + Created: 2018-04-16 + Discussion: + +# Abstract + +# Motivation +The ability to escrow assets on BitShares is a desirable feature that could be used by many persons, services, and businesses. It permits conditional transfers between parties to occur that minimize or eliminate risks to a depositor/sender while conditions are being evaluated. Conditions for completion of a transfer can be evaluated by an escrow agent of some form whether a human and/or a software agent such as the blockchain agent. If all the conditions are evaluated to be true (a positive evaluation) during the evaluation period, then assets are transferred to an intended recipient(s). If the conditions are never evaluated to be positive (either due to an active evaluation or due to no evaluation whatsoever), then the assets are returned to the depositor(s). + +# Rational +## Elements of a General Escrow Contract + +An escrow contract is defined to have the following elements: + +* parties to the escrow contract +* assets that are being escrowed +* escrow period start and end (expiry) +* conditions for escrow completion +* condition evaluators +* escrow agent and fee +* when and how frequently are escrow conditions evaluated +* what occurs when all conditions are satisfied +* what occurs at conclusion of escrow period if all the conditions have not been satisfied + +### Parties + +At least two parties must be defined for an escrow contract: at least one depositor, and at least one intended recipient. (Escrow agents are not defined here to be a "party" of the escrow contract [**To-do**: perhaps use better terminology]. + +### Escrow Assets +An escrow involves a conditional transfer of ownership of at least one item from one party (a depositor) to another (an intended recipient). An escrow is used to temporarily hold **some or all** of these items while the conditions are being evaluated during the escrow period. Upon satisfaction of the escrow conditions, the escrowed items will be transferred to the intended recipient. If the conditions are not satisfied by the expiry then the escrowed items are to be returned to the depositor. If certain conditions are met, the escrowed items can be returned early to the depositor before the expiry with the approval of designated parties (e.g. either all participants of an escrow and/or by the escrow agent). + +For definition purposes, let an item that will be transferred from Party A to Party B upon completion of the escrow conditions to be called Item AB. Let an item that will be transferred from Party B to Party A upon completion of the escrow conditions to be called Item BA. + +### Conditions + +The conditions of an escrow contract involve events about other people, assets, and/or actions that are beyond the control of the escrow agent. One such example is the transfer of property between the parties of the contract by means which the escrow agent can at most observe. Whoever or whatever will evaluate the conditions of a contract must somehow obtain information about these events, perhaps with assistance by the escrow parties (e.g. by providing proof of this external activity), to evaluate the conditions. + +### Condition Evaluators + +The evaluators of the conditions of an escrow condition can be designated in the contract to be tiered such that if the first tier cannot reach an agreement, then the second tier will be tasked with performing the evaluation. + +For example, the first tier of evaluators could consist of the escrow parties themselves (e.g. Parties A and B). If the parties agree on the evaluation, then the escrow transfer can proceed according to the designated terms (e.g. transfer of Item AB from A to B if conditions are satisfied, or return of Item AB to A if the conditions are not satisfied before the expiry). If the conditions are not satisfied by the expiry, then the escrowed items will automatically be returned to their depositors. + +### Timing of Condition Evaluation + +The timing of a condition evaluation is quite flexible and can vary from a single occurrence at near the expiry, or periodically during the escrow period, and/or triggered by certain events or activities. + + +### Escrow Agent and Fee + +An escrow agent can be used to perform distinct services: + +- to evaluate the conditions of the escrow agreement; +- to hold the escrowed asset(s) during the escrow period; if holding the assets, to transfer the escrowed assets to the appropriate parties contingent on the condition evaluation + +An escrow agent is often paid a fee for these services before the escrow period begins and regardless of condition evaluation. + +If an escrow will be performing condition evaluations, it should be granted reasonable amount of time to perform the condition evaluation. Furthermore, to avoid allegations of negligence, an escrow agent can benefit from the ability to demonstrate that an evaluation of the conditions(s) with a negative outcome (a negative evaluation) was performed. + +### What Occurs when Conditions are Satisfied + +When all the conditions are evaluated to be satisfied, the escrowed assets are expected to be transferred to the intended recipient. This transfer could be automated or require human action to initiate. + +### Early Termination of an Escrow Contract + +TBD: When intended recipient or escrow agent decide to terminate an escrow contract early such that the assets are returned to the depositor + +### Conclusion of Escrow without Satisfied Conditions + +If an escrow contract concludes without all the conditions being satisfied, a typical escrow contract has the escrowed asset(s) being returned to the depositor. This might be automatic process, or might require an action by the escrow agent. + + +## Elements of a Blockchain Escrow Contract + +An escrow contract on a blockchain can have certain qualities that are distinctive from a general escrow contract. Some of these differences are described in this section. + +### Condition Evaluation on a Blockchain + +#### Off-Chain Escrow Evaluation + +Off-chain escrow evaluations involves either a human(s) or an off-chain agent(s) making the evaluation regarding escrow conditions (e.g. escrow agent, Etienne, evaluates whether Bob satisfied the escrow conditions before releasing an asset from Alice to Bob). If all conditions are evaluated to be satisfied by the appropriate escrow parties or agent, then they can indicate their approval to the contract, and then the defined contract transfers will occur. If the appropriate approvals are not granted by the expiry, then the escrow deposits will be returned to the depositors. + +#### On-Chain Escrow Evaluation With Oracles + +On-chain escrow evaluations with oracles involves an escrow contract that can be evaluated by the blockchain itself by reviewing data that is submitted by a trusted party who can observe events outside of the blockchain (oracle). An example of such data could be the temperature at a location on a particular date. Such a contract would require the following: +- A contract state that consists in part on this temperature data (e.g. a decimal variable); +- a software contract that can interpret this data; +- a trusted oracle that can submit/update this information in the contract state. + +A variation on this idea is where the contract state consists of a particular asset DEX price, market condition on the DEX, and/or an account balance on the DEX so that no new data would be required. Under this variation the trusted oracles are account holders who initiate DEX transactions and the blockchain that processes those transactions. + +Either evaluation involves a contract, similar in nature to the existing DEX market processing, being designed for a particular contract. + +### Automatic Transfers Upon Expiry + +Upon expiry of the evaluation period, the assets that are held by the blockchain will automatically be returned to their depositors. + +### Agent and Fee on a Blockchain + +With the use of a blockchain, it is possible for the blockchain to hold the escrowed asset(s) while the escrow agent merely performs the condition evaluation. (A variant of this notion is that an escrow could act as an oracle to submit raw data to the blockchain that permits the blockchain to perform the condition evaluation.) If no action is taken by the escrow, the all escrowed assets will be returned to their depositors. (See [Automatic Transfers Upon Expiry](#automatic-transfer-upon-expiry)) + +When signaling that conditions were evaluated with either a positive or a negative outcome, it would likely be beneficial for the escrow parties and the escrow agent to optionally memorialize either evidence of the condition evaluation, or some sort of "link" or "hash" of the condition evaluation (cite Factom as an example). The ability to explicitly indicate a negative outcome by an escrow agent is beneficial to an escrow agent to reduce the likelihood of allegations of negligence by either of the escrow parties. + +## Existing Escrow Proposals +The section describes various escrow concepts that have been proposed either for BitShares or for other blockchains or services in terms of the elements that have been defined above. This is intended to provide some background and comparison to the concepts that will be described below in [Possible Concepts](#possible-concepts). + +**To-do**: LocalBitcoin type of escrow of fiat for BTC + +**To-do**: Elaborate Steem Escrow + +**To-do**: Elaborate Interledger + +## Existing Graphene Features that are Similar to What is Needed for Blockchain Escrowing + +[**To-do**: Consider moving this section elsewhere] + +### BitShares Multi-Signature Account +One of the existing features of BitShares is the ability to have an account that requires multiples signatures by differently authorized parties [cite] and even hierarchical authorizations. This mechanism has the benefit of escrowing an asset within an account whose transactions can be authorized by different combinations of parties (e.g. either both the depositor and the intended recipient; only the escrow agent; the escrow agent and the depositor; the escrow agent and the intended recipient) and can transfer an asset towards any account. + +This feature can actually satisfy the requirements for "off-chain evaluation" escrowing although it has the burden of requiring a unique account with the appropriate escrow agent and escrow participants for a specific ongoing escrow contract. One option to handle a specific contract would be to create a single-use account for this purpose. Another more technical option would be for the authorities on an account to be re-assigned to the escrow agent upon the completion or expiry of the contract, so that the escrow agent could re-use the account in a future contract by subsequently re-assigning among the agent, and future contract participants. This approach, however, is somewhat complicated, error-prone, and awkward. + +### BitShares Proposals + +One of the existing features of BitShares is the ability to have a proposal that is recorded on the blockchain and awaits the authorization of the requisite parties (e.g. M-of-N signatures). If the required authorizations are not given by the proposal expiry then no transfer will occur. + +This feature alone falls short of what is needed because no asset is actually escrowed while the proposal is awaiting the necessary signatures to complete. Therefore there is no guarantee that the asset will be secured by the time that the final required signature is obtained. + +### Steem Escrow + +**To-do**: Elaborate + +### Atomic Cross Chain Transfers +Atomic Cross Chain Transfers (ACCT) involves the transfer of one asset (Asset A) on one chain (Chain A) from one account (A1) to another account (A2) if another asset (Asset B) on another chain (Chain B) is transferred from one account (B2) to another account (B1). Either both transfer occur or neither do. This functionality has been prototyped between two Graphene chains by the Scorum team [cite]. + +This feature implicitly involves escrowing of Asset A on Chain A while waiting for authorization to complete the transfer to A2. The sub-feature of ACCT could either be duplicated for the escrowing envisioned in this BSIP, or generalized for use by both ACCT and this BSIP. + +# Specifications + +## Possible Concepts to Implement +The following will describe possible escrow concepts that could be implemented in BitShares. + +### Concept A + +|Element|Description| +|-|-| +|Parties|Depositor and intended recipient each have an account on the blockchain| +|Escrow Assets|A quantity of an asset that exists on the blockchain| +|Escrow Period Start and End|Defined in contract| +|Conditions|Conditions describe events that might occur on the blockchain (e.g. does the price of some asset rise above a particular price; etc.) or occur off-chain (e.g. did the escrow intended recipient send 50 fiat USD to the escrow depositor via a bank wire; etc.). These conditions are textually described and are intended to be interpreted by off-chain parties and agent.| +|Condition Evaluators|The condition evaluators are the off-chain depositor and intended recipient, or the escrow agent| +|Reporting on Condition Evaluation Outcome|Whichever off-chain entity is responsible for performing the evaluation must signal the outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| +|Escrow agent and fee|An escrow agent has an account on the blockchain. The fee is defined and paid to the escrow agent [by whom is TBD] as a prerequisite to initiate the escrow contract.| +|When and how frequently are escrow conditions evaluated|When and how **can optionally be** textually described as a part of the escrow contract on the blockchain| +|Who or what evaluates those conditions|The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved. At that point, the escrow agent should, if he is responsible, evaluate the conditions **at least once during the escrow period**; whether the escrow agent performs this evaluation once or multiple times, or early or late during the escrow period is something that **might be** textually defined but which is not enforced by the blockchain. See [Reporting Conditions Evaluation](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct.| +|What Occurs when Conditions are Satisfied|When conditions are signaled to be satisfied by the designated condition evaluators, the assets are automatically transferred to the intended recipient| +|Conclusion of Escrow without Satisfied Conditions|Escrowed assets are automatically returned to the depositors without any action by the escrow agent. See [Avoiding Appearance of Negligence](#escrow-negligence).| + +#### Evaluation of Concept + +This concept has the following weaknesses: + +- It does not clearly delineate when an escrow agent can and should become involved because it is merely described in a textual format that can and need only be interpreted by the off-chain parties and escrow agent. +- It does not guarantee a sufficient amount of time, as negotiated between the escrow parties and escrow agent, for the escrow agent to perform the condition evaluation (e.g. the off-chain party might notify the escrow agent to be perform conditions evaluations only a few seconds before the expiry which is likely to be insufficient notice to properly evaluate the conditions) + +When an escrow agent is expected to become involved **might only** be defined in human-readable text, if at all, and therefore introduces ambiguity and opportunities for abuse by parties and for allegations of misconduct or negligence against the escrow agent. + +Although this concept contains many of the elements that are often desired of an escrow contract, the weaknesses that is has could be addressed by enhancing the concept with features than can be handled by a blockchain. + +#### Technical Approach +TBD + + +### Concept B + +This concept is the same as Concept A except for where **the emphasis** is added. + +|Element|Description| +|-|-| +|Parties|Depositor and intended recipient each have an account on the blockchain| +|Escrow Assets|A quantity of an asset that exists on the blockchain| +|Escrow Period Start and End|Defined in contract; **an additional deadline (invitation deadline) must be specified within the escrow period that defines by when an escrow agent may be invited by either escrow party to begin conditions evaluation**| +|Conditions|Conditions describe events that might occur on the blockchain (e.g. does the price of some asset rise above a particular price; etc.) or occur off-chain (e.g. did the escrow intended recipient send 50 fiat USD to the escrow depositor via a bank wire; etc.). These conditions are textually described and are intended to be interpreted by off-chain parties and agent.| +|Condition Evaluators|The condition evaluators are the off-chain depositor and intended recipient, or the escrow agent| +|Reporting on Condition Evaluation Outcome|Whichever off-chain entity is responsible for performing the evaluation must signal the outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| +|Escrow agent and fee|An escrow agent has an account on the blockchain. The fee is defined and **escrowed for the escrow agent by the blockchain** [by whom is TBD] as a prerequisite to initiate the escrow contract. **The fee is transferred to the agent upon escrow expiry if (a) the escrow agent has _not_ been requested to participate by the invitation deadline, or (b) the escrow agent _has_ been requested to participate by the escrow agent deadline and the agent has submitted at least one report of conditions evaluation**| +|When and how frequently are escrow conditions evaluated|When and how **can optionally be** textually described as a part of the escrow contract on the blockchain. **If an escrow agent is invited by the invitation deadline, then the agent will be expected to report on conditions evaluation at least once between the deadline and the expiry.**| +|Who or what evaluates those conditions|The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved **by the invitation deadline**. At that point, the escrow agent should ~~, if he is responsible,~~ evaluate the conditions **at least once during the escrow period** **if the agent expects to receive the escrow fee**.~~; whether the escrow agent performs this evaluation once or multiple times, or early or late during the escrow period is something that **might be** textually defined but which is not enforced by the blockchain. See [Reporting Conditions Evaluation](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct.~~ **Reporting on conditions evaluation may or may not include a textual description of the evaluation or a proof of a textual description (which can be used to both maintain some privacy for the escrow parties and to minimize on fees associated with the length of a textual report). A report on conditions evaluation must also include the conditions evaluation outcome so that the blockchain can resolve the escrow contract.**| +|What Occurs when Conditions are Satisfied|When conditions are signaled to be satisfied by the designated condition evaluators, the assets are automatically transferred to the intended recipient| +|Conclusion of Escrow without Satisfied Conditions|Escrowed assets are automatically returned to the depositors without any action by the escrow agent. **If an escrow agent is invited to participate, an escrow agent should report at least one condition evaluation on the blockchain to avoid [avoid appearance of negligence](#escrow-negligence)**.| + +#### Evaluation of Concept + +This concept improves on Concept A yet has the following weaknesses: + +- The quality of a condition evaluations report by an escrow agent might be variable yet would be sufficient to ensure itself of receiving the escrow fee from the blockchain +- If an escrow agent is invited, only a single report is required of the escrow agent by the blockchain for the agent receive the escrow fee. + +#### Technical Approach +TBD + + +# Discussion +## Responsible Escrow Behavior +### Reporting Conditions Evaluation + +An escrow agent could publish either a report or a proof of a report on the blockchain to demonstrate the evaluation of conditions. + +A related feature could be that an escrow agent does not even receive payment until this reporting occurs at least once. + +### Avoiding Appearance of Negligence + +To avoid the appearance of negligence, an escrow agent can report when conditions were evaluated and the outcome of that evaluation even when the outcome is negative in order to demonstrate alertness and avoid the appearance of being negligent as an escrow. + +## Rating of Escrow Agents and Parties +A helpful though separation discussion pertains to the rating or evaluation of escrow agents themselves. Such a rating could be as simple as word of mouth, or performed by a third-party, or evaluated by the the parties to previous escrow contracts themselves and memorialized on a some system such as a website or a blockchain. + +A similar argument could be made for evaluating the parties themselves. + +## Dead-Man Switch +Escrow contracts involve transfers from one party to another that are contingent on certain events being observed. A variation on this idea is for a transfer to occur if certain events are not observed. An example of this is a "dead-man switch" wherein a transfer will occur **unless** a party signals activity before the expiry. Such an example bears all the same characteristics as an escrow contract **except** for how to handle the absence of a condition evaluation. For a blockchain escrow contract, the assets are returned to their depositors if no positive indication is given (see [Automatic Transfers Upon Expiry](#automatic-transfer-upon-expiry)). For a dead-man contract, the assets are delivered to the intended recipients if no positive indication is given by the expiry. Some of the work towards blockchain escrow might be reusable or generalizable for dead-man switch use cases (e.g. life insurance, posthumous asset transfers, etc). + +# Summary for Shareholders + +TBD + +# Copyright + +This document is placed in the public domain. + +# See Also + From 909cba843e37aaca9ebeeb5bdeae176708ec56f1 Mon Sep 17 00:00:00 2001 From: Taconator Date: Thu, 19 Apr 2018 17:16:58 -0400 Subject: [PATCH 02/11] Correction to Concept B --- bsip-0040.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsip-0040.md b/bsip-0040.md index 7a95888..29ebb0b 100644 --- a/bsip-0040.md +++ b/bsip-0040.md @@ -184,7 +184,7 @@ This concept is the same as Concept A except for where **the emphasis** is added |Escrow Assets|A quantity of an asset that exists on the blockchain| |Escrow Period Start and End|Defined in contract; **an additional deadline (invitation deadline) must be specified within the escrow period that defines by when an escrow agent may be invited by either escrow party to begin conditions evaluation**| |Conditions|Conditions describe events that might occur on the blockchain (e.g. does the price of some asset rise above a particular price; etc.) or occur off-chain (e.g. did the escrow intended recipient send 50 fiat USD to the escrow depositor via a bank wire; etc.). These conditions are textually described and are intended to be interpreted by off-chain parties and agent.| -|Condition Evaluators|The condition evaluators are the off-chain depositor and intended recipient, or the escrow agent| +|Condition Evaluators|The condition evaluators are the off-chain depositor and intended recipient **unless and until either party "invites" the escrow agent to become the sole evaluator by signaling this invitation on the blockchain**| |Reporting on Condition Evaluation Outcome|Whichever off-chain entity is responsible for performing the evaluation must signal the outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| |Escrow agent and fee|An escrow agent has an account on the blockchain. The fee is defined and **escrowed for the escrow agent by the blockchain** [by whom is TBD] as a prerequisite to initiate the escrow contract. **The fee is transferred to the agent upon escrow expiry if (a) the escrow agent has _not_ been requested to participate by the invitation deadline, or (b) the escrow agent _has_ been requested to participate by the escrow agent deadline and the agent has submitted at least one report of conditions evaluation**| |When and how frequently are escrow conditions evaluated|When and how **can optionally be** textually described as a part of the escrow contract on the blockchain. **If an escrow agent is invited by the invitation deadline, then the agent will be expected to report on conditions evaluation at least once between the deadline and the expiry.**| From 650404d51b68dfde19da1ceb24a91b17e2f9df4a Mon Sep 17 00:00:00 2001 From: Taconator Date: Thu, 19 Apr 2018 17:26:24 -0400 Subject: [PATCH 03/11] Clarification that multiple evaluators (depositor and intended recipient) might be required depending on the concept, and the status of the concept --- bsip-0040.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bsip-0040.md b/bsip-0040.md index 29ebb0b..514a98d 100644 --- a/bsip-0040.md +++ b/bsip-0040.md @@ -152,7 +152,7 @@ The following will describe possible escrow concepts that could be implemented i |Escrow Period Start and End|Defined in contract| |Conditions|Conditions describe events that might occur on the blockchain (e.g. does the price of some asset rise above a particular price; etc.) or occur off-chain (e.g. did the escrow intended recipient send 50 fiat USD to the escrow depositor via a bank wire; etc.). These conditions are textually described and are intended to be interpreted by off-chain parties and agent.| |Condition Evaluators|The condition evaluators are the off-chain depositor and intended recipient, or the escrow agent| -|Reporting on Condition Evaluation Outcome|Whichever off-chain entity is responsible for performing the evaluation must signal the outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| +|Reporting on Condition Evaluation Outcome|Whichever off-chain entities are responsible for performing the evaluation must signal the outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| |Escrow agent and fee|An escrow agent has an account on the blockchain. The fee is defined and paid to the escrow agent [by whom is TBD] as a prerequisite to initiate the escrow contract.| |When and how frequently are escrow conditions evaluated|When and how **can optionally be** textually described as a part of the escrow contract on the blockchain| |Who or what evaluates those conditions|The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved. At that point, the escrow agent should, if he is responsible, evaluate the conditions **at least once during the escrow period**; whether the escrow agent performs this evaluation once or multiple times, or early or late during the escrow period is something that **might be** textually defined but which is not enforced by the blockchain. See [Reporting Conditions Evaluation](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct.| @@ -185,7 +185,7 @@ This concept is the same as Concept A except for where **the emphasis** is added |Escrow Period Start and End|Defined in contract; **an additional deadline (invitation deadline) must be specified within the escrow period that defines by when an escrow agent may be invited by either escrow party to begin conditions evaluation**| |Conditions|Conditions describe events that might occur on the blockchain (e.g. does the price of some asset rise above a particular price; etc.) or occur off-chain (e.g. did the escrow intended recipient send 50 fiat USD to the escrow depositor via a bank wire; etc.). These conditions are textually described and are intended to be interpreted by off-chain parties and agent.| |Condition Evaluators|The condition evaluators are the off-chain depositor and intended recipient **unless and until either party "invites" the escrow agent to become the sole evaluator by signaling this invitation on the blockchain**| -|Reporting on Condition Evaluation Outcome|Whichever off-chain entity is responsible for performing the evaluation must signal the outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| +|Reporting on Condition Evaluation Outcome|Whichever off-chain entities are responsible for performing the evaluation must signal the outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| |Escrow agent and fee|An escrow agent has an account on the blockchain. The fee is defined and **escrowed for the escrow agent by the blockchain** [by whom is TBD] as a prerequisite to initiate the escrow contract. **The fee is transferred to the agent upon escrow expiry if (a) the escrow agent has _not_ been requested to participate by the invitation deadline, or (b) the escrow agent _has_ been requested to participate by the escrow agent deadline and the agent has submitted at least one report of conditions evaluation**| |When and how frequently are escrow conditions evaluated|When and how **can optionally be** textually described as a part of the escrow contract on the blockchain. **If an escrow agent is invited by the invitation deadline, then the agent will be expected to report on conditions evaluation at least once between the deadline and the expiry.**| |Who or what evaluates those conditions|The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved **by the invitation deadline**. At that point, the escrow agent should ~~, if he is responsible,~~ evaluate the conditions **at least once during the escrow period** **if the agent expects to receive the escrow fee**.~~; whether the escrow agent performs this evaluation once or multiple times, or early or late during the escrow period is something that **might be** textually defined but which is not enforced by the blockchain. See [Reporting Conditions Evaluation](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct.~~ **Reporting on conditions evaluation may or may not include a textual description of the evaluation or a proof of a textual description (which can be used to both maintain some privacy for the escrow parties and to minimize on fees associated with the length of a textual report). A report on conditions evaluation must also include the conditions evaluation outcome so that the blockchain can resolve the escrow contract.**| From b627267c5622e7b3f3dde25d78f54aebb8e4ad71 Mon Sep 17 00:00:00 2001 From: Taconator Date: Fri, 20 Apr 2018 00:09:29 -0400 Subject: [PATCH 04/11] Clarification of when and how frequently are escrow conditions evaluated --- bsip-0040.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bsip-0040.md b/bsip-0040.md index 514a98d..51f8560 100644 --- a/bsip-0040.md +++ b/bsip-0040.md @@ -154,7 +154,7 @@ The following will describe possible escrow concepts that could be implemented i |Condition Evaluators|The condition evaluators are the off-chain depositor and intended recipient, or the escrow agent| |Reporting on Condition Evaluation Outcome|Whichever off-chain entities are responsible for performing the evaluation must signal the outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| |Escrow agent and fee|An escrow agent has an account on the blockchain. The fee is defined and paid to the escrow agent [by whom is TBD] as a prerequisite to initiate the escrow contract.| -|When and how frequently are escrow conditions evaluated|When and how **can optionally be** textually described as a part of the escrow contract on the blockchain| +|When and how frequently are escrow conditions evaluated|When and how **can optionally be** textually described as a part of the escrow contract on the blockchain. A positive evaluation must be signaled on the blockchain during the escrow period.| |Who or what evaluates those conditions|The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved. At that point, the escrow agent should, if he is responsible, evaluate the conditions **at least once during the escrow period**; whether the escrow agent performs this evaluation once or multiple times, or early or late during the escrow period is something that **might be** textually defined but which is not enforced by the blockchain. See [Reporting Conditions Evaluation](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct.| |What Occurs when Conditions are Satisfied|When conditions are signaled to be satisfied by the designated condition evaluators, the assets are automatically transferred to the intended recipient| |Conclusion of Escrow without Satisfied Conditions|Escrowed assets are automatically returned to the depositors without any action by the escrow agent. See [Avoiding Appearance of Negligence](#escrow-negligence).| @@ -187,7 +187,7 @@ This concept is the same as Concept A except for where **the emphasis** is added |Condition Evaluators|The condition evaluators are the off-chain depositor and intended recipient **unless and until either party "invites" the escrow agent to become the sole evaluator by signaling this invitation on the blockchain**| |Reporting on Condition Evaluation Outcome|Whichever off-chain entities are responsible for performing the evaluation must signal the outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| |Escrow agent and fee|An escrow agent has an account on the blockchain. The fee is defined and **escrowed for the escrow agent by the blockchain** [by whom is TBD] as a prerequisite to initiate the escrow contract. **The fee is transferred to the agent upon escrow expiry if (a) the escrow agent has _not_ been requested to participate by the invitation deadline, or (b) the escrow agent _has_ been requested to participate by the escrow agent deadline and the agent has submitted at least one report of conditions evaluation**| -|When and how frequently are escrow conditions evaluated|When and how **can optionally be** textually described as a part of the escrow contract on the blockchain. **If an escrow agent is invited by the invitation deadline, then the agent will be expected to report on conditions evaluation at least once between the deadline and the expiry.**| +|When and how frequently are escrow conditions evaluated|When and how can optionally be textually described as a part of the escrow contract on the blockchain. A positive evaluation must be signaled on the blockchain during the escrow period. **If an escrow agent is invited by the invitation deadline, then the agent will be expected to report on conditions evaluation at least once between the deadline and the expiry.**| |Who or what evaluates those conditions|The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved **by the invitation deadline**. At that point, the escrow agent should ~~, if he is responsible,~~ evaluate the conditions **at least once during the escrow period** **if the agent expects to receive the escrow fee**.~~; whether the escrow agent performs this evaluation once or multiple times, or early or late during the escrow period is something that **might be** textually defined but which is not enforced by the blockchain. See [Reporting Conditions Evaluation](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct.~~ **Reporting on conditions evaluation may or may not include a textual description of the evaluation or a proof of a textual description (which can be used to both maintain some privacy for the escrow parties and to minimize on fees associated with the length of a textual report). A report on conditions evaluation must also include the conditions evaluation outcome so that the blockchain can resolve the escrow contract.**| |What Occurs when Conditions are Satisfied|When conditions are signaled to be satisfied by the designated condition evaluators, the assets are automatically transferred to the intended recipient| |Conclusion of Escrow without Satisfied Conditions|Escrowed assets are automatically returned to the depositors without any action by the escrow agent. **If an escrow agent is invited to participate, an escrow agent should report at least one condition evaluation on the blockchain to avoid [avoid appearance of negligence](#escrow-negligence)**.| From 0f76c9c01b47ec2869207bb67b9f78fe0c4bd285 Mon Sep 17 00:00:00 2001 From: Taconator Date: Fri, 20 Apr 2018 00:12:32 -0400 Subject: [PATCH 05/11] Cosmetic changes to Concept A --- bsip-0040.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/bsip-0040.md b/bsip-0040.md index 51f8560..a45a69d 100644 --- a/bsip-0040.md +++ b/bsip-0040.md @@ -165,10 +165,9 @@ This concept has the following weaknesses: - It does not clearly delineate when an escrow agent can and should become involved because it is merely described in a textual format that can and need only be interpreted by the off-chain parties and escrow agent. - It does not guarantee a sufficient amount of time, as negotiated between the escrow parties and escrow agent, for the escrow agent to perform the condition evaluation (e.g. the off-chain party might notify the escrow agent to be perform conditions evaluations only a few seconds before the expiry which is likely to be insufficient notice to properly evaluate the conditions) +- When an escrow agent is expected to become involved **might only** be defined in human-readable text, if at all, and therefore introduces ambiguity and opportunities for abuse by parties and for allegations of misconduct or negligence against the escrow agent. -When an escrow agent is expected to become involved **might only** be defined in human-readable text, if at all, and therefore introduces ambiguity and opportunities for abuse by parties and for allegations of misconduct or negligence against the escrow agent. - -Although this concept contains many of the elements that are often desired of an escrow contract, the weaknesses that is has could be addressed by enhancing the concept with features than can be handled by a blockchain. +Although this concept contains many of the elements that are often desired of an escrow contract, its weaknesses could be addressed by enhancing the concept with features than can be handled by a blockchain. #### Technical Approach TBD From 27db35ae2f6211db937b83c97d9815ffd1193c28 Mon Sep 17 00:00:00 2001 From: Taconator Date: Fri, 20 Apr 2018 00:13:43 -0400 Subject: [PATCH 06/11] Renaming Concept B to Concept C Introduction of new Concept B that improves on Concept A yet is weaker than Concept C --- bsip-0040.md | 38 +++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-) diff --git a/bsip-0040.md b/bsip-0040.md index a45a69d..081cce0 100644 --- a/bsip-0040.md +++ b/bsip-0040.md @@ -175,6 +175,42 @@ TBD ### Concept B +This concept is the same as Concept A except that the escrow can only participate after being invited by either escrow party. Differences are shown with **an emphasis**. + +|Element|Description| +|-|-| +|Parties|Depositor and intended recipient each have an account on the blockchain| +|Escrow Assets|A quantity of an asset that exists on the blockchain| +|Escrow Period Start and End|Defined in contract| +|Conditions|Conditions describe events that might occur on the blockchain (e.g. does the price of some asset rise above a particular price; etc.) or occur off-chain (e.g. did the escrow intended recipient send 50 fiat USD to the escrow depositor via a bank wire; etc.). These conditions are textually described and are intended to be interpreted by off-chain parties and agent.| +|Condition Evaluators|The condition evaluators are the off-chain depositor and intended recipient **unless and until either party "invites" the escrow agent to become the sole evaluator by signaling this invitation on the blockchain**| +|Reporting on Condition Evaluation Outcome|Whichever off-chain entities are responsible for performing the evaluation must signal **a positive** outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| +|Escrow agent and fee|An escrow agent has an account on the blockchain. The fee is defined and paid to the escrow agent [by whom is TBD] as a prerequisite to initiate the escrow contract.| +|When and how frequently are escrow conditions evaluated|When and how **can optionally be** textually described as a part of the escrow contract on the blockchain. A positive evaluation must be signaled on the blockchain during the escrow period.| +|Who or what evaluates those conditions|The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved. At that point, the escrow agent should, if he is responsible evaluate the conditions **at least once during the escrow period**; whether the escrow agent performs this evaluation once or multiple times, or early or late during the escrow period is something that **might be** textually defined but which is not enforced by the blockchain. See [Reporting Conditions Evaluation](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct.| +|What Occurs when Conditions are Satisfied|When conditions are signaled to be satisfied by the designated condition evaluators, the assets are automatically transferred to the intended recipient| +|Conclusion of Escrow without Satisfied Conditions|Escrowed assets are automatically returned to the depositors without any action by the escrow agent. See [Avoiding Appearance of Negligence](#escrow-negligence).| + +#### Evaluation of Concept + +This concept improves on Concept A in the following ways: + +- clearly delineates that an escrow agent should only become involved as the sole condition evaluator after being invited by either of the escrow parties +- the escrow agent can record the outcome of a single condition evaluation on the blockchain and thereby avoid the obvious appearance of negligence + +This concept has the following weaknesses: + +- The escrow agent can only record a single outcome of a single condition evaluation on the blockchain. (A postive outcome only requires one signaling on the blockchain. In contrast, multiple negative outcomes cannot be recorded.) +- Neither the condition evaluation itself (e.g. the escrow agent looked at a bank statement on January 1 and found no record of a transfer, etc.) nor a proof of a condition evaluation is being recorded on the blockchain. +- It does not guarantee a sufficient amount of time for the escrow agent to perform the condition evaluation (e.g. the off-chain party might notify the escrow agent to be perform conditions evaluations only a few seconds before the expiry which is likely to be insufficient notice to properly evaluate the conditions) +- An escrow agent receives the fee regardless of performing any evaluation and of recording any evidence of the evaluation on the blockchain. See [Reporting Conditions Evaluation](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct. + +#### Technical Approach +TBD (something similar to Steem escrow is a good candidate for technical implementation) + + +### Concept C + This concept is the same as Concept A except for where **the emphasis** is added. |Element|Description| @@ -193,7 +229,7 @@ This concept is the same as Concept A except for where **the emphasis** is added #### Evaluation of Concept -This concept improves on Concept A yet has the following weaknesses: +This concept improves on Concept B yet has the following weaknesses: - The quality of a condition evaluations report by an escrow agent might be variable yet would be sufficient to ensure itself of receiving the escrow fee from the blockchain - If an escrow agent is invited, only a single report is required of the escrow agent by the blockchain for the agent receive the escrow fee. From 814568b3f6e15d8ffecbd13e49598bd7e044b5b6 Mon Sep 17 00:00:00 2001 From: Taconator Date: Fri, 29 Jun 2018 17:54:20 -0400 Subject: [PATCH 07/11] Escrow: InterLedger Protocol Escrow: Steem Escrow Escrow: Peerplays Escrow Escrow: Concept D for compatibility with InterLedger Protocol --- bsip-0040.md | 145 +++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 113 insertions(+), 32 deletions(-) diff --git a/bsip-0040.md b/bsip-0040.md index 081cce0..e859ad6 100644 --- a/bsip-0040.md +++ b/bsip-0040.md @@ -11,7 +11,7 @@ # Motivation The ability to escrow assets on BitShares is a desirable feature that could be used by many persons, services, and businesses. It permits conditional transfers between parties to occur that minimize or eliminate risks to a depositor/sender while conditions are being evaluated. Conditions for completion of a transfer can be evaluated by an escrow agent of some form whether a human and/or a software agent such as the blockchain agent. If all the conditions are evaluated to be true (a positive evaluation) during the evaluation period, then assets are transferred to an intended recipient(s). If the conditions are never evaluated to be positive (either due to an active evaluation or due to no evaluation whatsoever), then the assets are returned to the depositor(s). -# Rational +# Rationale ## Elements of a General Escrow Contract An escrow contract is defined to have the following elements: @@ -71,7 +71,7 @@ TBD: When intended recipient or escrow agent decide to terminate an escrow contr ### Conclusion of Escrow without Satisfied Conditions -If an escrow contract concludes without all the conditions being satisfied, a typical escrow contract has the escrowed asset(s) being returned to the depositor. This might be automatic process, or might require an action by the escrow agent. +If an escrow contract concludes without all the conditions being satisfied, a typical escrow contract has the escrowed asset(s) being returned to the depositor. This might be an automatic process, or might require an action by the escrow agent. ## Elements of a Blockchain Escrow Contract @@ -97,46 +97,95 @@ Either evaluation involves a contract, similar in nature to the existing DEX mar ### Automatic Transfers Upon Expiry -Upon expiry of the evaluation period, the assets that are held by the blockchain will automatically be returned to their depositors. +Upon expiry of the evaluation period without all conditions being satisfied, the assets that are held by the blockchain will automatically be returned to their depositors. ### Agent and Fee on a Blockchain -With the use of a blockchain, it is possible for the blockchain to hold the escrowed asset(s) while the escrow agent merely performs the condition evaluation. (A variant of this notion is that an escrow could act as an oracle to submit raw data to the blockchain that permits the blockchain to perform the condition evaluation.) If no action is taken by the escrow, the all escrowed assets will be returned to their depositors. (See [Automatic Transfers Upon Expiry](#automatic-transfer-upon-expiry)) +With the use of a blockchain, it is possible for the blockchain to hold the escrowed asset(s) while the escrow agent merely performs the condition evaluation. (A variant of this notion is that an escrow could act as an oracle to submit raw data to the blockchain that permits the blockchain to perform the condition evaluation.) If no action is taken by the escrow, then all escrowed assets will be returned to their depositors. (See [Automatic Transfers Upon Expiry](#automatic-transfer-upon-expiry)) -When signaling that conditions were evaluated with either a positive or a negative outcome, it would likely be beneficial for the escrow parties and the escrow agent to optionally memorialize either evidence of the condition evaluation, or some sort of "link" or "hash" of the condition evaluation (cite Factom as an example). The ability to explicitly indicate a negative outcome by an escrow agent is beneficial to an escrow agent to reduce the likelihood of allegations of negligence by either of the escrow parties. +When signaling that conditions were evaluated with either a positive or a negative outcome, it would likely be beneficial for the escrow parties and the escrow agent to optionally memorialize either evidence of the condition evaluation, or some sort of "link" or "hash" of the condition evaluation (e.g. see [Factom's "proof of existence"](https://www.factom.com/about/faqs)). The ability to explicitly indicate a negative outcome by an escrow agent is beneficial to an escrow agent to reduce the likelihood of allegations of negligence by either of the escrow parties. -## Existing Escrow Proposals -The section describes various escrow concepts that have been proposed either for BitShares or for other blockchains or services in terms of the elements that have been defined above. This is intended to provide some background and comparison to the concepts that will be described below in [Possible Concepts](#possible-concepts). -**To-do**: LocalBitcoin type of escrow of fiat for BTC +## Existing Graphene Features that are Similar to What is Needed for Blockchain Escrowing -**To-do**: Elaborate Steem Escrow +The section describes concepts related to escrow that either exist or have been proposed for BitShares or for other blockchains or services in terms of the elements that have been defined above. This is intended to provide some background and comparison to the concepts that will be described below in [Possible Concepts](#possible-concepts). -**To-do**: Elaborate Interledger +### Steem Escrow +Explicit escrow exists on [Steem](https://steem.io). when [a depositor initiates an escrow](https://github.com/steemit/steem/blob/807fb40ec137a987dc53cee6d8455c7b6c47aeed/libraries/chain/steem_evaluator.cpp#L810-L848). The asset is released: -## Existing Graphene Features that are Similar to What is Needed for Blockchain Escrowing +- to the intended recipient if [both recipient and the escrow agent approve the transfer](https://github.com/steemit/steem/blob/807fb40ec137a987dc53cee6d8455c7b6c47aeed/libraries/chain/steem_evaluator.cpp#L896-L904), +- to the depositor if [either the recipient or the escrow agent rejects the transfer](https://github.com/steemit/steem/blob/807fb40ec137a987dc53cee6d8455c7b6c47aeed/libraries/chain/steem_evaluator.cpp#L888-L895), +- to the intended recipient if [the depositor authorizes the release and the escrow is _not under dispute_](https://github.com/steemit/steem/blob/807fb40ec137a987dc53cee6d8455c7b6c47aeed/libraries/chain/steem_evaluator.cpp#L955-L963), +- to the depositor if [the depositor authorizes the release and the escrow is _not under dispute_](https://github.com/steemit/steem/blob/807fb40ec137a987dc53cee6d8455c7b6c47aeed/libraries/chain/steem_evaluator.cpp#L953-L964), +- to either the depositor or the intended recipient [by the escrow agent if the escrow is under dispute](https://github.com/steemit/steem/blob/807fb40ec137a987dc53cee6d8455c7b6c47aeed/libraries/chain/steem_evaluator.cpp#L944-L948) + +Two behaviors in the Steem implementation are noteworthy: +- there is no automatic return to the depositor if no actions have been taken; a positive action by either the escrow agent or the intended recipient are required for the return +- **partial** release of funds are possible when using the "release" mechanism. + + +### Peerplays Escrow +Implicit escrow exists on [Peerplays](https://peerplays.com) when [a user joins an on-chain tournament](https://github.com/PBSA/peerplays/blob/fc18c4812cea7993fa204619be8f246c96485cec/libraries/chain/tournament_object.cpp#L382-L397). The asset is released: + +- to the depositor if [the tournament is canceled](https://github.com/PBSA/peerplays/blob/fc18c4812cea7993fa204619be8f246c96485cec/libraries/chain/tournament_object.cpp#L262-L290), +- to the depositor if [the user exits an on-chain tournament before its start](https://github.com/PBSA/peerplays/blob/fc18c4812cea7993fa204619be8f246c96485cec/libraries/chain/tournament_object.cpp#L399-L417), and +- to the winner of the tournament at its [conclusion](https://github.com/PBSA/peerplays/blob/fc18c4812cea7993fa204619be8f246c96485cec/libraries/chain/tournament_object.cpp#L292-L356). + + +### Atomic Cross Chain Transfers +[Atomic Cross Chain Transfers](https://en.bitcoin.it/wiki/Atomic_cross-chain_trading) (ACCT) involves the transfer of one asset (Asset A) on one chain (Chain A) from one account (A1) to another account (A2) if another asset (Asset B) on another chain (Chain B) is transferred from one account (B2) to another account (B1). Either both transfer occur or neither do. This functionality [has been prototyped between two Graphene chains by the Scorum team](https://github.com/scorum/scorum/pull/41). + +This feature implicitly involves escrowing of Asset A on Chain A while waiting for authorization to complete the transfer to A2. The sub-feature of ACCT could either be duplicated for the escrowing envisioned in this BSIP, or generalized for use by both ACCT and this BSIP. -[**To-do**: Consider moving this section elsewhere] ### BitShares Multi-Signature Account -One of the existing features of BitShares is the ability to have an account that requires multiples signatures by differently authorized parties [cite] and even hierarchical authorizations. This mechanism has the benefit of escrowing an asset within an account whose transactions can be authorized by different combinations of parties (e.g. either both the depositor and the intended recipient; only the escrow agent; the escrow agent and the depositor; the escrow agent and the intended recipient) and can transfer an asset towards any account. +One of the existing features of BitShares is the ability to have an account that requires multiples signatures by differently authorized parties (see [BitShares General Whitepaper](http://docs.bitshares.org/_downloads/bitshares-general.pdf) _Section 4.1.4: Flexible Identity Management_) and even hierarchical authorizations. This mechanism has the benefit of escrowing an asset within an account whose transactions can be authorized by different combinations of parties (e.g. either both the depositor and the intended recipient; only the escrow agent; the escrow agent and the depositor; the escrow agent and the intended recipient) and can transfer an asset towards any account. This feature can actually satisfy the requirements for "off-chain evaluation" escrowing although it has the burden of requiring a unique account with the appropriate escrow agent and escrow participants for a specific ongoing escrow contract. One option to handle a specific contract would be to create a single-use account for this purpose. Another more technical option would be for the authorities on an account to be re-assigned to the escrow agent upon the completion or expiry of the contract, so that the escrow agent could re-use the account in a future contract by subsequently re-assigning among the agent, and future contract participants. This approach, however, is somewhat complicated, error-prone, and awkward. -### BitShares Proposals +### BitShares Proposed Transactions -One of the existing features of BitShares is the ability to have a proposal that is recorded on the blockchain and awaits the authorization of the requisite parties (e.g. M-of-N signatures). If the required authorizations are not given by the proposal expiry then no transfer will occur. +One of the existing features of BitShares is the ability to have a proposed transaction that is recorded on the blockchain and awaits the authorization of the requisite parties (e.g. M-of-N signatures)(see [BitShares General Whitepaper](http://docs.bitshares.org/_downloads/bitshares-general.pdf) _Section 5.7: Proposed Transactions_). If the required authorizations are not given by the proposal expiry then no transfer will occur. This feature alone falls short of what is needed because no asset is actually escrowed while the proposal is awaiting the necessary signatures to complete. Therefore there is no guarantee that the asset will be secured by the time that the final required signature is obtained. -### Steem Escrow -**To-do**: Elaborate +## Related Concepts -### Atomic Cross Chain Transfers -Atomic Cross Chain Transfers (ACCT) involves the transfer of one asset (Asset A) on one chain (Chain A) from one account (A1) to another account (A2) if another asset (Asset B) on another chain (Chain B) is transferred from one account (B2) to another account (B1). Either both transfer occur or neither do. This functionality has been prototyped between two Graphene chains by the Scorum team [cite]. +The section describes concepts related to escrow that either exist or have been proposed for BitShares or for other blockchains or services in terms of the elements that have been defined above. This is intended to provide some background and comparison to the concepts that will be described below in [Possible Concepts](#possible-concepts). + + +### Interledger Transfer + +The [Interledger Protocol (ILP)](https://interledger.org) is a protocol for transmitting **debt claims (e.g. IOUs)** from one party (Alice) who controls an account on one Ledger (Ledger A) to another party (Bob) who controls an account on another Ledger (Ledger B) through at least one trusted intermediate party (Connector). A Connector must effectively control an account on at least two ledgers in order to "fulfill" the claim transfer across ledgers. Parties to the protocol are effectively only transferring debt claims between their immediate "peers" but the chain of peers enables the transfer across many participants. + +The transmission of the debt claim from Alice to Bob is called a "payment". The transmission is conveyed through a "communication channel" which may be done in any form either person-to-person, by voice, by email, by blockchain, etc. The various means of transmission have different characteristics in terms of speed and guarantee of arrival therefore a part of the protocol is focused on robustly handling these communication delays and uncertainties by embedding expiration times into the protocol. Packets that are not relayed in time result in no formal claim transfer between parties. When a recipient receives the transmission, the recipient may choose to accept or reject the debt claim transfer. + +Debt claim transfers may optionally be post-funded or pre-funded. With post-funded "transfers", debt claims can be settled on the ledger that is shared by any connected-peer thus canceling the debt **after the conclusion of the "transfer"**. With pre-funded transfers, **assets of some form are securely set aside as a pre-condition for the transfer. The escrowed asset is then assigned to the appropriate connected-peer when the "transfer" is concluded either successfully or unsuccessfully.** + +There are similarities between a conditional transfer that is escrowed on the blockchain versus an ILP transfer through the blockchain + +- Both use cases involve two accounts on the blockchain. +- Both use cases involve an asset temporarily being held by the blockchain until either certain conditions are satisfied or the expiry arrives, whichever is earlier. + +Nevertheless there is a crucial difference between the two use cases. In the case of a conditional transfer, the condition for release to the recipient must be satisfactory to both the depositor and the recipient. **In the case of an ILP transfer, the condition for release to the recipient is determined by only one party, the recipient,** because the sender tacitly accepts the transfer when initiating the ILP transfer. + +[Concept C of the InterLedger BSIP](https://github.com/bitshares/bsips/blob/bsip41/bisip-0041.md) elaborates on an implementation of InterLedger on BitShares that makes use of a proposed escrow feature on BitShares. This description applies an additional mechanism on top of [this BSIP's Concept D](#concept-full-release-by-blockchain)). + + +### LocalBitcoin +**To-do**: Elaboarate LocalBitcoin type of escrow of fiat for BTC + + +## Comparison of the Related Concepts and Technologies + +|Concept / Technology|# of Ledgers|Does Recipient Receive Same Type of Asset that was Sent by Depostior?|Is Recipient Guaranteed to Receive Asset Upon "successful completion"?|Can Depositor halt the transfer after the deposit into escrow?|Automatic return of deposit at expiry if conditions are not satisfied?| +|-|-|-|-|-|-| +|Steem Escrow|1|Yes (same ledger)|Yes|Yes (by inviting escrow agent to participate)|No| +|Peerplays Escrow|1|Yes (same ledger)|Yes|No (smart contract is the sole adjudicator)|Yes (if tournament quorum is not reached); N/A after tournament begins| +|ACCT|2+|No (asset is converted across ledgers)|Yes|Yes (by not accepting the reciprocal transfer on the second ledger)|Yes| +|InterLedger|2+|No (asset is converted across ledgers)|Depends on the Connector that is peered with the Recipient; only the transfer of a debt claim is guaranteed|No (only actions or inactions by the Connectors and recipient can halt the transfer)|Yes| -This feature implicitly involves escrowing of Asset A on Chain A while waiting for authorization to complete the transfer to A2. The sub-feature of ACCT could either be duplicated for the escrowing envisioned in this BSIP, or generalized for use by both ACCT and this BSIP. # Specifications @@ -151,11 +200,10 @@ The following will describe possible escrow concepts that could be implemented i |Escrow Assets|A quantity of an asset that exists on the blockchain| |Escrow Period Start and End|Defined in contract| |Conditions|Conditions describe events that might occur on the blockchain (e.g. does the price of some asset rise above a particular price; etc.) or occur off-chain (e.g. did the escrow intended recipient send 50 fiat USD to the escrow depositor via a bank wire; etc.). These conditions are textually described and are intended to be interpreted by off-chain parties and agent.| -|Condition Evaluators|The condition evaluators are the off-chain depositor and intended recipient, or the escrow agent| -|Reporting on Condition Evaluation Outcome|Whichever off-chain entities are responsible for performing the evaluation must signal the outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| +|Condition Evaluators|The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved. At that point, the escrow agent should, if he is responsible, evaluate the conditions **at least once during the escrow period**; whether the escrow agent performs this evaluation once or multiple times, or early or late during the escrow period is something that **might be** textually defined but which is not enforced by the blockchain. See [Reporting on Evaluation of Conditions](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct.| +|Reporting on Evaluation of Conditions|Whichever off-chain entities are responsible for performing the evaluation must signal the outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| |Escrow agent and fee|An escrow agent has an account on the blockchain. The fee is defined and paid to the escrow agent [by whom is TBD] as a prerequisite to initiate the escrow contract.| |When and how frequently are escrow conditions evaluated|When and how **can optionally be** textually described as a part of the escrow contract on the blockchain. A positive evaluation must be signaled on the blockchain during the escrow period.| -|Who or what evaluates those conditions|The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved. At that point, the escrow agent should, if he is responsible, evaluate the conditions **at least once during the escrow period**; whether the escrow agent performs this evaluation once or multiple times, or early or late during the escrow period is something that **might be** textually defined but which is not enforced by the blockchain. See [Reporting Conditions Evaluation](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct.| |What Occurs when Conditions are Satisfied|When conditions are signaled to be satisfied by the designated condition evaluators, the assets are automatically transferred to the intended recipient| |Conclusion of Escrow without Satisfied Conditions|Escrowed assets are automatically returned to the depositors without any action by the escrow agent. See [Avoiding Appearance of Negligence](#escrow-negligence).| @@ -183,11 +231,10 @@ This concept is the same as Concept A except that the escrow can only participat |Escrow Assets|A quantity of an asset that exists on the blockchain| |Escrow Period Start and End|Defined in contract| |Conditions|Conditions describe events that might occur on the blockchain (e.g. does the price of some asset rise above a particular price; etc.) or occur off-chain (e.g. did the escrow intended recipient send 50 fiat USD to the escrow depositor via a bank wire; etc.). These conditions are textually described and are intended to be interpreted by off-chain parties and agent.| -|Condition Evaluators|The condition evaluators are the off-chain depositor and intended recipient **unless and until either party "invites" the escrow agent to become the sole evaluator by signaling this invitation on the blockchain**| -|Reporting on Condition Evaluation Outcome|Whichever off-chain entities are responsible for performing the evaluation must signal **a positive** outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| +|Condition Evaluators|The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved. At that point, the escrow agent should, if he is responsible evaluate the conditions **at least once during the escrow period**; whether the escrow agent performs this evaluation once or multiple times, or early or late during the escrow period is something that **might be** textually defined but which is not enforced by the blockchain. See [Reporting on Evaluation of Conditions](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct.| +|Reporting on Evaluation of Conditions|Whichever off-chain entities are responsible for performing the evaluation must signal **a positive** outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| |Escrow agent and fee|An escrow agent has an account on the blockchain. The fee is defined and paid to the escrow agent [by whom is TBD] as a prerequisite to initiate the escrow contract.| |When and how frequently are escrow conditions evaluated|When and how **can optionally be** textually described as a part of the escrow contract on the blockchain. A positive evaluation must be signaled on the blockchain during the escrow period.| -|Who or what evaluates those conditions|The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved. At that point, the escrow agent should, if he is responsible evaluate the conditions **at least once during the escrow period**; whether the escrow agent performs this evaluation once or multiple times, or early or late during the escrow period is something that **might be** textually defined but which is not enforced by the blockchain. See [Reporting Conditions Evaluation](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct.| |What Occurs when Conditions are Satisfied|When conditions are signaled to be satisfied by the designated condition evaluators, the assets are automatically transferred to the intended recipient| |Conclusion of Escrow without Satisfied Conditions|Escrowed assets are automatically returned to the depositors without any action by the escrow agent. See [Avoiding Appearance of Negligence](#escrow-negligence).| @@ -203,7 +250,7 @@ This concept has the following weaknesses: - The escrow agent can only record a single outcome of a single condition evaluation on the blockchain. (A postive outcome only requires one signaling on the blockchain. In contrast, multiple negative outcomes cannot be recorded.) - Neither the condition evaluation itself (e.g. the escrow agent looked at a bank statement on January 1 and found no record of a transfer, etc.) nor a proof of a condition evaluation is being recorded on the blockchain. - It does not guarantee a sufficient amount of time for the escrow agent to perform the condition evaluation (e.g. the off-chain party might notify the escrow agent to be perform conditions evaluations only a few seconds before the expiry which is likely to be insufficient notice to properly evaluate the conditions) -- An escrow agent receives the fee regardless of performing any evaluation and of recording any evidence of the evaluation on the blockchain. See [Reporting Conditions Evaluation](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct. +- An escrow agent receives the fee regardless of performing any evaluation and of recording any evidence of the evaluation on the blockchain. See [Reporting on Evaluation of Conditions](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct. #### Technical Approach TBD (something similar to Steem escrow is a good candidate for technical implementation) @@ -219,11 +266,10 @@ This concept is the same as Concept A except for where **the emphasis** is added |Escrow Assets|A quantity of an asset that exists on the blockchain| |Escrow Period Start and End|Defined in contract; **an additional deadline (invitation deadline) must be specified within the escrow period that defines by when an escrow agent may be invited by either escrow party to begin conditions evaluation**| |Conditions|Conditions describe events that might occur on the blockchain (e.g. does the price of some asset rise above a particular price; etc.) or occur off-chain (e.g. did the escrow intended recipient send 50 fiat USD to the escrow depositor via a bank wire; etc.). These conditions are textually described and are intended to be interpreted by off-chain parties and agent.| -|Condition Evaluators|The condition evaluators are the off-chain depositor and intended recipient **unless and until either party "invites" the escrow agent to become the sole evaluator by signaling this invitation on the blockchain**| -|Reporting on Condition Evaluation Outcome|Whichever off-chain entities are responsible for performing the evaluation must signal the outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| +|Condition Evaluators|The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved **by the invitation deadline**. At that point, the escrow agent should ~~, if he is responsible,~~ evaluate the conditions **at least once during the escrow period** **if the agent expects to receive the escrow fee**.~~; whether the escrow agent performs this evaluation once or multiple times, or early or late during the escrow period is something that **might be** textually defined but which is not enforced by the blockchain. See [Reporting on Evaluation of Conditions](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct.~~ **Reporting on conditions evaluation may or may not include a textual description of the evaluation or a proof of a textual description (which can be used to both maintain some privacy for the escrow parties and to minimize on fees associated with the length of a textual report). A report on conditions evaluation must also include the conditions evaluation outcome so that the blockchain can resolve the escrow contract.**| +|Reporting on Evaluation of Conditions|Whichever off-chain entities are responsible for performing the evaluation must signal the outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| |Escrow agent and fee|An escrow agent has an account on the blockchain. The fee is defined and **escrowed for the escrow agent by the blockchain** [by whom is TBD] as a prerequisite to initiate the escrow contract. **The fee is transferred to the agent upon escrow expiry if (a) the escrow agent has _not_ been requested to participate by the invitation deadline, or (b) the escrow agent _has_ been requested to participate by the escrow agent deadline and the agent has submitted at least one report of conditions evaluation**| |When and how frequently are escrow conditions evaluated|When and how can optionally be textually described as a part of the escrow contract on the blockchain. A positive evaluation must be signaled on the blockchain during the escrow period. **If an escrow agent is invited by the invitation deadline, then the agent will be expected to report on conditions evaluation at least once between the deadline and the expiry.**| -|Who or what evaluates those conditions|The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved **by the invitation deadline**. At that point, the escrow agent should ~~, if he is responsible,~~ evaluate the conditions **at least once during the escrow period** **if the agent expects to receive the escrow fee**.~~; whether the escrow agent performs this evaluation once or multiple times, or early or late during the escrow period is something that **might be** textually defined but which is not enforced by the blockchain. See [Reporting Conditions Evaluation](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct.~~ **Reporting on conditions evaluation may or may not include a textual description of the evaluation or a proof of a textual description (which can be used to both maintain some privacy for the escrow parties and to minimize on fees associated with the length of a textual report). A report on conditions evaluation must also include the conditions evaluation outcome so that the blockchain can resolve the escrow contract.**| |What Occurs when Conditions are Satisfied|When conditions are signaled to be satisfied by the designated condition evaluators, the assets are automatically transferred to the intended recipient| |Conclusion of Escrow without Satisfied Conditions|Escrowed assets are automatically returned to the depositors without any action by the escrow agent. **If an escrow agent is invited to participate, an escrow agent should report at least one condition evaluation on the blockchain to avoid [avoid appearance of negligence](#escrow-negligence)**.| @@ -237,10 +283,45 @@ This concept improves on Concept B yet has the following weaknesses: #### Technical Approach TBD +### Concept D +This concept is the same as Concept C except for where **the emphasis** is added. + +|Element|Description| +|-|-| +|Parties|Depositor and intended recipient each have an account on the blockchain| +|Escrow Assets|A quantity of an asset(s) that exists on the blockchain| +|Escrow Period Start and End|**Period start is when the escrow process is submitted to the blockchain. End period is defined in the "prepare packet".**| +|Conditions|**Acceptance is signaled by both the depositor and the intended recipient**| +|Condition Evaluators|**Smart contract/operation on the blockchain**| +|Reporting on Evaluation of Conditions|**Smart-contract will report on the results of any evaluation of the conditions**| +|Escrow agent and fee|**The blockchain acts as the escrow agent. The fee is paid when the prepare packet is presented and paid by the submitter of the prepare packet.**| +|When and how frequently are escrow conditions evaluated|**Evaluated when (a) an acceptance is signaled by either party, (b) a rejection is signaled by either party, or (c) the escrow expires**| +|What Occurs when Conditions are Satisfied|**If the depositor and intended recipient signal acceptance, then the escrowed assets are released to the recipient. If a rejection is signaled, the escrowed assets are released to the depositor.**| +|Conclusion of Escrow without Satisfied Conditions|**All of the escrowed assets are released to the "sending" connected peer.**| + +#### Evaluation of Concept + +This concept simplifies Concept C by making a smart contract on the blockchain the sole evaluator of a condition that may or may not be presented on the blockchain before the expiration. + +The approach is simple in that the entire collateral is either transferred to the recipient or returned to the depositor. + +The weaknesses of this Concept in contrast to Concept C is that are there is no third-party ajudicator to resolve a disagreement. + +#### Technical Approach +TBD + +### Concept E +TBD: Blockchain evaluation of a hash with partial release of collateral + +#### Evaluation of Concept +TBD + +#### Technical Approach +TBD # Discussion ## Responsible Escrow Behavior -### Reporting Conditions Evaluation +### Reporting the Evaluation of Conditions An escrow agent could publish either a report or a proof of a report on the blockchain to demonstrate the evaluation of conditions. @@ -258,7 +339,7 @@ A similar argument could be made for evaluating the parties themselves. ## Dead-Man Switch Escrow contracts involve transfers from one party to another that are contingent on certain events being observed. A variation on this idea is for a transfer to occur if certain events are not observed. An example of this is a "dead-man switch" wherein a transfer will occur **unless** a party signals activity before the expiry. Such an example bears all the same characteristics as an escrow contract **except** for how to handle the absence of a condition evaluation. For a blockchain escrow contract, the assets are returned to their depositors if no positive indication is given (see [Automatic Transfers Upon Expiry](#automatic-transfer-upon-expiry)). For a dead-man contract, the assets are delivered to the intended recipients if no positive indication is given by the expiry. Some of the work towards blockchain escrow might be reusable or generalizable for dead-man switch use cases (e.g. life insurance, posthumous asset transfers, etc). -# Summary for Shareholders +# Summary for Stakeholders TBD From d380ca480839df847e48f2f582a039afa738985c Mon Sep 17 00:00:00 2001 From: Taconator Date: Mon, 8 Oct 2018 18:53:32 -0400 Subject: [PATCH 08/11] Renamed escrow BSIP file --- bsip-0040.md => bsip-0046.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename bsip-0040.md => bsip-0046.md (100%) diff --git a/bsip-0040.md b/bsip-0046.md similarity index 100% rename from bsip-0040.md rename to bsip-0046.md From d4281f66c9172981703866602aaaa6ade9158e54 Mon Sep 17 00:00:00 2001 From: Taconator Date: Tue, 9 Oct 2018 08:32:09 -0400 Subject: [PATCH 09/11] Improved consistency and usage of escrow elements Comparison with HTLC Summary section References to related discussions, documents, and code --- README.md | 1 + bsip-0046.md | 186 ++++++++++++++++++++++++++++----------------------- 2 files changed, 102 insertions(+), 85 deletions(-) diff --git a/README.md b/README.md index 2d23357..966cb20 100644 --- a/README.md +++ b/README.md @@ -49,3 +49,4 @@ Number | Title | [39](bsip-0039.md) | Automatically approve proposals by the proposer | Fabian Schuh | Protocol | Draft [40](bsip-0040.md) | Custom active permission | Stefan Schießl | Protocol | Draft [42](bsip-0042.md) | Adjust price feed to influence trading price of SmartCoins | Abit More | Protocol | Draft +[46](bsip-0046.md) | Escrow Concepts | taconator | Informational | Draft diff --git a/bsip-0046.md b/bsip-0046.md index e859ad6..a5281cb 100644 --- a/bsip-0046.md +++ b/bsip-0046.md @@ -1,15 +1,19 @@ - BSIP: 0040 - Title: Escrow Feature + BSIP: 0046 + Title: Escrow Concepts Authors: taconator Status: Draft Type: Informational Created: 2018-04-16 - Discussion: + Discussion: BSIP (https://github.com/bitshares/bsips/pull/76) + conditional payment feature? (https://bitsharestalk.org/index.php/topic,23800.0.html) + 条件支付”是目前最急迫需要的功能 (https://bitsharestalk.org/index.php/topic,24155.0.html) # Abstract +This informational BSIP describes elements of a general escrow contract, existing Graphene features that are similar to escrow contracts, concepts that are related to blockchain escrows, and possible escrow concepts to implement on BitShares. + # Motivation -The ability to escrow assets on BitShares is a desirable feature that could be used by many persons, services, and businesses. It permits conditional transfers between parties to occur that minimize or eliminate risks to a depositor/sender while conditions are being evaluated. Conditions for completion of a transfer can be evaluated by an escrow agent of some form whether a human and/or a software agent such as the blockchain agent. If all the conditions are evaluated to be true (a positive evaluation) during the evaluation period, then assets are transferred to an intended recipient(s). If the conditions are never evaluated to be positive (either due to an active evaluation or due to no evaluation whatsoever), then the assets are returned to the depositor(s). +The ability to escrow assets on BitShares is a desirable feature that could be used by many persons, services, and businesses. It permits conditional transfers between parties to occur that minimize or eliminate risks to a depositor and sender while conditions are being evaluated. Conditions for completion of a transfer can be evaluated by an escrow agent of some form such as a human and/or a software agent. If all the conditions are evaluated to be true (a positive evaluation) during the evaluation period, then assets are transferred to an intended recipient(s). If the conditions are never evaluated to be true (either due to a negative evaluation or due to the absence of an evaluation), then the assets are returned to the depositor(s). # Rationale ## Elements of a General Escrow Contract @@ -21,20 +25,26 @@ An escrow contract is defined to have the following elements: * escrow period start and end (expiry) * conditions for escrow completion * condition evaluators -* escrow agent and fee -* when and how frequently are escrow conditions evaluated +* timing of conditions evaluation +* reporting of conditions evaluation * what occurs when all conditions are satisfied -* what occurs at conclusion of escrow period if all the conditions have not been satisfied +* what occurs when all conditions are not satisfied +* early termination of an escrow contract +* escrow agent and fee ### Parties -At least two parties must be defined for an escrow contract: at least one depositor, and at least one intended recipient. (Escrow agents are not defined here to be a "party" of the escrow contract [**To-do**: perhaps use better terminology]. +At least two parties must be defined for an escrow contract: at least one depositor, and at least one intended recipient. Escrow agents might also be considered to be part of the escrow contract depending on the defintions. ### Escrow Assets An escrow involves a conditional transfer of ownership of at least one item from one party (a depositor) to another (an intended recipient). An escrow is used to temporarily hold **some or all** of these items while the conditions are being evaluated during the escrow period. Upon satisfaction of the escrow conditions, the escrowed items will be transferred to the intended recipient. If the conditions are not satisfied by the expiry then the escrowed items are to be returned to the depositor. If certain conditions are met, the escrowed items can be returned early to the depositor before the expiry with the approval of designated parties (e.g. either all participants of an escrow and/or by the escrow agent). For definition purposes, let an item that will be transferred from Party A to Party B upon completion of the escrow conditions to be called Item AB. Let an item that will be transferred from Party B to Party A upon completion of the escrow conditions to be called Item BA. +### Escrow Period +The start of the escrow period is when the deposit of the escrow asset occurs. When the end of the escrow period arrives, any remaining asset that is still in the escrow is either automatically returned to the despositor or may be released by an escrow agent. + + ### Conditions The conditions of an escrow contract involve events about other people, assets, and/or actions that are beyond the control of the escrow agent. One such example is the transfer of property between the parties of the contract by means which the escrow agent can at most observe. Whoever or whatever will evaluate the conditions of a contract must somehow obtain information about these events, perhaps with assistance by the escrow parties (e.g. by providing proof of this external activity), to evaluate the conditions. @@ -45,33 +55,37 @@ The evaluators of the conditions of an escrow condition can be designated in the For example, the first tier of evaluators could consist of the escrow parties themselves (e.g. Parties A and B). If the parties agree on the evaluation, then the escrow transfer can proceed according to the designated terms (e.g. transfer of Item AB from A to B if conditions are satisfied, or return of Item AB to A if the conditions are not satisfied before the expiry). If the conditions are not satisfied by the expiry, then the escrowed items will automatically be returned to their depositors. -### Timing of Condition Evaluation +### Timing of Conditions Evaluation The timing of a condition evaluation is quite flexible and can vary from a single occurrence at near the expiry, or periodically during the escrow period, and/or triggered by certain events or activities. +### Reporting of Conditions Evaluation -### Escrow Agent and Fee +Condition evaluators, such as an escrow agent, will at least signal the outcome of their evaluation of the conditions through an action such as "release". A condition evaluator might also provide a report or an off-chain link to a report that summarizes their evaluation of the conditions. This report can serve to justify their action for releasing or holding the assets in the escrow. -An escrow agent can be used to perform distinct services: +### What occurs when conditions are satisfied -- to evaluate the conditions of the escrow agreement; -- to hold the escrowed asset(s) during the escrow period; if holding the assets, to transfer the escrowed assets to the appropriate parties contingent on the condition evaluation +When all the conditions are evaluated to be satisfied, _all or some_ of the escrowed assets are released to the intended recipient. This transfer could be automated or require human action to initiate. -An escrow agent is often paid a fee for these services before the escrow period begins and regardless of condition evaluation. +### What occurs when conditions are not satisfied -If an escrow will be performing condition evaluations, it should be granted reasonable amount of time to perform the condition evaluation. Furthermore, to avoid allegations of negligence, an escrow agent can benefit from the ability to demonstrate that an evaluation of the conditions(s) with a negative outcome (a negative evaluation) was performed. +If an escrow contract concludes without all the conditions being satisfied, a typical escrow contract has the remaining escrowed asset(s) being returned to the depositor. This might be an automatic process, or might require an action by the escrow agent. -### What Occurs when Conditions are Satisfied +### Early Termination of an Escrow Contract -When all the conditions are evaluated to be satisfied, the escrowed assets are expected to be transferred to the intended recipient. This transfer could be automated or require human action to initiate. +When an intended recipient or escrow agent decides to terminate an escrow contract early such that the assets are returned to the depositor. -### Early Termination of an Escrow Contract -TBD: When intended recipient or escrow agent decide to terminate an escrow contract early such that the assets are returned to the depositor +### Escrow Agent and Fee + +An escrow agent can be used to perform distinct services: -### Conclusion of Escrow without Satisfied Conditions +- to evaluate the conditions of the escrow agreement; +- to hold the escrowed asset(s) during the escrow period; if holding the assets, to transfer the escrowed assets to the appropriate parties contingent on the condition evaluation -If an escrow contract concludes without all the conditions being satisfied, a typical escrow contract has the escrowed asset(s) being returned to the depositor. This might be an automatic process, or might require an action by the escrow agent. +An escrow agent is often paid a fee for these services before the escrow period begins and regardless of condition evaluation. + +If an escrow will be performing condition evaluations, it should be granted reasonable amount of time to perform the condition evaluation. Furthermore, to avoid allegations of negligence, an escrow agent can benefit from the ability to demonstrate that an evaluation of the conditions(s) with a negative outcome (a negative evaluation) was performed. ## Elements of a Blockchain Escrow Contract @@ -84,16 +98,16 @@ An escrow contract on a blockchain can have certain qualities that are distincti Off-chain escrow evaluations involves either a human(s) or an off-chain agent(s) making the evaluation regarding escrow conditions (e.g. escrow agent, Etienne, evaluates whether Bob satisfied the escrow conditions before releasing an asset from Alice to Bob). If all conditions are evaluated to be satisfied by the appropriate escrow parties or agent, then they can indicate their approval to the contract, and then the defined contract transfers will occur. If the appropriate approvals are not granted by the expiry, then the escrow deposits will be returned to the depositors. -#### On-Chain Escrow Evaluation With Oracles +#### On-Chain Escrow Evaluation With Oracles On-chain escrow evaluations with oracles involves an escrow contract that can be evaluated by the blockchain itself by reviewing data that is submitted by a trusted party who can observe events outside of the blockchain (oracle). An example of such data could be the temperature at a location on a particular date. Such a contract would require the following: - A contract state that consists in part on this temperature data (e.g. a decimal variable); -- a software contract that can interpret this data; +- a smart contract that can interpret this data; - a trusted oracle that can submit/update this information in the contract state. -A variation on this idea is where the contract state consists of a particular asset DEX price, market condition on the DEX, and/or an account balance on the DEX so that no new data would be required. Under this variation the trusted oracles are account holders who initiate DEX transactions and the blockchain that processes those transactions. +A variation on this idea is where the contract state consists of a particular asset DEX price, market condition on the DEX, and/or an account balance on the DEX so that no new data would be required. Under this variation the trusted oracles are account holders who initiate DEX transactions and the smart contract then observes those transactions. -Either evaluation involves a contract, similar in nature to the existing DEX market processing, being designed for a particular contract. +Either evaluation involves a contract, similar in nature to the existing DEX market processing, being designed for a particular purpose. ### Automatic Transfers Upon Expiry @@ -101,7 +115,7 @@ Upon expiry of the evaluation period without all conditions being satisfied, the ### Agent and Fee on a Blockchain -With the use of a blockchain, it is possible for the blockchain to hold the escrowed asset(s) while the escrow agent merely performs the condition evaluation. (A variant of this notion is that an escrow could act as an oracle to submit raw data to the blockchain that permits the blockchain to perform the condition evaluation.) If no action is taken by the escrow, then all escrowed assets will be returned to their depositors. (See [Automatic Transfers Upon Expiry](#automatic-transfer-upon-expiry)) +With the use of a blockchain, it is possible for the blockchain to be a custodian of the escrowed asset(s) while the escrow agent merely performs the condition evaluation. (A variant of this notion is that an escrow could act as an oracle to submit raw data to the blockchain that permits the smart contract to perform the condition evaluation.) If no action is taken by the escrow agent, then all escrowed assets will be returned to their depositors. (See [Automatic Transfers Upon Expiry](#automatic-transfer-upon-expiry)) When signaling that conditions were evaluated with either a positive or a negative outcome, it would likely be beneficial for the escrow parties and the escrow agent to optionally memorialize either evidence of the condition evaluation, or some sort of "link" or "hash" of the condition evaluation (e.g. see [Factom's "proof of existence"](https://www.factom.com/about/faqs)). The ability to explicitly indicate a negative outcome by an escrow agent is beneficial to an escrow agent to reduce the likelihood of allegations of negligence by either of the escrow parties. @@ -111,7 +125,7 @@ When signaling that conditions were evaluated with either a positive or a negati The section describes concepts related to escrow that either exist or have been proposed for BitShares or for other blockchains or services in terms of the elements that have been defined above. This is intended to provide some background and comparison to the concepts that will be described below in [Possible Concepts](#possible-concepts). ### Steem Escrow -Explicit escrow exists on [Steem](https://steem.io). when [a depositor initiates an escrow](https://github.com/steemit/steem/blob/807fb40ec137a987dc53cee6d8455c7b6c47aeed/libraries/chain/steem_evaluator.cpp#L810-L848). The asset is released: +Explicit escrow exists on [Steem](https://steem.io) when [a depositor initiates an escrow](https://github.com/steemit/steem/blob/807fb40ec137a987dc53cee6d8455c7b6c47aeed/libraries/chain/steem_evaluator.cpp#L810-L848). The asset is released: - to the intended recipient if [both recipient and the escrow agent approve the transfer](https://github.com/steemit/steem/blob/807fb40ec137a987dc53cee6d8455c7b6c47aeed/libraries/chain/steem_evaluator.cpp#L896-L904), - to the depositor if [either the recipient or the escrow agent rejects the transfer](https://github.com/steemit/steem/blob/807fb40ec137a987dc53cee6d8455c7b6c47aeed/libraries/chain/steem_evaluator.cpp#L888-L895), @@ -132,12 +146,6 @@ Implicit escrow exists on [Peerplays](https://peerplays.com) when [a user joins - to the winner of the tournament at its [conclusion](https://github.com/PBSA/peerplays/blob/fc18c4812cea7993fa204619be8f246c96485cec/libraries/chain/tournament_object.cpp#L292-L356). -### Atomic Cross Chain Transfers -[Atomic Cross Chain Transfers](https://en.bitcoin.it/wiki/Atomic_cross-chain_trading) (ACCT) involves the transfer of one asset (Asset A) on one chain (Chain A) from one account (A1) to another account (A2) if another asset (Asset B) on another chain (Chain B) is transferred from one account (B2) to another account (B1). Either both transfer occur or neither do. This functionality [has been prototyped between two Graphene chains by the Scorum team](https://github.com/scorum/scorum/pull/41). - -This feature implicitly involves escrowing of Asset A on Chain A while waiting for authorization to complete the transfer to A2. The sub-feature of ACCT could either be duplicated for the escrowing envisioned in this BSIP, or generalized for use by both ACCT and this BSIP. - - ### BitShares Multi-Signature Account One of the existing features of BitShares is the ability to have an account that requires multiples signatures by differently authorized parties (see [BitShares General Whitepaper](http://docs.bitshares.org/_downloads/bitshares-general.pdf) _Section 4.1.4: Flexible Identity Management_) and even hierarchical authorizations. This mechanism has the benefit of escrowing an asset within an account whose transactions can be authorized by different combinations of parties (e.g. either both the depositor and the intended recipient; only the escrow agent; the escrow agent and the depositor; the escrow agent and the intended recipient) and can transfer an asset towards any account. @@ -155,9 +163,20 @@ This feature alone falls short of what is needed because no asset is actually es The section describes concepts related to escrow that either exist or have been proposed for BitShares or for other blockchains or services in terms of the elements that have been defined above. This is intended to provide some background and comparison to the concepts that will be described below in [Possible Concepts](#possible-concepts). -### Interledger Transfer +### Atomic Cross Chain Transfers +[Atomic Cross Chain Transfers](https://en.bitcoin.it/wiki/Atomic_cross-chain_trading) (ACCT) involves the transfer of one asset (Asset A) on one chain (Chain A) from one account (A1) to another account (A2) if another asset (Asset B) on another chain (Chain B) is transferred from one account (B2) to another account (B1). Either both transfer occur or neither do. This functionality [has been prototyped between two Graphene chains by the Scorum team](https://github.com/scorum/scorum/pull/41). + +This feature implicitly involves escrowing of Asset A on Chain A while waiting for authorization to complete the transfer to A2. The sub-feature of ACCT could either be duplicated for the escrowing envisioned in this BSIP, or generalized for use by both ACCT and this BSIP. + + +### Hash Time-Locked Contracts (HTLC) + +Specifications for Hash Time-Locked Contract in BitShares (BSIP 44) are being reviewed by the BitShares community at the time of this writing. The ability to securely hold tokenized assets within a Hash Time-locked contract on the BitShares blockchain is a desirable feature that could be used by many persons, services, and businesses to mitigate risks between participants during asset transfer. HTLC implement conditional transfers, whereby a designated party (the "recipient") will reveal the preimage of a hash in order to execute the asset transfers from a second party (the "depositor"), else after time lock expiry "depositor" may retrieve their assets. **No third-party escrow agent is required**, rather the HTLC operation enforces conditions, evaluations and transfers through the BitShares consensus protocol. + -The [Interledger Protocol (ILP)](https://interledger.org) is a protocol for transmitting **debt claims (e.g. IOUs)** from one party (Alice) who controls an account on one Ledger (Ledger A) to another party (Bob) who controls an account on another Ledger (Ledger B) through at least one trusted intermediate party (Connector). A Connector must effectively control an account on at least two ledgers in order to "fulfill" the claim transfer across ledgers. Parties to the protocol are effectively only transferring debt claims between their immediate "peers" but the chain of peers enables the transfer across many participants. +### InterLedger Transfer + +The [InterLedger Protocol (ILP)](https://interledger.org) is a protocol for transmitting **debt claims (e.g. IOUs)** from one party (Alice) who controls an account on one Ledger (Ledger A) to another party (Bob) who controls an account on another Ledger (Ledger B) through at least one trusted intermediate party (Connector). A Connector must effectively control an account on at least two ledgers in order to "fulfill" the claim transfer across ledgers. Parties to the protocol are effectively only transferring debt claims between their immediate "peers" but the chain of peers enables the transfer across many participants. The transmission of the debt claim from Alice to Bob is called a "payment". The transmission is conveyed through a "communication channel" which may be done in any form either person-to-person, by voice, by email, by blockchain, etc. The various means of transmission have different characteristics in terms of speed and guarantee of arrival therefore a part of the protocol is focused on robustly handling these communication delays and uncertainties by embedding expiration times into the protocol. Packets that are not relayed in time result in no formal claim transfer between parties. When a recipient receives the transmission, the recipient may choose to accept or reject the debt claim transfer. @@ -168,13 +187,9 @@ There are similarities between a conditional transfer that is escrowed on the bl - Both use cases involve two accounts on the blockchain. - Both use cases involve an asset temporarily being held by the blockchain until either certain conditions are satisfied or the expiry arrives, whichever is earlier. -Nevertheless there is a crucial difference between the two use cases. In the case of a conditional transfer, the condition for release to the recipient must be satisfactory to both the depositor and the recipient. **In the case of an ILP transfer, the condition for release to the recipient is determined by only one party, the recipient,** because the sender tacitly accepts the transfer when initiating the ILP transfer. - -[Concept C of the InterLedger BSIP](https://github.com/bitshares/bsips/blob/bsip41/bisip-0041.md) elaborates on an implementation of InterLedger on BitShares that makes use of a proposed escrow feature on BitShares. This description applies an additional mechanism on top of [this BSIP's Concept D](#concept-full-release-by-blockchain)). +Nevertheless there is a crucial difference between the two use cases. In the case of a escrow contract, the condition for release to the recipient must be satisfactory to both the depositor and the recipient _after the contract is created_. In the case of an ILP transfer, the condition for release to the recipient is determined by only one party, the recipient, after the contract is created _because the sender tacitly accepts the conditional transfer when initiating the ILP transfer_. - -### LocalBitcoin -**To-do**: Elaboarate LocalBitcoin type of escrow of fiat for BTC +[Concept C of the InterLedger BSIP](https://github.com/bitshares/bsips/blob/bsip41/bisip-0041.md) elaborates on an implementation of InterLedger on BitShares that makes use of a proposed escrow feature on BitShares. That Concept differs from [this BSIP's Concept D](#concept-full-release-by-blockchain)) in one minor and one major way: the minor difference is the supplemental "address information" in ILP that is used for determining delivering the "transfer" across ledger; the major difference is that early termination in with Escrow Concept D requires the initiation by both parties after the contract begins whereas early termination in ILP Concept C only requires the initiation by the recipient after the ILP transfer begins. ## Comparison of the Related Concepts and Technologies @@ -183,6 +198,7 @@ Nevertheless there is a crucial difference between the two use cases. In the cas |-|-|-|-|-|-| |Steem Escrow|1|Yes (same ledger)|Yes|Yes (by inviting escrow agent to participate)|No| |Peerplays Escrow|1|Yes (same ledger)|Yes|No (smart contract is the sole adjudicator)|Yes (if tournament quorum is not reached); N/A after tournament begins| +|HTLC|1|Yes (same ledger)|Yes|No|Yes| |ACCT|2+|No (asset is converted across ledgers)|Yes|Yes (by not accepting the reciprocal transfer on the second ledger)|Yes| |InterLedger|2+|No (asset is converted across ledgers)|Depends on the Connector that is peered with the Recipient; only the transfer of a debt claim is guaranteed|No (only actions or inactions by the Connectors and recipient can halt the transfer)|Yes| @@ -192,20 +208,23 @@ Nevertheless there is a crucial difference between the two use cases. In the cas ## Possible Concepts to Implement The following will describe possible escrow concepts that could be implemented in BitShares. -### Concept A +### Concept A + +This concept allows the escrow agent to be invited to evaluate conditions at any time during the escrow period. |Element|Description| |-|-| |Parties|Depositor and intended recipient each have an account on the blockchain| |Escrow Assets|A quantity of an asset that exists on the blockchain| |Escrow Period Start and End|Defined in contract| -|Conditions|Conditions describe events that might occur on the blockchain (e.g. does the price of some asset rise above a particular price; etc.) or occur off-chain (e.g. did the escrow intended recipient send 50 fiat USD to the escrow depositor via a bank wire; etc.). These conditions are textually described and are intended to be interpreted by off-chain parties and agent.| +|Conditions|Conditions describe events that might occur on the blockchain (e.g. does the price of some asset rise above a particular price; etc.) or occur off-chain (e.g. did the escrow intended recipient send 50 fiat USD to the escrow depositor via a bank wire; etc.). _These conditions are textually described and are intended to be interpreted by off-chain parties and agent._| |Condition Evaluators|The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved. At that point, the escrow agent should, if he is responsible, evaluate the conditions **at least once during the escrow period**; whether the escrow agent performs this evaluation once or multiple times, or early or late during the escrow period is something that **might be** textually defined but which is not enforced by the blockchain. See [Reporting on Evaluation of Conditions](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct.| +|Timing of Condition Evaluation|When and how **can optionally be** textually described as a part of the escrow contract on the blockchain. A positive evaluation may only be signaled on the blockchain during the escrow period.| |Reporting on Evaluation of Conditions|Whichever off-chain entities are responsible for performing the evaluation must signal the outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| -|Escrow agent and fee|An escrow agent has an account on the blockchain. The fee is defined and paid to the escrow agent [by whom is TBD] as a prerequisite to initiate the escrow contract.| -|When and how frequently are escrow conditions evaluated|When and how **can optionally be** textually described as a part of the escrow contract on the blockchain. A positive evaluation must be signaled on the blockchain during the escrow period.| |What Occurs when Conditions are Satisfied|When conditions are signaled to be satisfied by the designated condition evaluators, the assets are automatically transferred to the intended recipient| -|Conclusion of Escrow without Satisfied Conditions|Escrowed assets are automatically returned to the depositors without any action by the escrow agent. See [Avoiding Appearance of Negligence](#escrow-negligence).| +|What Occurs when Conditions are Not Satisfied|Escrowed assets are automatically returned to the depositors without any action by the escrow agent. See [Avoiding Appearance of Negligence](#escrow-negligence).| +|Early Termination|The contract can be terminated early by the current condition evaluators| +|Escrow agent and fee|An escrow agent has an account on the blockchain. The fee is defined and paid to the escrow agent (by whom is flexible) as a prerequisite to initiate the escrow contract.| #### Evaluation of Concept @@ -217,11 +236,9 @@ This concept has the following weaknesses: Although this concept contains many of the elements that are often desired of an escrow contract, its weaknesses could be addressed by enhancing the concept with features than can be handled by a blockchain. -#### Technical Approach -TBD -### Concept B +### Concept B This concept is the same as Concept A except that the escrow can only participate after being invited by either escrow party. Differences are shown with **an emphasis**. @@ -232,11 +249,12 @@ This concept is the same as Concept A except that the escrow can only participat |Escrow Period Start and End|Defined in contract| |Conditions|Conditions describe events that might occur on the blockchain (e.g. does the price of some asset rise above a particular price; etc.) or occur off-chain (e.g. did the escrow intended recipient send 50 fiat USD to the escrow depositor via a bank wire; etc.). These conditions are textually described and are intended to be interpreted by off-chain parties and agent.| |Condition Evaluators|The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved. At that point, the escrow agent should, if he is responsible evaluate the conditions **at least once during the escrow period**; whether the escrow agent performs this evaluation once or multiple times, or early or late during the escrow period is something that **might be** textually defined but which is not enforced by the blockchain. See [Reporting on Evaluation of Conditions](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct.| +|Timing of Condition Evaluation|When and how **can optionally be** textually described as a part of the escrow contract on the blockchain. A positive evaluation may only be signaled on the blockchain during the escrow period.| |Reporting on Evaluation of Conditions|Whichever off-chain entities are responsible for performing the evaluation must signal **a positive** outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| -|Escrow agent and fee|An escrow agent has an account on the blockchain. The fee is defined and paid to the escrow agent [by whom is TBD] as a prerequisite to initiate the escrow contract.| -|When and how frequently are escrow conditions evaluated|When and how **can optionally be** textually described as a part of the escrow contract on the blockchain. A positive evaluation must be signaled on the blockchain during the escrow period.| |What Occurs when Conditions are Satisfied|When conditions are signaled to be satisfied by the designated condition evaluators, the assets are automatically transferred to the intended recipient| -|Conclusion of Escrow without Satisfied Conditions|Escrowed assets are automatically returned to the depositors without any action by the escrow agent. See [Avoiding Appearance of Negligence](#escrow-negligence).| +|What Occurs when Conditions are Not Satisfied|Escrowed assets are automatically returned to the depositors without any action by the escrow agent. See [Avoiding Appearance of Negligence](#escrow-negligence).| +|Early Termination|The contract can be terminated early by the current condition evaluators| +|Escrow agent and fee|An escrow agent has an account on the blockchain. The fee is defined and paid to the escrow agent [by whom is TBD] as a prerequisite to initiate the escrow contract.| #### Evaluation of Concept @@ -253,10 +271,10 @@ This concept has the following weaknesses: - An escrow agent receives the fee regardless of performing any evaluation and of recording any evidence of the evaluation on the blockchain. See [Reporting on Evaluation of Conditions](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct. #### Technical Approach -TBD (something similar to Steem escrow is a good candidate for technical implementation) +An approach similar to [Steem Escrow](#steem-escrow) is a good candidate for technical implementation. -### Concept C +### Concept C This concept is the same as Concept A except for where **the emphasis** is added. @@ -267,11 +285,12 @@ This concept is the same as Concept A except for where **the emphasis** is added |Escrow Period Start and End|Defined in contract; **an additional deadline (invitation deadline) must be specified within the escrow period that defines by when an escrow agent may be invited by either escrow party to begin conditions evaluation**| |Conditions|Conditions describe events that might occur on the blockchain (e.g. does the price of some asset rise above a particular price; etc.) or occur off-chain (e.g. did the escrow intended recipient send 50 fiat USD to the escrow depositor via a bank wire; etc.). These conditions are textually described and are intended to be interpreted by off-chain parties and agent.| |Condition Evaluators|The escrow parties may elect to evaluate the conditions themselves unless and until either party requests the escrow agent to become involved **by the invitation deadline**. At that point, the escrow agent should ~~, if he is responsible,~~ evaluate the conditions **at least once during the escrow period** **if the agent expects to receive the escrow fee**.~~; whether the escrow agent performs this evaluation once or multiple times, or early or late during the escrow period is something that **might be** textually defined but which is not enforced by the blockchain. See [Reporting on Evaluation of Conditions](#escrow-reporting) for a description of actions that could be performed by an escrow agent to demonstrate ethical conduct.~~ **Reporting on conditions evaluation may or may not include a textual description of the evaluation or a proof of a textual description (which can be used to both maintain some privacy for the escrow parties and to minimize on fees associated with the length of a textual report). A report on conditions evaluation must also include the conditions evaluation outcome so that the blockchain can resolve the escrow contract.**| -|Reporting on Evaluation of Conditions|Whichever off-chain entities are responsible for performing the evaluation must signal the outcome of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.| -|Escrow agent and fee|An escrow agent has an account on the blockchain. The fee is defined and **escrowed for the escrow agent by the blockchain** [by whom is TBD] as a prerequisite to initiate the escrow contract. **The fee is transferred to the agent upon escrow expiry if (a) the escrow agent has _not_ been requested to participate by the invitation deadline, or (b) the escrow agent _has_ been requested to participate by the escrow agent deadline and the agent has submitted at least one report of conditions evaluation**| -|When and how frequently are escrow conditions evaluated|When and how can optionally be textually described as a part of the escrow contract on the blockchain. A positive evaluation must be signaled on the blockchain during the escrow period. **If an escrow agent is invited by the invitation deadline, then the agent will be expected to report on conditions evaluation at least once between the deadline and the expiry.**| +|Timing of Condition Evaluation|When and how can optionally be textually described as a part of the escrow contract on the blockchain. A positive evaluation may only be signaled on the blockchain during the escrow period. **If an escrow agent is invited by the invitation deadline, then the agent will be expected to report on conditions evaluation at least once between the deadline and the expiry.**| +|Reporting on Evaluation of Conditions|Whichever off-chain entities are responsible for performing the evaluation must signal the _outcome_ of the evaluation on the blockchain in order for the blockchain to resolve the contract under a positive evaluation.

**Off-chain entities may optionally provide supplemental information about their evaluations multiple times throughout the escrow period.**| |What Occurs when Conditions are Satisfied|When conditions are signaled to be satisfied by the designated condition evaluators, the assets are automatically transferred to the intended recipient| -|Conclusion of Escrow without Satisfied Conditions|Escrowed assets are automatically returned to the depositors without any action by the escrow agent. **If an escrow agent is invited to participate, an escrow agent should report at least one condition evaluation on the blockchain to avoid [avoid appearance of negligence](#escrow-negligence)**.| +|What Occurs when Conditions are Not Satisfied|Escrowed assets are automatically returned to the depositors without any action by the escrow agent. **If an escrow agent is invited to participate, an escrow agent should report at least one condition evaluation on the blockchain to [avoid appearance of negligence](#escrow-negligence)**.| +|Early Termination|The contract can be terminated early by the current condition evaluators| +|Escrow agent and fee|An escrow agent has an account on the blockchain. The fee is defined and **escrowed for the escrow agent by the blockchain** [by whom is TBD] as a prerequisite to initiate the escrow contract. **The fee is transferred to the agent upon escrow expiry if (a) the escrow agent has _not_ been requested to participate by the invitation deadline, or (b) the escrow agent _has_ been requested to participate by the escrow agent deadline and the agent has submitted at least one report of conditions evaluation**| #### Evaluation of Concept @@ -280,44 +299,32 @@ This concept improves on Concept B yet has the following weaknesses: - The quality of a condition evaluations report by an escrow agent might be variable yet would be sufficient to ensure itself of receiving the escrow fee from the blockchain - If an escrow agent is invited, only a single report is required of the escrow agent by the blockchain for the agent receive the escrow fee. -#### Technical Approach -TBD ### Concept D -This concept is the same as Concept C except for where **the emphasis** is added. +This escrow concept is very similar to [pre-funded blockchain ILP transfers](#ilp-transfer) and Hash Time-Locked Contracts **except that this Concept requires acceptance or rejection by both the depositor and the recipient for full release of the funds prior to expiry;** otherwise the full funds are released to the depositor upon expiry. This concept is the same as Concept C except for where **the emphasis** is added. |Element|Description| |-|-| |Parties|Depositor and intended recipient each have an account on the blockchain| |Escrow Assets|A quantity of an asset(s) that exists on the blockchain| -|Escrow Period Start and End|**Period start is when the escrow process is submitted to the blockchain. End period is defined in the "prepare packet".**| -|Conditions|**Acceptance is signaled by both the depositor and the intended recipient**| -|Condition Evaluators|**Smart contract/operation on the blockchain**| -|Reporting on Evaluation of Conditions|**Smart-contract will report on the results of any evaluation of the conditions**| -|Escrow agent and fee|**The blockchain acts as the escrow agent. The fee is paid when the prepare packet is presented and paid by the submitter of the prepare packet.**| -|When and how frequently are escrow conditions evaluated|**Evaluated when (a) an acceptance is signaled by either party, (b) a rejection is signaled by either party, or (c) the escrow expires**| -|What Occurs when Conditions are Satisfied|**If the depositor and intended recipient signal acceptance, then the escrowed assets are released to the recipient. If a rejection is signaled, the escrowed assets are released to the depositor.**| -|Conclusion of Escrow without Satisfied Conditions|**All of the escrowed assets are released to the "sending" connected peer.**| +|Escrow Period Start and End|**Period start is when the escrow process is submitted to the blockchain. End period is defined in the smart contract.**| +|Conditions|**Acceptance or rejection is signaled by both the depositor and the recipient.**| +|Condition Evaluators|**Depositor and/or the recipient**| +|Timing of Condition Evaluation|**Evaluated when (a) an acceptance is signaled by both depositor and recipient, (b) a rejection is signaled by both depositor and recipient, or (c) the escrow expires**| +|Reporting on Evaluation of Conditions|**None**| +|What Occurs when Conditions are Satisfied|**If the depositor and intended recipient signal acceptance, then the escrowed assets are released to the recipient. If a rejection is signaled, then the escrowed assets are released to the depositor.**| +|What Occurs when Conditions are Not Satisfied|**All of the escrowed assets are released to the depositor.**| +|Early Termination|The contract can be terminated early by agreement of the depositor and recipient| +|Escrow agent and fee|**The blockchain only acts as the custodian during the escrow. The custodian fee is paid when the escrow is created.**| #### Evaluation of Concept -This concept simplifies Concept C by making a smart contract on the blockchain the sole evaluator of a condition that may or may not be presented on the blockchain before the expiration. +This concept simplifies Concept C by eliminating the introduction of an escrow agent. Off-chain conditions are evaluated by the depositor and the recipient and signaled on the blockchain. -The approach is simple in that the entire collateral is either transferred to the recipient or returned to the depositor. +The approach is simpler than Concept C in that the entire deposit is either released to the recipient or returned to the depositor. Early termination of the escrow contract is only possible with a rejection by the recipient. -The weaknesses of this Concept in contrast to Concept C is that are there is no third-party ajudicator to resolve a disagreement. +The weakness of this Concept in contrast to Concept C is that are there is no third-party ajudicator to resolve a disagreement. -#### Technical Approach -TBD - -### Concept E -TBD: Blockchain evaluation of a hash with partial release of collateral - -#### Evaluation of Concept -TBD - -#### Technical Approach -TBD # Discussion ## Responsible Escrow Behavior @@ -341,11 +348,20 @@ Escrow contracts involve transfers from one party to another that are contingent # Summary for Stakeholders -TBD +This BSIP summarized various elements that are common to different escrow concepts, and related features and concepts that are available in other blockchains. Multiple possible concepts in BitShares were surveyed and a high-level comparison of the various concepts are summarized below. +|Concept Name|Summary|Strengths|Weaknesses| +|-|-|-|-| +|[Concept A](#concept-a)|Deposit held by blockchain with optional invitation of an escrow agent.

Terms and conditions of involvement by escrow agent are textually described.|Automatic return of blockchain asset to depositor if conditions are not satisfied.|Ambiguous designation of an escrow agent.

No guarantee of sufficient evaluation time for an evaluation of conditions by an escrow.

Ambiguous involvement by an escrow agent.| +|[Concept B](#concept-b)|Deposit held by blockchain with optional invitation of an escrow agent. Terms and conditions of involvement by escrow agent are more explicit than in Concept A.

Escrow agent can report and record the outcome of condition evaluation a single time.|All the benefits of Concept A.

Escrow agent becomes involved when invited by either the depositor or recipient.

Escrow agent can record the outcome of **a single** condition evaluation and thereby avoid the obvious appearance of negligence.|Escrow agent can only record the outcome of a single evaluation of the escrow conditions.

Neither the evaluation nor proof of the evaluation is recorded on the blockchain.

No guarantee of sufficient evaluation time for an evaluation of conditions by an escrow.

An escrow agent receives the fee regardless of performing any evaluation and of recording any evidence of the evaluation on the blockchain.| +|[Concept C](#concept-c)|Deposit held by blockchain with optional invitation of an escrow agent. Terms and conditions of involvement by escrow agent are more explicit than in Concept A. Escrow agent should have sufficient time to properly evaluate on conditions. Escrow agent can report and record the outcome of a condition evaluation multiple times.|All the benefits of Concept B.

A deadline for inviting an escrow agent can ensure sufficient time for evaluation by an escrow agent.

Escrow agent can both indicate the outcome of condition evaluations **and report on the condition evaluations multiple times.**|Quality of evaluations report by escrow agent might be variable.

Only a single report by escrow agent is required for escrow to receive payment for services.| +|[Concept D](#concept-full-release-by-blockchain)|Deposit held by blockchain and released upon agreement by depositor and recipient, or expiry. Entire deposit is either delivered or returned. Similar to [pre-funded HTLC ILP transfers](#ilp-transfer) and HTLC except for the required consent by both depositor and recipient after the process has begun.

No third-party escrow agent.|All the benefits of Concept A|There is no escrow agent to resolve a disagreement between the depositor and the recipient.| # Copyright This document is placed in the public domain. # See Also - +- [Escrow support prototype code](https://github.com/bitshares/bitshares-core/pull/866) +- InterLedger on BitShares (BSIP-41) +- Hash Time-Locked Contract (BSIP-44) +- [BSIP 40: Escrow Services](https://github.com/bitshares/bsips/issues/44) From c0dd4e0aa2a612105202b138bfe640eb41af6fe2 Mon Sep 17 00:00:00 2001 From: Taconator Date: Mon, 15 Oct 2018 10:04:25 -0400 Subject: [PATCH 10/11] References to related discussions --- bsip-0046.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/bsip-0046.md b/bsip-0046.md index a5281cb..797687f 100644 --- a/bsip-0046.md +++ b/bsip-0046.md @@ -4,9 +4,7 @@ Status: Draft Type: Informational Created: 2018-04-16 - Discussion: BSIP (https://github.com/bitshares/bsips/pull/76) - conditional payment feature? (https://bitsharestalk.org/index.php/topic,23800.0.html) - 条件支付”是目前最急迫需要的功能 (https://bitsharestalk.org/index.php/topic,24155.0.html) + Discussion: BSIP (https://github.com/bitshares/bsips/pull/111) # Abstract @@ -169,7 +167,7 @@ The section describes concepts related to escrow that either exist or have been This feature implicitly involves escrowing of Asset A on Chain A while waiting for authorization to complete the transfer to A2. The sub-feature of ACCT could either be duplicated for the escrowing envisioned in this BSIP, or generalized for use by both ACCT and this BSIP. -### Hash Time-Locked Contracts (HTLC) +### Hashed Time-Lock Contracts (HTLC) Specifications for Hash Time-Locked Contract in BitShares (BSIP 44) are being reviewed by the BitShares community at the time of this writing. The ability to securely hold tokenized assets within a Hash Time-locked contract on the BitShares blockchain is a desirable feature that could be used by many persons, services, and businesses to mitigate risks between participants during asset transfer. HTLC implement conditional transfers, whereby a designated party (the "recipient") will reveal the preimage of a hash in order to execute the asset transfers from a second party (the "depositor"), else after time lock expiry "depositor" may retrieve their assets. **No third-party escrow agent is required**, rather the HTLC operation enforces conditions, evaluations and transfers through the BitShares consensus protocol. @@ -301,7 +299,7 @@ This concept improves on Concept B yet has the following weaknesses: ### Concept D -This escrow concept is very similar to [pre-funded blockchain ILP transfers](#ilp-transfer) and Hash Time-Locked Contracts **except that this Concept requires acceptance or rejection by both the depositor and the recipient for full release of the funds prior to expiry;** otherwise the full funds are released to the depositor upon expiry. This concept is the same as Concept C except for where **the emphasis** is added. +This escrow concept is very similar to [pre-funded blockchain ILP transfers](#ilp-transfer) and Hashed Time-Lock Contracts **except that this Concept requires acceptance or rejection by both the depositor and the recipient for full release of the funds prior to expiry;** otherwise the full funds are released to the depositor upon expiry. This concept is the same as Concept C except for where **the emphasis** is added. |Element|Description| |-|-| @@ -349,6 +347,7 @@ Escrow contracts involve transfers from one party to another that are contingent # Summary for Stakeholders This BSIP summarized various elements that are common to different escrow concepts, and related features and concepts that are available in other blockchains. Multiple possible concepts in BitShares were surveyed and a high-level comparison of the various concepts are summarized below. + |Concept Name|Summary|Strengths|Weaknesses| |-|-|-|-| |[Concept A](#concept-a)|Deposit held by blockchain with optional invitation of an escrow agent.

Terms and conditions of involvement by escrow agent are textually described.|Automatic return of blockchain asset to depositor if conditions are not satisfied.|Ambiguous designation of an escrow agent.

No guarantee of sufficient evaluation time for an evaluation of conditions by an escrow.

Ambiguous involvement by an escrow agent.| @@ -361,7 +360,8 @@ This BSIP summarized various elements that are common to different escrow concep This document is placed in the public domain. # See Also -- [Escrow support prototype code](https://github.com/bitshares/bitshares-core/pull/866) +- [Github Issue on Escrow Services](https://github.com/bitshares/bsips/issues/44) - InterLedger on BitShares (BSIP-41) -- Hash Time-Locked Contract (BSIP-44) +- [Hashed Time-Lock Contract (BSIP-44)](https://github.com/bitshares/bsips/pull/112) - [BSIP 40: Escrow Services](https://github.com/bitshares/bsips/issues/44) +- [Escrow support prototype code](https://github.com/bitshares/bitshares-core/pull/866) From f623715fc3a5cb5e737982292e2fc974fc71e738 Mon Sep 17 00:00:00 2001 From: Taconator Date: Wed, 9 Jan 2019 09:00:46 -0400 Subject: [PATCH 11/11] Clean document by request --- bsip-0046.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/bsip-0046.md b/bsip-0046.md index 797687f..32252a3 100644 --- a/bsip-0046.md +++ b/bsip-0046.md @@ -187,8 +187,6 @@ There are similarities between a conditional transfer that is escrowed on the bl Nevertheless there is a crucial difference between the two use cases. In the case of a escrow contract, the condition for release to the recipient must be satisfactory to both the depositor and the recipient _after the contract is created_. In the case of an ILP transfer, the condition for release to the recipient is determined by only one party, the recipient, after the contract is created _because the sender tacitly accepts the conditional transfer when initiating the ILP transfer_. -[Concept C of the InterLedger BSIP](https://github.com/bitshares/bsips/blob/bsip41/bisip-0041.md) elaborates on an implementation of InterLedger on BitShares that makes use of a proposed escrow feature on BitShares. That Concept differs from [this BSIP's Concept D](#concept-full-release-by-blockchain)) in one minor and one major way: the minor difference is the supplemental "address information" in ILP that is used for determining delivering the "transfer" across ledger; the major difference is that early termination in with Escrow Concept D requires the initiation by both parties after the contract begins whereas early termination in ILP Concept C only requires the initiation by the recipient after the ILP transfer begins. - ## Comparison of the Related Concepts and Technologies @@ -361,7 +359,6 @@ This document is placed in the public domain. # See Also - [Github Issue on Escrow Services](https://github.com/bitshares/bsips/issues/44) -- InterLedger on BitShares (BSIP-41) - [Hashed Time-Lock Contract (BSIP-44)](https://github.com/bitshares/bsips/pull/112) -- [BSIP 40: Escrow Services](https://github.com/bitshares/bsips/issues/44) +- [Escrow Services](https://github.com/bitshares/bsips/issues/44) - [Escrow support prototype code](https://github.com/bitshares/bitshares-core/pull/866)