User:Casascius/Escrow scheme draft - Revision history

Casascius: /* Base58 codes (draft) for 3-party scheme */

2012-12-14T04:27:45Z

Base58 codes (draft) for 3-party scheme

← Older revision		Revision as of 04:27, 14 December 2012
Line 90:		Line 90:
	* 8 bytes: Int64 sum of 0x140bebcba900182f plus ''identifier31'' from the accepted escrow proposal		* 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: 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		* 32 bytes: z
			* 20 bytes: hash160 of expected bitcoin address
	* 1 byte: bitflags		* 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 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.		** 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		** 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		* 20 bytes: hash160 of expected bitcoin address
	* 12 bytes: set to all 0's		* 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

Casascius: /* Base58 codes (draft) for 3-party scheme */

2012-12-14T00:09:27Z

Base58 codes (draft) for 3-party scheme

← Older revision		Revision as of 00:09, 14 December 2012
Line 81:		Line 81:
	Escrow invitation from escrow agent is 106 Base58 characters starting with "einva" or "einvb". It consists of the following bytes:		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.		* 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: ~~0x140bebc0f619ffdd~~		** Constant for part a: 0x140bebc0a12ca9c6
	** Constant for part b: ~~0x140bebc1bfcdac52~~		** Constant for part b: 0x140bebc16ae0563b
	* 1 byte: reserved, set this to 0 and reject an invitation that has something other than 0 here		* 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)		* 32 bytes: x or y (invitation part a gets x, invitation part b gets y)
Line 88:		Line 88:

	Payment invitation generated by payee contains an additional 256-bit number z, and is 106 Base58 characters starting with "einvp" as follows:		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 ~~0x140bebcbfded6e45~~ plus ''identifier31'' from the accepted escrow proposal		* 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: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)
	* 32 bytes: z		* 32 bytes: z

Casascius: /* Base58 codes (draft) for 3-party scheme */

2012-12-13T23:47:26Z

Base58 codes (draft) for 3-party scheme

← Older revision		Revision as of 23:47, 13 December 2012
Line 83:		Line 83:
	** Constant for part a: 0x140bebc0f619ffdd		** Constant for part a: 0x140bebc0f619ffdd
	** Constant for part b: 0x140bebc1bfcdac52		** Constant for part b: 0x140bebc1bfcdac52
	* 1 byte: reserved, set this to 0		* 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)		* 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)		* 33 bytes: Gx or Gy (invitation part a gets Gy, invitation part b gets Gx)

Casascius: /* Base58 codes (draft) for 3-party scheme */

2012-12-13T23:46:56Z

Base58 codes (draft) for 3-party scheme

← Older revision		Revision as of 23:46, 13 December 2012
Line 83:		Line 83:
	** Constant for part a: 0x140bebc0f619ffdd		** Constant for part a: 0x140bebc0f619ffdd
	** Constant for part b: 0x140bebc1bfcdac52		** Constant for part b: 0x140bebc1bfcdac52
	* 1 byte: 0 to ~~represent the type of coin (~~0~~=bitcoin, 111=testnet, other values reserved for altcoins)~~		* 1 byte: reserved, set this to 0
	* 32 bytes: x or y (invitation part a gets x, invitation part b gets y)		* 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)		* 33 bytes: Gx or Gy (invitation part a gets Gy, invitation part b gets Gx)
Line 92:		Line 92:
	* 32 bytes: z		* 32 bytes: z
	* 1 byte: bitflags		* 1 byte: bitflags
	** Bit with value 0x02: 0 if payment invitation was created ~~with~~ the "einva" invitation code, 1 if invitation was created with the "einvb" invitation code (assuming an app allows it)		** 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.		** 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		** all other bits: reserved and must be 0
	* 20 bytes: hash160 of expected bitcoin address		* 20 bytes: hash160 of expected bitcoin address
	* 12 bytes: set to all 0's		* 12 bytes: set to all 0's

Casascius: /* Base58 codes (draft) for 3-party scheme */

2012-12-13T23:40:21Z

Base58 codes (draft) for 3-party scheme

← Older revision		Revision as of 23:40, 13 December 2012
Line 91:		Line 91:
	* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)		* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)
	* 32 bytes: z		* 32 bytes: z
	* 1 byte: 0 if bitcoin address to be paid will use an uncompressed public key, 1 if it will use a compressed public key.		* 1 byte: bitflags
			** Bit with value 0x02: 0 if payment invitation was created with 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
	* 20 bytes: hash160 of expected bitcoin address		* 20 bytes: hash160 of expected bitcoin address
	* 12 bytes: set to all 0's		* 12 bytes: set to all 0's

Casascius: /* Base58 codes (draft) for 3-party scheme */

2012-12-13T23:37:26Z

Base58 codes (draft) for 3-party scheme

← Older revision		Revision as of 23:37, 13 December 2012
Line 77:		Line 77:
	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).		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 ~~four~~ or ~~five~~ characters following the prefixes to be the same for matching invitations. This number will be referred to as ''identifier31''.		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:		Escrow invitation from escrow agent is 106 Base58 characters starting with "einva" or "einvb". It consists of the following bytes:

Casascius: /* Base58 codes (draft) for 3-party scheme */

2012-12-13T23:35:18Z

Base58 codes (draft) for 3-party scheme

← Older revision		Revision as of 23:35, 13 December 2012
Line 80:		Line 80:

	Escrow invitation from escrow agent is 106 Base58 characters starting with "einva" or "einvb". It consists of the following bytes:		Escrow invitation from escrow agent is 106 Base58 characters starting with "einva" or "einvb". It consists of the following bytes:
	* 16 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.		* 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: 0x140bebc0f619ffdd		** Constant for part a: 0x140bebc0f619ffdd
	** Constant for part b: 0x140bebc1bfcdac52		** Constant for part b: 0x140bebc1bfcdac52
			* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet, other values reserved for altcoins)
	* 32 bytes: x or y (invitation part a gets x, invitation part b gets y)		* 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)		* 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:		Payment invitation generated by payee contains an additional 256-bit number z, and is 106 Base58 characters starting with "einvp" as follows:
	* 16 bytes: Int64 sum of 0x140bebcbfded6e45 plus ''identifier31'' from the accepted escrow proposal		* 8 bytes: Int64 sum of 0x140bebcbfded6e45 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)
	* 32 bytes: z		* 32 bytes: z
	* 1 byte: 0 if bitcoin address to be paid will use an uncompressed public key, 1 if it will use a compressed public key.		* 1 byte: 0 if bitcoin address to be paid will use an uncompressed public key, 1 if it will use a compressed public key.
	* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet)
	* 20 bytes: hash160 of expected bitcoin address		* 20 bytes: hash160 of expected bitcoin address
	* 11 bytes: set to all 0's		* 12 bytes: set to all 0's

Casascius at 23:28, 13 December 2012

2012-12-13T23:28:47Z

← Older revision		Revision as of 23:28, 13 December 2012
Line 71:		Line 71:
	* a will never known by Eddie or Charlie and this prevents them from ever gaining access to 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.		* 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 four or five 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:
			* 16 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: 0x140bebc0f619ffdd
			** Constant for part b: 0x140bebc1bfcdac52
			* 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:
			* 16 bytes: Int64 sum of 0x140bebcbfded6e45 plus ''identifier31'' from the accepted escrow proposal
			* 32 bytes: z
			* 1 byte: 0 if bitcoin address to be paid will use an uncompressed public key, 1 if it will use a compressed public key.
			* 1 byte: 0 to represent the type of coin (0=bitcoin, 111=testnet)
			* 20 bytes: hash160 of expected bitcoin address
			* 11 bytes: set to all 0's

Casascius: /* Initiation of Proposal */

2012-12-08T23:57:25Z

Initiation of Proposal

← Older revision		Revision as of 23:57, 8 December 2012
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 "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.		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.

Casascius: /* Four party scheme */

2012-12-08T16:10:46Z

Four party scheme

← Older revision		Revision as of 16:10, 8 December 2012
Line 54:		Line 54:
	Charlie must make the initial proposal, as everything else depends on keys produced by Charlie.		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~~. He gives Gx to Alice~~.		* Charlie creates private keys x and y. He gives x and Gy to Bob and y to Eddie.
	* Bob creates private ~~key~~ b. He gives it to ~~Eddie. Bob has b, x, and Gy~~. He gives ~~Gbxy~~ to ~~Alice.~~		* 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 creates private key a. ~~She~~ gives ~~it to Bob. Alice has a, Gx,~~ and ~~Gbxy. She gives~~ Gax to Eddie.		* Alice and Eddie don't create any private keys.
	* ~~Now that Bob knows a, he provides Gab to Charlie.~~
	* Eddie ~~doesn~~'t create any private keys ~~but knows y, b, and Gax~~.
	After all proposals and acceptances have been exchanged:		After all proposals and acceptances have been exchanged:
	* Charlie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.		* Charlie knows x, y, and Gab. He calculates the Bitcoin address as (Gab)xy.
	* Alice knows a and ~~Gbxy~~. She calculates the Bitcoin address as (~~Gxy~~)ab.		* 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.		* Bob knows b, a, x, and Gy. He calculates the Bitcoin address as (Gy)abx.
	* Eddie knows ~~Gabx~~ and y. He calculates the Bitcoin address as (~~Gabx~~)y.		* 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:		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).		* Charlie can release the funds to Bob by giving him y (or the original record he gave to Eddie).
Line 71:		Line 69:
	* x represents Charlie's control, ensures that Alice can't get funds without his consent.		* 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		* y represents Charlie's and Eddie's ability to decide if and when Bob gets the funds
	* a is never known by Eddie or Charlie and prevents them from ever gaining access to 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.		* b represents Eddie's ability to override Bob and to consent to Alice getting the funds.