Hashed Timelock Contracts

From zaoniao
Jump to navigation Jump to search

Hashed TimeLock Contract or HTLC is a class of payments that use hashlocks and timelocks to require that the receiver of a payment either acknowledge receiving the payment prior to a deadline by generating cryptographic proof of payment or forfeit the ability to claim the payment, returning it to the payer.[1]

The cryptographic proof of payment the receiver generates can then be used to trigger other actions in other payments, making HTLCs a powerful technique for producing conditional payments in Bitcoin.

This implementation of Hashed Timelock Contracts as part of atomic cross-chain trading goes by the name of HTLC. It is also possible to use HTLC in payment channels moving forward. Even though payment channels use timelocks by default, they can be “extended” with hashlocks. As a result, one would be able to route [Bitcoin] payments through two or more payment channels.

All of this sounds great and exciting, but there is a secondary aspect to Hashed Timelock Contracts when it comes to cryptocurrency payments. This technology also allows the recipient of a payment to forfeit the ability to claim the pending transfer. In doing so, they will effectively return the money to the sender. Up until now, that seemed very improbable where bitcoin is concerned, although it could prove to be quite useful in the long run.

In the end, it is not hard to see why developers are excited about Hashed Timelock Contracts. The opportunities for this technological feature are virtually limitless, and it is an area of development well worth exploring further. Conditional payments can be quite beneficial to cryptocurrency as a whole in the future.

Description

Advanced Bitcoin Scripting -- Part 1: Transactions & Multisig

Hashed Timelocked Contracts (HTLC) are a well-known and simple technique for building protocols for atomic swaps. They allow you to pay another party for some information (generally, a key) with a condition that allows you to receive your money back if the party does not cooperate.

HTLCs are a fundamental tool in the Lightning network, in zero-knowledge contingent payments (ZKCP) like the one we performed last year at FC’16, and in our XCAT project that we announced last month. One of the first steps forward is the inclusion of general HTLC functionality in the Bitcoin Core wallet.

Hashed-Timelock Agreements (HTLAs)

A contract is a certain type of agreement that is enforced by a third party. Hashed-Timelock Agreements (HTLAs) generalize the idea of HTLCs to include agreements that are enforced by a ledger. The principle has been in use in Interledger since the project was started but the HTLA term was proposed more recently in this thread on the Interledger mailing list. HTLAs enable secure Interledger payments through all types of ledgers, including those that do not support conditional transfers[2].

HTLCs in cross-chain atomic swaps

Atomic cross-chain trading allows some amount of one cryptocurrency (such as bitcoin on mainnet) to be traded for some amount of cryptocurrency on another block chain (such as bitcoin on a sidechain)[1].

Descriptions of cross-chain atomic swaps are probably the origin of the technique now called HTLCs.

HTLCs in payment channels

Payment channels already use timelocks, and it can be relatively simple conceptually to extend them with hashlocks. This provides the useful benefit of making payments routable across two or more payment channels.

Example

  1. Alice opens a payment channel to Bob, and Bob opens a payment channel to Charlie.
  2. Alice wants to buy something from Charlie for 1000 satoshis.
  3. Charlie generates a random number and generates its SHA-256 hash. Charlie gives that hash to Alice.
  4. Alice uses her payment channel to Bob to pay him 1,000 satoshis, but she adds the hash Charlie gave her to the payment along with an extra condition: in order for Bob to claim the payment, he has to provide the data which was used to produce that hash.
  5. Bob uses his payment channel to Charlie to pay Charlie 1,000 satoshis, and Bob adds a copy of the same condition that Alice put on the payment she gave Bob.
  6. Charlie has the original data that was used to produce the hash (called a pre-image), so Charlie can use it to finalize his payment and fully receive the payment from Bob. By doing so, Charlie necessarily makes the pre-image available to Bob.
  7. Bob uses the pre-image to finalize his payment from Alice

External links

See also

References