Payment channels - Revision history

Harding: Mention that Poon-Dryja is also called LN-Penalty

2024-11-01T05:37:57Z

Mention that Poon-Dryja is also called LN-Penalty

← Older revision		Revision as of 05:37, 1 November 2024
Line 37:		Line 37:
	=== Poon-Dryja payment channels ===		=== Poon-Dryja payment channels ===

	Poon-Dryja payment channels were presented in the paper<ref name="ln_pdf">[https://lightning.network/lightning-network-paper.pdf Lightning Network paper, v0.5.9.1]<br>Joseph Poon & Thaddeus Dryja<br>''Retrieved 2016-04-10''</ref> that also introduced the [[Lightning Network]]. Channel backing funds are locked into a 2-of-2 multisig, but before the funding transaction is even signed, commitment transactions for each party are first written and signed. As it requires referring to transactions that have not been signed yet, it requires using a transaction format that separates signatures from the part of the transaction that is hashed to generate the txid, such as [[Segregated Witness]].		Poon-Dryja payment channels, also called LN-Penalty<ref name="ln-penalty"/> were presented in the paper<ref name="ln_pdf">[https://lightning.network/lightning-network-paper.pdf Lightning Network paper, v0.5.9.1]<br>Joseph Poon & Thaddeus Dryja<br>''Retrieved 2016-04-10''</ref> that also introduced the [[Lightning Network]]. Channel backing funds are locked into a 2-of-2 multisig, but before the funding transaction is even signed, commitment transactions for each party are first written and signed. As it requires referring to transactions that have not been signed yet, it requires using a transaction format that separates signatures from the part of the transaction that is hashed to generate the txid, such as [[Segregated Witness]].

	Poon-Dryja channels may be closed unilaterally (requires the participation of only one party) or bilaterally (requires the participation of both parties). When closed bilaterally Poon-Dryja channels are indistinguishable on-chain from 2-of-2 multisig address spends. When closed unilaterally, the funds of the party that closed the channel is temporarily timelocked; this allows the other party to dispute the state transmitted by the closing party (who might have given old state on closing).		Poon-Dryja channels may be closed unilaterally (requires the participation of only one party) or bilaterally (requires the participation of both parties). When closed bilaterally Poon-Dryja channels are indistinguishable on-chain from 2-of-2 multisig address spends. When closed unilaterally, the funds of the party that closed the channel is temporarily timelocked; this allows the other party to dispute the state transmitted by the closing party (who might have given old state on closing).
Line 93:		Line 93:

	<ref name="bitcoin_dev_bip65">[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011197.html [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!], Peter Todd, bitcoin-dev mailing list, 27 September 2015</ref>		<ref name="bitcoin_dev_bip65">[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011197.html [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!], Peter Todd, bitcoin-dev mailing list, 27 September 2015</ref>

			<ref name="ln-penalty>[https://blog.blockstream.com/en-eltoo-next-lightning/ Blog post about Eltoo]</ref>
	</references>		</references>

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

MMGen at 07:45, 4 October 2021

2021-10-04T07:45:20Z

← Older revision		Revision as of 07:45, 4 October 2021
Line 1:		Line 1:
	A '''Micropayment Channel''' or '''Payment Channel''' is class of techniques designed to allow users to make multiple Bitcoin transactions without commiting all of the transactions to the Bitcoin block chain.<ref name="bitcoinorg_dev_guide"/> In a typical payment channel, only two transactions are added to the block chain but an unlimited or nearly unlimted number of payments can be made between the participants.		A '''Micropayment Channel''' or '''Payment Channel''' is class of techniques designed to allow users to make multiple Bitcoin transactions without commiting all of the transactions to the Bitcoin block chain.<ref name="bitcoinorg_dev_guide"/> In a typical payment channel, only two transactions are added to the block chain but an unlimited or nearly unlimted number of payments can be made between the participants.

	Several channel designs have been proposed or implemented over the years. This article describes some of them. Many designs are vulnerable to [[Transaction Malleability\|transaction malleability]]. Specifically, many designs require a way to be able to spend an unsigned transaction, in order to ensure that the channel can be opened atomically. Thus, these designs require a malleability fix that separates the signatures from the part of the transaction that is hashed to form the txid. With the introduction of Segwit, the malleability problem has been solved.		Several channel designs have been proposed or implemented over the years. This article describes some of them. Many designs are vulnerable to [[Transaction Malleability\|transaction malleability]]. Specifically, many designs require a way to be able to spend an unsigned transaction, in order to ensure that the channel can be opened atomically. Thus, these designs require a malleability fix that separates the signatures from the part of the transaction that is hashed to form the txid. With the introduction of [[Segwit]], the malleability problem has been solved.

	=== Nakamoto high-frequency transactions ===		=== Nakamoto high-frequency transactions ===

MMGen at 07:44, 4 October 2021

2021-10-04T07:44:24Z

← Older revision		Revision as of 07:44, 4 October 2021
Line 1:		Line 1:
	A '''Micropayment Channel''' or '''Payment Channel''' is class of techniques designed to allow users to make multiple Bitcoin transactions without commiting all of the transactions to the Bitcoin block chain.<ref name="bitcoinorg_dev_guide"/> In a typical payment channel, only two transactions are added to the block chain but an unlimited or nearly unlimted number of payments can be made between the participants.		A '''Micropayment Channel''' or '''Payment Channel''' is class of techniques designed to allow users to make multiple Bitcoin transactions without commiting all of the transactions to the Bitcoin block chain.<ref name="bitcoinorg_dev_guide"/> In a typical payment channel, only two transactions are added to the block chain but an unlimited or nearly unlimted number of payments can be made between the participants.

	Several channel designs have been proposed or implemented over the years. This article describes some of them. Many designs are vulnerable to [[Transaction Malleability\|transaction malleability]]. Specifically, many designs require a way to be able to spend an unsigned transaction, in order to ensure that the channel can be opened atomically. Thus, these designs require a malleability fix that separates the signatures from the part of the transaction that is hashed to form the txid. With the introduction of Segwit, ~~this~~ problem has been solved.		Several channel designs have been proposed or implemented over the years. This article describes some of them. Many designs are vulnerable to [[Transaction Malleability\|transaction malleability]]. Specifically, many designs require a way to be able to spend an unsigned transaction, in order to ensure that the channel can be opened atomically. Thus, these designs require a malleability fix that separates the signatures from the part of the transaction that is hashed to form the txid. With the introduction of Segwit, the malleability problem has been solved.

	=== Nakamoto high-frequency transactions ===		=== Nakamoto high-frequency transactions ===

MMGen at 07:43, 4 October 2021

2021-10-04T07:43:38Z

← Older revision		Revision as of 07:43, 4 October 2021
Line 1:		Line 1:
	A '''Micropayment Channel''' or '''Payment Channel''' is class of techniques designed to allow users to make multiple Bitcoin transactions without commiting all of the transactions to the Bitcoin block chain.<ref name="bitcoinorg_dev_guide"/> In a typical payment channel, only two transactions are added to the block chain but an unlimited or nearly unlimted number of payments can be made between the participants.		A '''Micropayment Channel''' or '''Payment Channel''' is class of techniques designed to allow users to make multiple Bitcoin transactions without commiting all of the transactions to the Bitcoin block chain.<ref name="bitcoinorg_dev_guide"/> In a typical payment channel, only two transactions are added to the block chain but an unlimited or nearly unlimted number of payments can be made between the participants.

	Several channel designs have been proposed or implemented over the years. This article describes some of them. Many designs are vulnerable to [[Transaction Malleability\|transaction malleability]]. Specifically, many designs require a way to be able to spend an unsigned transaction, in order to ensure that the channel can be opened atomically. Thus, these designs require a malleability fix that separates the signatures from the part of the transaction that is hashed to form the txid.		Several channel designs have been proposed or implemented over the years. This article describes some of them. Many designs are vulnerable to [[Transaction Malleability\|transaction malleability]]. Specifically, many designs require a way to be able to spend an unsigned transaction, in order to ensure that the channel can be opened atomically. Thus, these designs require a malleability fix that separates the signatures from the part of the transaction that is hashed to form the txid. With the introduction of Segwit, this problem has been solved.

	=== Nakamoto high-frequency transactions ===		=== Nakamoto high-frequency transactions ===

Rusty: Broken reference URL, fixed

2019-07-18T04:54:20Z

Broken reference URL, fixed

← Older revision		Revision as of 04:54, 18 July 2019
Line 47:		Line 47:
	=== Decker-Wattenhofer duplex payment channels ===		=== Decker-Wattenhofer duplex payment channels ===

	Duplex payment channels were presented in a paper<ref name='duplex_pdf'>[https://~~www.~~tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels] Decker, C.; Wattenhofer, R.</ref> by Christian Decker and Roger Wattenhofer. This type of payment channel requires the new BIP68<ref name='bip68'>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68]</ref> meaning of nSequence. As the name implies, a duplex payment channel is composed of two unidirectional payment channels, one in both directions. The unidirectional payment channels are essentially Spillman channels, but using relative lock time (nSequence) instead of nLockTime.		Duplex payment channels were presented in a paper<ref name='duplex_pdf'>[https://tik-old.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels] Decker, C.; Wattenhofer, R.</ref> by Christian Decker and Roger Wattenhofer. This type of payment channel requires the new BIP68<ref name='bip68'>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68]</ref> meaning of nSequence. As the name implies, a duplex payment channel is composed of two unidirectional payment channels, one in both directions. The unidirectional payment channels are essentially Spillman channels, but using relative lock time (nSequence) instead of nLockTime.

	However, instead of funding unidirectional payment channels directly from an on-chain funding transaction, there is an "invalidation tree" of off-chain transactions between the funding transaction and the payment channel finalization transactions. The invalidation tree transactions also use relative lock time; the first version of the transaction has a large relative lock time, and the next version of the transaction (which ''invalidates'' the first) uses a slightly smaller relative lock time, and so on. There is also a "kick-off" transaction that starts the timeout for the relative locktime. The sequence of transactions is thus: funding -> kickoff -> invalidation tree -> payment channel.		However, instead of funding unidirectional payment channels directly from an on-chain funding transaction, there is an "invalidation tree" of off-chain transactions between the funding transaction and the payment channel finalization transactions. The invalidation tree transactions also use relative lock time; the first version of the transaction has a large relative lock time, and the next version of the transaction (which ''invalidates'' the first) uses a slightly smaller relative lock time, and so on. There is also a "kick-off" transaction that starts the timeout for the relative locktime. The sequence of transactions is thus: funding -> kickoff -> invalidation tree -> payment channel.

Almkglor at 06:07, 2 May 2018

2018-05-02T06:07:44Z

← Older revision		Revision as of 06:07, 2 May 2018
Line 63:		Line 63:
	=== Decker-Russell-Osuntokun eltoo Channels ===		=== Decker-Russell-Osuntokun eltoo Channels ===

	Eltoo channels were presented in a paper<ref name='eltoo_pdf'>[https://blockstream.com/eltoo.pdf eltoo: A Simple Layer2 Protocol for Bitcoin] Decker, C.; Russell, R., Osuntokun, O.</ref> by Christian Decker, Rusty Russell, and Olauluwa Osuntokun in April 30, 2018. This type of channel requires a new <code>SIGHASH_NOINPUT</code><ref name='bip_sighash_noinput'>[https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki <code>SIGHASH_NOINPUT</code>]</ref> signing flag.		Eltoo channels were presented in a paper<ref name='eltoo_pdf'>[https://blockstream.com/eltoo.pdf eltoo: A Simple Layer2 Protocol for Bitcoin] Decker, C.; Russell, R., Osuntokun, O. '''Retrieved 2018-05-02'''</ref> by Christian Decker, Rusty Russell, and Olauluwa Osuntokun in April 30, 2018. This type of channel requires a new <code>SIGHASH_NOINPUT</code><ref name='bip_sighash_noinput'>[https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki <code>SIGHASH_NOINPUT</code>]</ref> signing flag.

	Roughly, each update of the channel requires creating two transactions: an update transaction and a CSV-encumbered settlement transaction that spends the update transaction. Via <code>SIGHASH_NOINPUT</code> and an unusual use of <code>OP_CHECKLOCKTIMEVERIFY</code>, any later update transaction can spend any earlier update transaction during the time that the settlement transaction is encumbered; only the latest update transaction cannot be spent by another update transaction (since it has no later update) and can only be spent by its corresponding settlement transaction after the CSV delay has passed. Thus even if an attacker or disrupter publishes an old update transaction, it cannot get the old state published since the latest transaction can still be published while the CSV-delay on the old settlement transaction hasn't completed yet.		Roughly, each update of the channel requires creating two transactions: an update transaction and a CSV-encumbered settlement transaction that spends the update transaction. Via <code>SIGHASH_NOINPUT</code> and an unusual use of <code>OP_CHECKLOCKTIMEVERIFY</code>, any later update transaction can spend any earlier update transaction during the time that the settlement transaction is encumbered; only the latest update transaction cannot be spent by another update transaction (since it has no later update) and can only be spent by its corresponding settlement transaction after the CSV delay has passed. Thus even if an attacker or disrupter publishes an old update transaction, it cannot get the old state published since the latest transaction can still be published while the CSV-delay on the old settlement transaction hasn't completed yet.

Almkglor: /* Decker-Russell-Osuntokun eltoo Channels */

2018-05-02T06:05:54Z

Decker-Russell-Osuntokun eltoo Channels

← Older revision		Revision as of 06:05, 2 May 2018
Line 66:		Line 66:

	Roughly, each update of the channel requires creating two transactions: an update transaction and a CSV-encumbered settlement transaction that spends the update transaction. Via <code>SIGHASH_NOINPUT</code> and an unusual use of <code>OP_CHECKLOCKTIMEVERIFY</code>, any later update transaction can spend any earlier update transaction during the time that the settlement transaction is encumbered; only the latest update transaction cannot be spent by another update transaction (since it has no later update) and can only be spent by its corresponding settlement transaction after the CSV delay has passed. Thus even if an attacker or disrupter publishes an old update transaction, it cannot get the old state published since the latest transaction can still be published while the CSV-delay on the old settlement transaction hasn't completed yet.		Roughly, each update of the channel requires creating two transactions: an update transaction and a CSV-encumbered settlement transaction that spends the update transaction. Via <code>SIGHASH_NOINPUT</code> and an unusual use of <code>OP_CHECKLOCKTIMEVERIFY</code>, any later update transaction can spend any earlier update transaction during the time that the settlement transaction is encumbered; only the latest update transaction cannot be spent by another update transaction (since it has no later update) and can only be spent by its corresponding settlement transaction after the CSV delay has passed. Thus even if an attacker or disrupter publishes an old update transaction, it cannot get the old state published since the latest transaction can still be published while the CSV-delay on the old settlement transaction hasn't completed yet.

			The <code>OP_CHECKLOCKTIMEVERIFY</code> is not used to enforce a particular future time, but rather to enforce an ordering on the update transactions, such that a later update transaction can spend an earlier update transaction, but not vice versa. This is because <code>OP_CHECKLOCKTIMEVERIFY</code> ensures that the spending transaction has a <code>nLockTime</code> equal to, '''or greater than''', the value specified in the spent output SCRIPT. Each update transaction's output SCRIPT has an "update" branch that allows any update transaction to spend it, as long as that update transaction has a higher <code>nLockTime</code> than it currently has. We use past <code>nLockTime</code> Unix timestamps, which start at 500,000,000 and reach up to about ~1,500,000,000 (somewhat less than the Unix timestamp as of time of writing), giving a limit of about 1,000,000,000 (1 billion) updates. If an old update transaction is spent, it will allow any later update transaction to spend it, thus preventing publication of old settlement transactions.

	This has the advantage of not requiring a punishment branch (unlike Poon-Dryja), simplifying watchtower design and reducing the punishment of accidentally using old state (which would lead to total loss of funds under Poon-Dryja, but will only lead to wasting of fees in Decker-Russell-Osuntokun). However, it requires a new feature in the base blockchain (<code>SIGHASH_NOINPUT</code>).		This has the advantage of not requiring a punishment branch (unlike Poon-Dryja), simplifying watchtower design and reducing the punishment of accidentally using old state (which would lead to total loss of funds under Poon-Dryja, but will only lead to wasting of fees in Decker-Russell-Osuntokun). However, it requires a new feature in the base blockchain (<code>SIGHASH_NOINPUT</code>).

Almkglor: /* Decker-Russell-Osuntokun eltoo Channels */

2018-05-02T05:59:42Z

Decker-Russell-Osuntokun eltoo Channels

← Older revision		Revision as of 05:59, 2 May 2018
Line 65:		Line 65:
	Eltoo channels were presented in a paper<ref name='eltoo_pdf'>[https://blockstream.com/eltoo.pdf eltoo: A Simple Layer2 Protocol for Bitcoin] Decker, C.; Russell, R., Osuntokun, O.</ref> by Christian Decker, Rusty Russell, and Olauluwa Osuntokun in April 30, 2018. This type of channel requires a new <code>SIGHASH_NOINPUT</code><ref name='bip_sighash_noinput'>[https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki <code>SIGHASH_NOINPUT</code>]</ref> signing flag.		Eltoo channels were presented in a paper<ref name='eltoo_pdf'>[https://blockstream.com/eltoo.pdf eltoo: A Simple Layer2 Protocol for Bitcoin] Decker, C.; Russell, R., Osuntokun, O.</ref> by Christian Decker, Rusty Russell, and Olauluwa Osuntokun in April 30, 2018. This type of channel requires a new <code>SIGHASH_NOINPUT</code><ref name='bip_sighash_noinput'>[https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki <code>SIGHASH_NOINPUT</code>]</ref> signing flag.

	Roughly, each update of the channel requires creating two transactions: an update transaction and a CSV-encumbered settlement transaction that spends the update transaction. Via <code>SIGHASH_NOINPUT</code> and an unusual use of <code>OP_CHECKLOCKTIMEVERIFY</code>, any later update transaction can spend any earlier update transaction during the time that the settlement transaction is encumbered; only the latest update transaction cannot be spent by another update transaction (since it has no later update) and can only be spent by its corresponding settlement transaction after the CSV delay has passed. Thus even if an attacker or disrupter publishes an old update transaction, it cannot get the old state published since the latest transaction can still be published while the CSV-delay on the old settlement transaction ~~is still passing~~.		Roughly, each update of the channel requires creating two transactions: an update transaction and a CSV-encumbered settlement transaction that spends the update transaction. Via <code>SIGHASH_NOINPUT</code> and an unusual use of <code>OP_CHECKLOCKTIMEVERIFY</code>, any later update transaction can spend any earlier update transaction during the time that the settlement transaction is encumbered; only the latest update transaction cannot be spent by another update transaction (since it has no later update) and can only be spent by its corresponding settlement transaction after the CSV delay has passed. Thus even if an attacker or disrupter publishes an old update transaction, it cannot get the old state published since the latest transaction can still be published while the CSV-delay on the old settlement transaction hasn't completed yet.

	This has the advantage of not requiring a punishment branch (unlike Poon-Dryja), simplifying watchtower design and reducing the punishment of accidentally using old state (which would lead to total loss of funds under Poon-Dryja, but will only lead to wasting of fees in Decker-Russell-Osuntokun). However, it requires a new feature in the base blockchain (<code>SIGHASH_NOINPUT</code>).		This has the advantage of not requiring a punishment branch (unlike Poon-Dryja), simplifying watchtower design and reducing the punishment of accidentally using old state (which would lead to total loss of funds under Poon-Dryja, but will only lead to wasting of fees in Decker-Russell-Osuntokun). However, it requires a new feature in the base blockchain (<code>SIGHASH_NOINPUT</code>).

Almkglor: eltoo

2018-05-02T03:32:30Z

eltoo

← Older revision		Revision as of 03:32, 2 May 2018
Line 60:		Line 60:

	The invalidation tree structure may actually have more than two participants; it would be possible for groups of 3 or more parties to build multiple payment channels between them that are backed by this invalidation tree structure, and to rebalance their payment channels without hitting the blockchain.<ref name='scaling_funding_pdf'>[https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf Scalable Funding of Bitcoin Micropayment Channel Networks]</ref> It would also be possible for the invalidation tree structure to fund Poon-Dryja rather than pairs of unidirectional payment channels.		The invalidation tree structure may actually have more than two participants; it would be possible for groups of 3 or more parties to build multiple payment channels between them that are backed by this invalidation tree structure, and to rebalance their payment channels without hitting the blockchain.<ref name='scaling_funding_pdf'>[https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf Scalable Funding of Bitcoin Micropayment Channel Networks]</ref> It would also be possible for the invalidation tree structure to fund Poon-Dryja rather than pairs of unidirectional payment channels.

			=== Decker-Russell-Osuntokun eltoo Channels ===

			Eltoo channels were presented in a paper<ref name='eltoo_pdf'>[https://blockstream.com/eltoo.pdf eltoo: A Simple Layer2 Protocol for Bitcoin] Decker, C.; Russell, R., Osuntokun, O.</ref> by Christian Decker, Rusty Russell, and Olauluwa Osuntokun in April 30, 2018. This type of channel requires a new <code>SIGHASH_NOINPUT</code><ref name='bip_sighash_noinput'>[https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki <code>SIGHASH_NOINPUT</code>]</ref> signing flag.

			Roughly, each update of the channel requires creating two transactions: an update transaction and a CSV-encumbered settlement transaction that spends the update transaction. Via <code>SIGHASH_NOINPUT</code> and an unusual use of <code>OP_CHECKLOCKTIMEVERIFY</code>, any later update transaction can spend any earlier update transaction during the time that the settlement transaction is encumbered; only the latest update transaction cannot be spent by another update transaction (since it has no later update) and can only be spent by its corresponding settlement transaction after the CSV delay has passed. Thus even if an attacker or disrupter publishes an old update transaction, it cannot get the old state published since the latest transaction can still be published while the CSV-delay on the old settlement transaction is still passing.

			This has the advantage of not requiring a punishment branch (unlike Poon-Dryja), simplifying watchtower design and reducing the punishment of accidentally using old state (which would lead to total loss of funds under Poon-Dryja, but will only lead to wasting of fees in Decker-Russell-Osuntokun). However, it requires a new feature in the base blockchain (<code>SIGHASH_NOINPUT</code>).

	=== Hashed Time-Locked Contracts (HTLCs) ===		=== Hashed Time-Locked Contracts (HTLCs) ===

Belcher: added to catagory technical

2017-11-26T10:55:04Z

added to catagory technical

← Older revision		Revision as of 10:55, 26 November 2017
Line 84:		Line 84:
	<ref name="bitcoin_dev_bip65">[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011197.html [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!], Peter Todd, bitcoin-dev mailing list, 27 September 2015</ref>		<ref name="bitcoin_dev_bip65">[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011197.html [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!], Peter Todd, bitcoin-dev mailing list, 27 September 2015</ref>
	</references>		</references>

			[[Category:Technical]]