User:Casascius/Escrow scheme draft: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
← Older edit
Casascius (talk | contribs)
Editors
618 edits
No edit summary
Casascius (talk | contribs)
Editors
618 edits
 
(12 intermediate revisions by the same user not shown)
Line 16: Line 16:


===Initiation of Proposal===
===Initiation of Proposal===
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.
First, one of the parties initiates an escrow transaction proposal.  The second party creates a proposal that "seconds" the first.  The third party either "accepts" the proposal (if it's a three party transaction) or "thirds" it, and finally (if applicable), the fourth party accepts it.


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.
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.
Line 22: Line 22:
The prefixes for the strings are always four characters, that follow this format:
The prefixes for the strings are always four characters, that follow this format:
* First character: who created the string (B, A, or E)
* First character: who created the string (B, A, or E)
* Second character: whether this is a Proposal (P), Seconding (S), Acceptance (A), or Confirmation (C)
* Second character: whether this is a Proposal (P), Seconding (2), Thirding (3), or Acceptance (A)
* Third character: the number 4
* Third character: the number 4
* Fourth character: the intended recipient of the string (B, A, E, or C).
* Fourth character: the intended recipient of the string (B, A, E, or C).
Line 30: Line 30:
Initiation involves generating cryptographic key(s), and creating 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.
Initiation involves generating cryptographic key(s), and creating 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.


If a prospective Escrow Agent initiates a proposal, he generates two private keys we'll call x and y.  He emits two records with prefixes EP4A and EP4B.
====Three party scheme====
* EP4A contains private key x and public key Gy.
* EP4B contains private key y and public key Gx.
* Both records contain a 32-bit proposal identifier (which is the first 32 bits of RIPEMD160(SHA256(Gxy))).


If a prospective Beneficiary initiates a proposal, he generates a private key we'll call b.  He emits two records with prefixes BP4A and BP4E.
A three party scheme involves Alice paying Bob, and Eddie being the escrow agent.  Alice and Bob can release the funds to one another without Eddie's help, and Eddie can break a tie and force the funds to go to either Alice or Bob if the two of them don't agree.
* BP4A contains private key b.
* BP4E contains public key Gb.
* Both records contain a 32-bit proposal identifier, the first 32 bits of RIPEMD160(SHA256(Gb)).


If a prospective Alternate Beneficiary, or Customer who is also an Alternate Beneficiary, initiates a proposal, she generates a private key we'll call a.  She emits two records with prefixes AP4B and AP4E.
* Eddie creates private keys x and y.  He gives Alice x and Gy.  He gives Bob y and Gx.
* AP4B contains private key a.
* Alice creates private key a.  She gives Bob a.  She gives Eddie Gab if she knows b.
* AP4E contains public key Ga.
* Bob creates private key b.  He gives Alice b.  He gives Eddie Gab if he knows a.
* Both records contain a 32-bit proposal identifier, the first 32 bits of RIPEMD160(SHA256(Ga)).
After all proposals acceptances have been exchanged:
* Eddie knows x, y, and Gab.  He calculates the Bitcoin address as (Gab)xy.
* Alice knows a, b, x, and Gy.  She calculates the Bitcoin address as (Gy)abx.
* Bob knows a, b, y, and Gx.  She calculates the Bitcoin address as (Gx)aby.
Once all parties agree they have the same Bitcoin address, Alice pays, and then:
* Alice releases the funds to Bob by giving him x (or Eddie's original record to him containing x and Gy).
* Bob can give Alice a refund by giving her y (or Eddie's original record to him containing y and Gx).
* Eddie can force the funds to go to Alice by giving her y (or the original record he gave to Bob).
* Eddie can force the funds to go to Bob by giving him x (or the original record he gave to Alice).


===Intermediate acceptance and secondary proposal===
====Four party scheme====
A party who receives an initial proposal as described above may Second the proposal and become the second party, producing an Acceptance record for the proposing party, and a Seconding record for the remaining party.
A four party scheme involves Charlie the customer paying Bob the beneficiary, with no chance that he could get his money back without the combined consent of Alice and Eddie.  Even then, Alice would have sole control over the funds and would choose where they ultimately go - if they should automatically go back to Charlie, the three-party scheme would work better.  Alice is the alternate beneficiary - a third party entrusted to receive full control over the money in case Charlie and Eddie are certain it must not go to Bob.


Proposals can be created and accepted by the parties in any order, except the escrow agent cannot be last.
In this scheme, Charlie can independently release the funds to Bob without anyone else's help.  Eddie can also release them to Bob without help from Charlie.  However, if Charlie and Eddie both agree that Bob shouldn't get the funds, then they can collectively agree to have the funds go to Alice; neither Charlie nor Eddie can send the funds to Alice acting alone.


If a prospective Escrow Agent seconds an initial proposal from a Beneficiary, then he generates private keys x and y, and emits an Acceptance record with prefix EA4B and a Seconding record with prefix ES4A.
Charlie must make the initial proposal, as everything else depends on keys produced by Charlie.
* EA4B contains private key y and public key Gx.
* ES4A contains private key x and public key Gy.
* Both records use the same 32-bit proposal identifier that came from the Beneficiary, which is a hash based on Gb.
* The proposal record has bits set indicating that it is also the acceptance of a proposal by a prospective Beneficiary.


If a prospective Escrow Agent accepts an initial proposal from an Alternate Beneficiary / Customer who is also an Alternate Beneficiary, the same method is employed as described above, except swap all a and b, and swap all x and y as applicable.
* Charlie creates private keys x and y.  He gives x and Gy to Bob and y to Eddie.
* Bob creates private keys a and b.  He gives a and Gybx to Alice.  He gives Gab to Charlie.  He gives b and Gax to Eddie.
* Alice and Eddie don't create any private keys.
After all proposals and acceptances have been exchanged:
* Charlie knows x, y, and Gab.  He calculates the Bitcoin address as (Gab)xy.
* Alice knows a and Gybx.  She calculates the Bitcoin address as (Gybx)a.
* Bob knows b, a, x, and Gy.  He calculates the Bitcoin address as (Gy)abx.
* Eddie knows Gax, b and y.  He calculates the Bitcoin address as (Gax)by.
Once all parties agree they have the same Bitcoin address, Charlie pays, and then:
* Charlie can release the funds to Bob by giving him y (or the original record he gave to Eddie).
* Eddie can release the funds to Bob by giving him y (or the original record Charlie gave him).
* If Charlie and Eddie agree that Alice should get the funds, then Charlie gives her x and y, and Eddie gives her b.
And just so it's clear:
* x represents Charlie's control, ensures that Alice can't get funds without his consent.
* y represents Charlie's and Eddie's ability to decide if and when Bob gets the funds
* a will never known by Eddie or Charlie and this prevents them from ever gaining access to the funds
* b represents Eddie's ability to override Bob and to consent to Alice getting the funds.


If a prospective Beneficiary accepts an initial proposal created by an Escrow Agent, then he generates private key b, and emits an acceptance record BA4E and a secondary proposal record with prefix BP4A.
* BA4E contains public keys Gb and Gab.
* BP4A contains private key b.
* Both records use the same 32-bit proposal identifier that came from the Escrow Agent, which is a hash based on Gxy.


If a prospective Alternate Beneficiary accepts an initial proposal created by an Escrow Agent, follow the same procedure for a Beneficiary, swapping a and b, and x and y.
==Base58 codes (draft) for 3-party scheme==


===Final acceptance===
An escrow invitation starts out with two random 256 bit numbers, x and y.  One party receiving the invitation will get Gx and y, the other gets Gy and x, they should both be able to calculate Gxy.  The identifier for the proposal is the hash of Gxy (compressed notation).
A party in a position to issue a final acceptance will have received two proposals with identical proposal identifiers.  That party should generate its own private key(s) as defined in the other stages, and emit acceptance records for the benefit of the first two parties.  It is at this point that the accepting party knows the Bitcoin address for the entire arrangement.
* If the final acceptance happens by an Escrow Agent, he knows Gab, x, and y, and can calculate the Bitcoin address as (Gab)xy.
* If the final acceptance happens by a Beneficiary or Alternate Beneficiary, he/she knows or can calculate Gxy and knows a and b.  He or she can calculate the Bitcoin address as (Gxy)ab.


Upon final acceptance, each party is in a position to issue a confirmation record for the benefit of Charlie the paying-only customer.  This confirmation permits Charlie to ensure he is paying an address that is participating in an escrow scheme.
We will use 31 bits of the proposal (four most significant bytes & 0x7fffffff) as the identifier.  This allows for the prefixes einva, einvb, einvc, as well as five or six characters following the prefixes to be the same for matching invitations.  This number will be referred to as ''identifier31''.


If confirmation is needed, each party shall issue one.  Charlie will need three records in order to receive a satisfactory confirmation.
Escrow invitation from escrow agent is 106 Base58 characters starting with "einva" or "einvb".  It consists of the following bytes:
* The Escrow Agent provides a confirmation record which starts with EC4C and contains:
* 8 bytes: Int64 sum of a constant plus ''identifier31''.  The constant depends on whether this is to create part a or b.  Using this value results in the "einva" or "einvb" prefix as well as several more identical characters when a set is matched.  In this case, "plus" refers to addition.
* The Beneficiary provides a confirmation which starts with BC4C and contains:
** Constant for part a: 0x140bebc0a12ca9c6
** Constant for part b: 0x140bebc16ae0563b
* 1 byte: reserved, set this to 0 and reject an invitation that has something other than 0 here
* 32 bytes: x or y (invitation part a gets x, invitation part b gets y)
* 33 bytes: Gx or Gy (invitation part a gets Gy, invitation part b gets Gx)
 
Payment invitation generated by payee contains an additional 256-bit number z, and is 106 Base58 characters starting with "einvp" as follows:
* 8 bytes: Int64 sum of 0x140bebcba900182f plus ''identifier31'' from the accepted escrow proposal
* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)
* 1 byte: reserved, must be 0
* 32 bytes: z
* 20 bytes: hash160 of expected bitcoin address
* 1 byte: bitflags
** Bit with value 0x02: 0 if payment invitation was created by someone who knows the "einva" invitation code, 1 if invitation was created with the "einvb" invitation code (assuming an app allows it)
** Bit with value 0x01: 0 if bitcoin address to be paid will use an uncompressed public key, 1 if it will use a compressed public key.
** all other bits: reserved and must be 0
* 11 bytes: set to all 0's
 
Payment confirmation generated by payee contains Gz and is 106 Base58 characters starting with "cfrmp".  Its purpose is to prove the association of the generated Bitcoin address to the escrow agent, if needed, without giving away z, which would grant the ability to redeem funds.
Payment invitation generated by payee contains an additional 256-bit number z, and is 106 Base58 characters starting with "einvp" as follows:
* 8 bytes: Int64 sum of 0x12f4eff38f7d74f9 plus ''identifier31'' from the accepted escrow proposal
* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)
* 33 bytes: Gz
* 20 bytes: hash160 of expected bitcoin address
* 1 byte: bitflags
** Bit with value 0x02: 0 if address confirmation was created by someone who knows the "einva" invitation code, 1 if invitation was created with the "einvb" invitation code (assuming an app allows it)
** Bit with value 0x01: 0 if bitcoin address to be paid will use an uncompressed public key, 1 if it will use a compressed public key.
** all other bits: reserved and must be 0
* 11 bytes: set to all 0's

Latest revision as of 04:27, 14 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

Initiation of Proposal

First, one of the parties initiates an escrow transaction proposal. The second party creates a proposal that "seconds" the first. The third party either "accepts" the proposal (if it's a three party transaction) or "thirds" it, and finally (if applicable), the fourth party accepts it.

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), Seconding (2), Thirding (3), or Acceptance (A)
  • Third character: the number 4
  • Fourth character: the intended recipient of the string (B, A, E, or C).

As an example, if someone creates a proposal and selects that they intend to be the Escrow Agent, then their client will generate two strings: one starting with EP4A and the other starting with EP4B.

Initiation involves generating cryptographic key(s), and creating 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.

Three party scheme

A three party scheme involves Alice paying Bob, and Eddie being the escrow agent. Alice and Bob can release the funds to one another without Eddie's help, and Eddie can break a tie and force the funds to go to either Alice or Bob if the two of them don't agree.

  • Eddie creates private keys x and y. He gives Alice x and Gy. He gives Bob y and Gx.
  • Alice creates private key a. She gives Bob a. She gives Eddie Gab if she knows b.
  • Bob creates private key b. He gives Alice b. He gives Eddie Gab if he knows a.

After all proposals acceptances have been exchanged:

  • Eddie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
  • Alice knows a, b, x, and Gy. She calculates the Bitcoin address as (Gy)abx.
  • Bob knows a, b, y, and Gx. She calculates the Bitcoin address as (Gx)aby.

Once all parties agree they have the same Bitcoin address, Alice pays, and then:

  • Alice releases the funds to Bob by giving him x (or Eddie's original record to him containing x and Gy).
  • Bob can give Alice a refund by giving her y (or Eddie's original record to him containing y and Gx).
  • Eddie can force the funds to go to Alice by giving her y (or the original record he gave to Bob).
  • Eddie can force the funds to go to Bob by giving him x (or the original record he gave to Alice).

Four party scheme

A four party scheme involves Charlie the customer paying Bob the beneficiary, with no chance that he could get his money back without the combined consent of Alice and Eddie. Even then, Alice would have sole control over the funds and would choose where they ultimately go - if they should automatically go back to Charlie, the three-party scheme would work better. Alice is the alternate beneficiary - a third party entrusted to receive full control over the money in case Charlie and Eddie are certain it must not go to Bob.

In this scheme, Charlie can independently release the funds to Bob without anyone else's help. Eddie can also release them to Bob without help from Charlie. However, if Charlie and Eddie both agree that Bob shouldn't get the funds, then they can collectively agree to have the funds go to Alice; neither Charlie nor Eddie can send the funds to Alice acting alone.

Charlie must make the initial proposal, as everything else depends on keys produced by Charlie.

  • Charlie creates private keys x and y. He gives x and Gy to Bob and y to Eddie.
  • Bob creates private keys a and b. He gives a and Gybx to Alice. He gives Gab to Charlie. He gives b and Gax to Eddie.
  • Alice and Eddie don't create any private keys.

After all proposals and acceptances have been exchanged:

  • Charlie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
  • Alice knows a and Gybx. She calculates the Bitcoin address as (Gybx)a.
  • Bob knows b, a, x, and Gy. He calculates the Bitcoin address as (Gy)abx.
  • Eddie knows Gax, b and y. He calculates the Bitcoin address as (Gax)by.

Once all parties agree they have the same Bitcoin address, Charlie pays, and then:

  • Charlie can release the funds to Bob by giving him y (or the original record he gave to Eddie).
  • Eddie can release the funds to Bob by giving him y (or the original record Charlie gave him).
  • If Charlie and Eddie agree that Alice should get the funds, then Charlie gives her x and y, and Eddie gives her b.

And just so it's clear:

  • x represents Charlie's control, ensures that Alice can't get funds without his consent.
  • y represents Charlie's and Eddie's ability to decide if and when Bob gets the funds
  • a will never known by Eddie or Charlie and this prevents them from ever gaining access to the funds
  • b represents Eddie's ability to override Bob and to consent to Alice getting the funds.


Base58 codes (draft) for 3-party scheme

An escrow invitation starts out with two random 256 bit numbers, x and y. One party receiving the invitation will get Gx and y, the other gets Gy and x, they should both be able to calculate Gxy. The identifier for the proposal is the hash of Gxy (compressed notation).

We will use 31 bits of the proposal (four most significant bytes & 0x7fffffff) as the identifier. This allows for the prefixes einva, einvb, einvc, as well as five or six characters following the prefixes to be the same for matching invitations. This number will be referred to as identifier31.

Escrow invitation from escrow agent is 106 Base58 characters starting with "einva" or "einvb". It consists of the following bytes:

  • 8 bytes: Int64 sum of a constant plus identifier31. The constant depends on whether this is to create part a or b. Using this value results in the "einva" or "einvb" prefix as well as several more identical characters when a set is matched. In this case, "plus" refers to addition.
    • Constant for part a: 0x140bebc0a12ca9c6
    • Constant for part b: 0x140bebc16ae0563b
  • 1 byte: reserved, set this to 0 and reject an invitation that has something other than 0 here
  • 32 bytes: x or y (invitation part a gets x, invitation part b gets y)
  • 33 bytes: Gx or Gy (invitation part a gets Gy, invitation part b gets Gx)

Payment invitation generated by payee contains an additional 256-bit number z, and is 106 Base58 characters starting with "einvp" as follows:

  • 8 bytes: Int64 sum of 0x140bebcba900182f plus identifier31 from the accepted escrow proposal
  • 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)
  • 1 byte: reserved, must be 0
  • 32 bytes: z
  • 20 bytes: hash160 of expected bitcoin address
  • 1 byte: bitflags
    • Bit with value 0x02: 0 if payment invitation was created by someone who knows the "einva" invitation code, 1 if invitation was created with the "einvb" invitation code (assuming an app allows it)
    • Bit with value 0x01: 0 if bitcoin address to be paid will use an uncompressed public key, 1 if it will use a compressed public key.
    • all other bits: reserved and must be 0
  • 11 bytes: set to all 0's

Payment confirmation generated by payee contains Gz and is 106 Base58 characters starting with "cfrmp". Its purpose is to prove the association of the generated Bitcoin address to the escrow agent, if needed, without giving away z, which would grant the ability to redeem funds. Payment invitation generated by payee contains an additional 256-bit number z, and is 106 Base58 characters starting with "einvp" as follows:

  • 8 bytes: Int64 sum of 0x12f4eff38f7d74f9 plus identifier31 from the accepted escrow proposal
  • 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)
  • 33 bytes: Gz
  • 20 bytes: hash160 of expected bitcoin address
  • 1 byte: bitflags
    • Bit with value 0x02: 0 if address confirmation was created by someone who knows the "einva" invitation code, 1 if invitation was created with the "einvb" invitation code (assuming an app allows it)
    • Bit with value 0x01: 0 if bitcoin address to be paid will use an uncompressed public key, 1 if it will use a compressed public key.
    • all other bits: reserved and must be 0
  • 11 bytes: set to all 0's
Retrieved from "https://en.bitcoin.it/w/index.php?title=User:Casascius/Escrow_scheme_draft&oldid=33738"