Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
New BSIP: Hashed Time-Locked Contract #103
Please provide comments within PR #104
Current version of BSIP44 draft:
This BSIP describes an implementation of a Hashed Time-Locked Contract (HTLC) operation.
The ability to securely hold tokenized assets within a hashed time-locked contract on the BitShares blockchain is a desirable feature that could be used by many persons, services, and businesses to mitigate risks between participants during asset transfer. HTLC implement conditional transfers, whereby a designated party (the "recipient") will reveal the preimage of a hash in order to execute the asset transfers from a second party (the "depositor"), else after time lock expiry "depositor" may retrieve their assets. No third-party escrow agent is required, rather the HTLC operation enforces conditions, evaluations and transfers through the BitShares consensus protocol.
Elements of a Hashed Time-Locked Contract (HTLC)
An HTLC is defined to have the following components:
Two parties must be defined within each HTLC: the
An HTLC involves a conditional transfer of the defined
There are two competing conditions within an HTLC, the
The HTLC contains a
If a satisfactory
Note: we recommend the Committee the set maximum allowable
Upon presentation of a
If all evaluations succeed, the
Timing of Condition Evaluation
Note: we recommend the Committee set the maximum value for
Early Termination of an HTLC
To protect the
Automatic Transfers Upon Expiry
Upon expiry of the
We propose three (3) operations (see Specification) to implement the HTLC feature, each requiring distinct fees. All fees will be set and maintained by the Committee.
The "prepare" operation will store in-memory data on validation nodes until redeemed or expiry. We recommend the
The "redeem" operation frees most of the memory from the validation nodes and adds the
The "extend expiry" operation will update the
Existing Escrow Proposals
This section describes various escrow concepts that have been proposed either for BitShares or for other blockchains or services in terms of the elements that have been defined above. This is intended to provide some background and comparison to the concepts that follow.
A separate BSIP [cite] is currently being discussed that provides a more traditional escrow service. This involves parties, agents, and a more complex evaluation. HTLC shares some similarities, and could be considered a thin subset of BitShares Escrow.
The smaller, well-defined nature of HTLC provides a major advantage for applications that want to attempt tasks such as cross chain atomic swaps.
Scorum Atomic Swap
BitShares Multi-Signature Account
One of the existing features of BitShares is the ability to have an account that requires multiples signatures by differently authorized parties [cite] and even hierarchical authorizations. Using this mechanism as a form of escrow is possible. But there are many limitations. More information on escrow and multi-signatures can be found in the BitShares Escrow BSIP [cite].
One of the existing features of BitShares is the ability to have a proposal that is recorded on the blockchain and awaits the authorization of the requisite parties (e.g. M-of-N signatures) to execute. However, the proposal does not "lock" any assets, so the transfer will fail if the sending account lacks sufficient funds during validation. If the required authorizations are not given by proposal expiry, then no transfer will occur. This feature also contains many limitations when compared to HTLC.
Possible Concepts to Implement
The following will describe possible concepts that could be implemented within the BitShares protocol.
Two parties may agree on a swap of two distinct
Alice begins by generating a distinct
Bob queries the blockchain for the
Alice now examines the HTLC Bob created, ensuring the
Bob can now observe the
Similar to the set-price swap mentioned above, two parties may exchange tokens between distinct blockchains when both implement HTLC support. Bitcoin, Litecoin and many others support HTLC [cite].
Alice and Bob intend to swap BTC (bitcoin token) and BTS (BitShares token). This will require both parties to define both a BTC deposit address and BTS deposit account. These addresses/accounts will be exchanged between the parties.
Alice will initiate the first leg of the swap on the BitShares Network with her HTLC and Bob will follow up on the Bitcoin Network with his HTLC. Allice generates a distinct
Bob queries the BitShares Network for the
Alice now examines the HTLC Bob created on the Bitcoin Network, ensuring the
Bob has now observed the
At Expiry (evaluated at each block commit)
Summary for Tokenholders
Hashed Timelock Contracts (HTLCs) enable conditional transfers, whereby distinct account holders may transfer tokens from one account (
A typical scenario involves “Alice” and “Bob” each having accounts on the BitShares Network and addresses on the Bitcoin Network willing to trade their tokens. Alice will begin by creating an HTLC on BitShares to transfer BTS tokens from account
This document is placed in the public domain.
A description of Hashed Timelock Contracts