User:Casascius/Escrow scheme draft: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
Casascius (talk | contribs)
Created page with "This is a draft for a three-party or four-party scheme that enables an escrow transaction using nothing more than standard (non-multi-signature) Bitcoin transactions. This pr..."
 
Casascius (talk | contribs)
No edit summary
Line 12: Line 12:
* '''E - Escrow Agent Eddie''' - This person gets the power to award control of the funds to either Alice or Bob if the two of them cannot agree who amongst themselves should get the funds.
* '''E - Escrow Agent Eddie''' - This person gets the power to award control of the funds to either Alice or Bob if the two of them cannot agree who amongst themselves should get the funds.
* '''C - Customer Charlie (optional)''' - If Charlie is a party to the transaction, then Charlie is the person paying into the escrow account with no hope of receiving a refund.  Charlie has the power to grant the proceeds of the funds to Bob or Alice, but only if the Eddie doesn't do it first.  Charlie can also verify, with the help of a tool, that he is paying into an account under the control of Bob, Alice, and Eddie, rather than into someone's personal wallet.
* '''C - Customer Charlie (optional)''' - If Charlie is a party to the transaction, then Charlie is the person paying into the escrow account with no hope of receiving a refund.  Charlie has the power to grant the proceeds of the funds to Bob or Alice, but only if the Eddie doesn't do it first.  Charlie can also verify, with the help of a tool, that he is paying into an account under the control of Bob, Alice, and Eddie, rather than into someone's personal wallet.
==How the scheme works==
First, any of the parties (other than Customer Charlie) can initiate an escrow transaction proposal.  The second party creates a proposal that references the first.  The third party creates an acceptance.
A proposal or acceptance is a Base58-encoded string whose prefix specifies who created the record and to whom it should be given.  The parties can initiate and accept in any order, with one exception: the escrow agent must be first or second.
The prefixes for the strings are always four characters, that follow this format:
* First character: who created the string (B, A, or E)
* Second character: whether this is a Proposal (P) or Acceptance (A)
* Third character: the number 4
* Fourth character: the intended recipient of the string (B, A, E, or C).
Initiation involves generating cryptographic key(s), and creates two Base58-encoded records containing the applicable keys (public or private) and signaling the party's intentions.  One record is given to each other party.
The second party takes the record from the first party, and generates another Base58-encoded record to give to the third party.

Revision as of 02:41, 8 December 2012

This is a draft for a three-party or four-party scheme that enables an escrow transaction using nothing more than standard (non-multi-signature) Bitcoin transactions. This proposal contemplates the following features:

  1. One shared Bitcoin address for the entire transaction
  2. All parties to the transaction can verify that the Bitcoin address belongs to the transaction they're participating in, and not one made up or taken from someone's own personal wallet
  3. Escrow agent can control the disposition of the funds but cannot take the funds
  4. Releasing the funds remains possible even if the escrow agent disappears

The proposal contemplates up to four roles, defined as follows:

  • B - Beneficiary Bob - Bob is the person providing the goods or services, and who will receive control the proceeds of the transaction if there is no dispute and the goods or services are delivered as promised.
  • A - Alternate Beneficiary Alice (or Customer Alice): Alice is the person who will receive the proceeds of the transaction if either the Bob or the Escrow Agent decide that the funds should not go to the Beneficiary. Alice might or might not be the customer who is paying into the escrow transaction. If Alice is the customer, then allowing the funds to go to Alice constitutes a refund. If Alice is not the customer, then Alice is an alternate beneficiary who may be granted access to the funds by the Escrow Agent in the event they determine it should not go to Bob, and might be a person more able to settle a dispute than anyone else.
  • E - Escrow Agent Eddie - This person gets the power to award control of the funds to either Alice or Bob if the two of them cannot agree who amongst themselves should get the funds.
  • C - Customer Charlie (optional) - If Charlie is a party to the transaction, then Charlie is the person paying into the escrow account with no hope of receiving a refund. Charlie has the power to grant the proceeds of the funds to Bob or Alice, but only if the Eddie doesn't do it first. Charlie can also verify, with the help of a tool, that he is paying into an account under the control of Bob, Alice, and Eddie, rather than into someone's personal wallet.

How the scheme works

First, any of the parties (other than Customer Charlie) can initiate an escrow transaction proposal. The second party creates a proposal that references the first. The third party creates an acceptance.

A proposal or acceptance is a Base58-encoded string whose prefix specifies who created the record and to whom it should be given. The parties can initiate and accept in any order, with one exception: the escrow agent must be first or second.

The prefixes for the strings are always four characters, that follow this format:

  • First character: who created the string (B, A, or E)
  • Second character: whether this is a Proposal (P) or Acceptance (A)
  • Third character: the number 4
  • Fourth character: the intended recipient of the string (B, A, E, or C).

Initiation involves generating cryptographic key(s), and creates two Base58-encoded records containing the applicable keys (public or private) and signaling the party's intentions. One record is given to each other party.

The second party takes the record from the first party, and generates another Base58-encoded record to give to the third party.