Early Temple Developer’s Sandbox
This is the developer's sandbox for Early Temple. It is connected to the bitcoin testnet. Early Temple is an API for creating smart contracts, which transfer Bitcoin based on a preset condition.
Get API key
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
- 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.
- Early Temple creates an address for this contract, assigns it a globally unique identifier (GUID), and
return a location URI based on the GUID.
- Alice reads the contract at its URI, to find out its address.
- Alice sends the expected amount to the contract address.
- Alice updates the contract with the transaction ID of that send.
- 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.)
- Alice reads the contract at its URI, to find out the two potential spend transactions.
- 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.
- 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.
- Bob reads the contract at its URI, sending his signature in the
x-auth-receiver
header.
Early Temple processes the contract
- Early Temple now waits roughly an hour for Alice's spend transaction to completely confirm.
- Having confirmed the contract funds, Early Temple will now start checking the contract condition against
the expiration date.
Funds get sent
- 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.
- 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@
.