Background

Multi-signature technology

Bitcoin contains a special escrow system called multi-signature addresses, which were introduced in Bitcoin Improvement Proposal 11. Funds placed into this escrow state cannot be accessed without permission from multiple people.

An m-of-n multi-signature address is created with the public keys of n people, and m of those keys are required to sign off on any expenditures. Early Temple uses 2-of-3 addresses, made from the public key of the sender, the public key of the receiver, and one generated by Early Temple for the contract. None of the three parties have independent access to the funds, which can only be spent with the cooperation of any two participants.

Conditions

In the literature on advanced bitcoin operations, an Oracle is a server that provides data about the world to bitcoin contracts.

Currently, contracts based on the most flexible condition are provided: a selected phrase appearing on a selected web page, both chosen by the contract creator, and visible by the receiver.

Protocol

Sender Requirements

• Early Temple API key + secret
• JSON REST client capability
• Signing bitcoin tx (e.g. bitcoind RPC signrawtransaction command)
• Sending bitcoin (e.g. bitcoind RPC sendtoaddress command)

Receiver Requirements

• Optional: JSON REST client capability
• Optional: Bitcoin message signing (e.g. bitcoind RPC signmessage command)

Contract creation flow

Access requires an API key + secret, sent in the x-auth-key and x-auth-secret headers of every request.

The creator, here called Alice, will create and modify a contract resource on the server. Once it is prepared, the server will check the condition periodically. If the condition is satisfied, the funds will be automatically sent to the recipient, here called Bob. If the expiration time arrives before the condition is satisfied, the funds will be automatically refunded to Alice.

This contract creation flow is depicted in the activity diagram below. Click the pink notes in the diagram to view sample JSON.

Alice creates a contract

1. Alice creates a contract object, including the public key and address of both herself and Bob, the amount, a contract name and expiration date, and condition details.
2. Early Temple creates an address for this contract, assigns it a globally unique identifier (GUID), and return a location URI based on the GUID.
3. Alice reads the contract at its URI, to find out its address.
4. Alice sends the expected amount to the contract address.
5. Alice updates the contract with the transaction ID of that send.
6. Early Temple ensures that this transaction contains the expected amount, and if so, creates two potential spend transactions: one forward to the recipient, and one backward that refunds Alice. (These transactions require two signatures, and at this point they don't have any.)
7. Alice reads the contract at its URI, to find out the two potential spend transactions.
8. Alice signs both transactions, and updates the contract with them.

Bob reviews the contract (optional)

If Bob wants to verify the contract before engaging the deal, he gets the contract GUID from Alice.

1. Bob doesn't need his own API key + secret to read the contract. To prove that he is the recipient, he uses bitcoin signing to sign the contract GUID with his address used in the contract, generating a signature.
2. Bob reads the contract at its URI, sending his signature in the x-auth-receiver header.

Early Temple processes the contract

1. Early Temple now waits roughly an hour for Alice's spend transaction to completely confirm.
2. Having confirmed the contract funds, Early Temple will now start checking the contract condition against the expiration date.

Funds get sent

1. If the contract condition becomes true before the expiration date arrives, Early Temple will sign and broadcast the forward transaction, sending the funds to Bob.
2. If the expiration date arrives before the contract condition becomes true, Early Temple will sign and broadcast the backward transaction, sending the funds back to Alice.

Activity

Contact

For technical questions, mail us at tech@.

---