Hash Time Locked Contracts - Revision history

MMGen: /* HTLCs in payment channels */

2021-10-04T07:30:24Z

HTLCs in payment channels

← Older revision		Revision as of 07:30, 4 October 2021
Line 17:		Line 17:

	# Alice opens a payment channel to Bob, and Bob opens a payment channel to Charlie.		# Alice opens a payment channel to Bob, and Bob opens a payment channel to Charlie.
	# Alice wants to buy something from Charlie for ~~1000~~ satoshis.		# Alice wants to buy something from Charlie for 1,000 satoshis.
	# Charlie generates a random number and generates its SHA256 hash. Charlie gives that hash to Alice.		# Charlie generates a random number and generates its SHA256 hash. Charlie gives that hash to Alice.
	# 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.		# 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.

Darosior at 18:02, 23 September 2019

2019-09-23T18:02:29Z

← Older revision		Revision as of 18:02, 23 September 2019
Line 12:		Line 12:
	== HTLCs in payment channels ==		== 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.		[[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, as done in the Lightning Network <ref name="lightning_network_htlc"/>.

	=== Example ===		=== Example ===
Line 27:		Line 27:
	<references>		<references>
	<ref name="russell_htlc">[https://rusty.ozlabs.org/?p=462 Lightning Networks Part II: Hashed Timelock Contracts (HTLCs)]</ref>		<ref name="russell_htlc">[https://rusty.ozlabs.org/?p=462 Lightning Networks Part II: Hashed Timelock Contracts (HTLCs)]</ref>
	<ref name="lightning_network_htlc">[https://lightning.network/lightning-network-paper.pdf#page=30]</ref>		<ref name="lightning_network_htlc">[https://lightning.network/lightning-network-paper.pdf#page=30 Hashed Timelock Contract (HTLC) in the Lightning Network paper]</ref>
	</references>		</references>

	[[Category:Technical]]		[[Category:Technical]]

Darosior: Add a reference to the Lightning Network paper

2019-09-23T17:59:45Z

Add a reference to the Lightning Network paper

← Older revision		Revision as of 17:59, 23 September 2019
Line 27:		Line 27:
	<references>		<references>
	<ref name="russell_htlc">[https://rusty.ozlabs.org/?p=462 Lightning Networks Part II: Hashed Timelock Contracts (HTLCs)]</ref>		<ref name="russell_htlc">[https://rusty.ozlabs.org/?p=462 Lightning Networks Part II: Hashed Timelock Contracts (HTLCs)]</ref>
			<ref name="lightning_network_htlc">[https://lightning.network/lightning-network-paper.pdf#page=30]</ref>
	</references>		</references>

	[[Category:Technical]]		[[Category:Technical]]

Belcher: Rename in introduction to go with page move

2019-01-29T14:36:34Z

Rename in introduction to go with page move

← Older revision		Revision as of 14:36, 29 January 2019
Line 1:		Line 1:
	A '''~~Hashed TimeLock~~ Contract''' or '''HTLC''' is a class of payments that use [[hashlock]]s and [[timelock]]s 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.<ref name="russell_htlc" />		A '''Hash Time Locked Contract''' or '''HTLC''' is a class of payments that use [[hashlock]]s and [[timelock]]s 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.<ref name="russell_htlc" />

	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		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

Belcher: Belcher moved page Hashed Timelock Contracts to Hash Time Locked Contracts: Earlier name made it sound like they are a timelock contract that is hashed

2019-01-29T14:35:09Z

Belcher moved page Hashed Timelock Contracts to Hash Time Locked Contracts: Earlier name made it sound like they are a timelock contract that is hashed

← Older revision	Revision as of 14:35, 29 January 2019
(No difference)

Belcher: Fixed references tag and added category technical

2018-11-30T02:07:12Z

Fixed references tag and added category technical

← Older revision		Revision as of 02:07, 30 November 2018
Line 26:		Line 26:
	== References ==		== References ==
	<references>		<references>
	<ref name="russell_htlc">[https://rusty.ozlabs.org/?p=462 Lightning Networks Part II: Hashed Timelock Contracts (HTLCs)]		<ref name="russell_htlc">[https://rusty.ozlabs.org/?p=462 Lightning Networks Part II: Hashed Timelock Contracts (HTLCs)]</ref>
	</references>		</references>

			[[Category:Technical]]

Gunar: Fix: Bob -> Charlie

2017-09-26T21:20:23Z

Fix: Bob -> Charlie

← Older revision		Revision as of 21:20, 26 September 2017
Line 19:		Line 19:
	# Alice wants to buy something from Charlie for 1000 satoshis.		# Alice wants to buy something from Charlie for 1000 satoshis.
	# Charlie generates a random number and generates its SHA256 hash. Charlie gives that hash to Alice.		# Charlie generates a random number and generates its SHA256 hash. Charlie gives that hash to Alice.
	# Alice uses her payment channel to Bob to pay him 1,000 satoshis, but she adds the hash ~~Bob~~ 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.		# 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.
	# 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.		# 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.
	# 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.		# 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.

Harding: Link to hashlocks and timelocks

2016-11-07T19:08:16Z

Link to hashlocks and timelocks

← Older revision		Revision as of 19:08, 7 November 2016
Line 1:		Line 1:
	A '''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.<ref name="russell_htlc" />		A '''Hashed TimeLock Contract''' or '''HTLC''' is a class of payments that use [[hashlock]]s and [[timelock]]s 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.<ref name="russell_htlc" />

	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		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

Harding: Created page.

2016-11-06T18:03:50Z

Created page.

New page

A '''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.<ref name="russell_htlc" />

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.

== 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]]).

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

== 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 ===

# Alice opens a payment channel to Bob, and Bob opens a payment channel to Charlie.
# Alice wants to buy something from Charlie for 1000 satoshis.
# Charlie generates a random number and generates its SHA256 hash. Charlie gives that hash to Alice.
# Alice uses her payment channel to Bob to pay him 1,000 satoshis, but she adds the hash Bob 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.
# 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.
# 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.
# Bob uses the pre-image to finalize his payment from Alice

== References ==
<references>
<ref name="russell_htlc">[https://rusty.ozlabs.org/?p=462 Lightning Networks Part II: Hashed Timelock Contracts (HTLCs)]
</references>