Payment channels: Difference between revisions
m s/Hash/Hashed/ in HTLC |
m Link to Hashed Timelock Contracts and re-arrange references for easier editing |
||
| 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 | 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. | Several channel designs have been proposed or implemented over the years. This article describes some of them. | ||
| Line 5: | Line 5: | ||
=== Nakamoto high-frequency transactions === | === Nakamoto high-frequency transactions === | ||
Implemented in Bitcoin 0.1 were features such as [[Transaction Replacement|transaction replacement]]<ref | Implemented in Bitcoin 0.1 were features such as [[Transaction Replacement|transaction replacement]]<ref name="replacement_in_original_code" />, input sequence numbers (nSequence), and [[nLockTime]] that would allow two or more parties to repeatedly update the state of an unconfirmed transaction prior to it becoming confirmed. | ||
Satoshi Nakamoto described the technique to a Bitcoin developer in a personal email:<ref | Satoshi Nakamoto described the technique to a Bitcoin developer in a personal email:<ref name="hearn_hft_quote" /> | ||
<blockquote> | <blockquote> | ||
| Line 21: | Line 21: | ||
=== Spillman-style payment channels=== | === Spillman-style payment channels=== | ||
Discussed on the bitcoin-development mailing list<ref | Discussed on the bitcoin-development mailing list<ref name="spillman_channel_description"/> and implemented in BitcoinJ,<ref name="channels_bitcoinj"/> this one transaction to create a secured deposit and a second transaction to release the deposit funds in the manner agreed to by both parties, preventing miners from being able to commit a non-final version of the transaction. However, opening a channel in the Spillman model exposed the depositor to malleability risk where the counter party would be able to hold the depositor's funds hostage.<ref name="bip65"/> | ||
=== CLTV-style payment channels === | === CLTV-style payment channels === | ||
Were made possible in Decemember 2015 by the activation of the CLTV soft fork{{citation needed}} after discussion that began in the #bitcoin-wizards IRC channel{{citation needed}}, moved to the bitcoin-development and bitcoin-dev mailing lists<ref | Were made possible in Decemember 2015 by the activation of the CLTV soft fork{{citation needed}} after discussion that began in the #bitcoin-wizards IRC channel{{citation needed}}, moved to the bitcoin-development and bitcoin-dev mailing lists<ref name="bitcoin_dev_bip65"/>, and included a design specification in [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65]. Channels constructed using the new OP_CLTV opcode were resistant to the malleability problem inherient in the Spillman-style construction.<ref name="bip65" /> | ||
=== Hashed Time-Locked Contracts (HTLCs) === | === Hashed Time-Locked Contracts (HTLCs) === | ||
''Full article: [[Hashed Timelock Contracts]]'' | |||
A technique that can allow payments to be securely routed across multiple payment channels.{{citation needed}} For example, if Alice has a channel open to Bob and Bob has a channel open to Charlie, Alice can use a HTLC to pay Charlie through Bob without any risk of Bob stealing the payment in transit. HTLCs are integral to the design of more advanced payment channels such as those used by the [[Lightning Network]]. | A technique that can allow payments to be securely routed across multiple payment channels.{{citation needed}} For example, if Alice has a channel open to Bob and Bob has a channel open to Charlie, Alice can use a HTLC to pay Charlie through Bob without any risk of Bob stealing the payment in transit. HTLCs are integral to the design of more advanced payment channels such as those used by the [[Lightning Network]]. | ||
=== References === | === References === | ||
<references> | |||
<ref name="bitcoinorg_dev_guide">[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channel], Bitcoin.org Developer Guide</ref> | |||
<ref name="replacement_in_original_code">[https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp#L434 Replacement in original Bitcoin code]<br>Satoshi Nakamoto, GitHub</ref> | |||
<ref name="hearn_hft_quote">[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002417.html Anti DoS for tx replacement], Mike Hearn, bitcoin-development mailing list, 17 April 2013</ref> | |||
<ref name="spillman_channel_description">[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Re: Anti DoS for tx replacement], Jeremy Spillman, bitcoin-development mailing list, 20 April 2013</ref> | |||
<ref name="channels_bitcoinj">[https://bitcointalk.org/index.php?topic=244656.0 Micro-payment channels implementation now in bitcoinj], Mike Hearn & Matt Corallo, BitcoinTalk.org, 27 June 2013</ref> | |||
<ref name="bip65">[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65], Peter Todd, BIPs repository, retrieved 28 October 2016</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> | |||
Revision as of 18:19, 6 November 2016
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.[1] 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.
Nakamoto high-frequency transactions
Implemented in Bitcoin 0.1 were features such as transaction replacement[2], input sequence numbers (nSequence), and nLockTime that would allow two or more parties to repeatedly update the state of an unconfirmed transaction prior to it becoming confirmed.
Satoshi Nakamoto described the technique to a Bitcoin developer in a personal email:[3]
An unrecorded open transaction can keep being replaced until nLockTime. It may contain payments by multiple parties. Each input owner signs their input. For a new version to be written, each must sign a higher sequence number (see IsNewerThan). By signing, an input owner says "I agree to put my money in, if everyone puts their money in and the outputs are this." There are other options in SignatureHash such as SIGHASH_SINGLE which means "I agree, as long as this one output (i.e. mine) is what I want, I don't care what you do with the other outputs.". If that's written with a high nSequenceNumber, the party can bow out of the negotiation except for that one stipulation, or sign SIGHASH_NONE and bow out completely.
The parties could create a pre-agreed default option by creating a higher nSequenceNumber tx using OP_CHECKMULTISIG that requires a subset of parties to sign to complete the signature. The parties hold this tx in reserve and if need be, pass it around until it has enough signatures.
One use of nLockTime is high frequency trades between a set of parties. They can keep updating a tx by unanimous agreement. The party giving money would be the first to sign the next version. If one party stops agreeing to changes, then the last state will be recorded at nLockTime. If desired, a default transaction can be prepared after each version so n-1 parties can push an unresponsive party out. Intermediate transactions do not need to be broadcast. Only the final outcome gets recorded by the network. Just before nLockTime, the parties and a few witness nodes broadcast the highest sequence tx they saw.
This design was not secure:[citation needed] one party could collude with a miner to commit a non-final version of the transaction, possibly stealing funds from the other party or parties.
Spillman-style payment channels
Discussed on the bitcoin-development mailing list[4] and implemented in BitcoinJ,[5] this one transaction to create a secured deposit and a second transaction to release the deposit funds in the manner agreed to by both parties, preventing miners from being able to commit a non-final version of the transaction. However, opening a channel in the Spillman model exposed the depositor to malleability risk where the counter party would be able to hold the depositor's funds hostage.[6]
CLTV-style payment channels
Were made possible in Decemember 2015 by the activation of the CLTV soft fork[citation needed] after discussion that began in the #bitcoin-wizards IRC channel[citation needed], moved to the bitcoin-development and bitcoin-dev mailing lists[7], and included a design specification in BIP65. Channels constructed using the new OP_CLTV opcode were resistant to the malleability problem inherient in the Spillman-style construction.[6]
Hashed Time-Locked Contracts (HTLCs)
Full article: Hashed Timelock Contracts
A technique that can allow payments to be securely routed across multiple payment channels.[citation needed] For example, if Alice has a channel open to Bob and Bob has a channel open to Charlie, Alice can use a HTLC to pay Charlie through Bob without any risk of Bob stealing the payment in transit. HTLCs are integral to the design of more advanced payment channels such as those used by the Lightning Network.
References
- ↑ Micropayment channel, Bitcoin.org Developer Guide
- ↑ Replacement in original Bitcoin code
Satoshi Nakamoto, GitHub - ↑ Anti DoS for tx replacement, Mike Hearn, bitcoin-development mailing list, 17 April 2013
- ↑ Re: Anti DoS for tx replacement, Jeremy Spillman, bitcoin-development mailing list, 20 April 2013
- ↑ Micro-payment channels implementation now in bitcoinj, Mike Hearn & Matt Corallo, BitcoinTalk.org, 27 June 2013
- ↑ 6.0 6.1 BIP65, Peter Todd, BIPs repository, retrieved 28 October 2016
- ↑ [bitcoin-dev Let's deploy BIP65 CHECKLOCKTIMEVERIFY!], Peter Todd, bitcoin-dev mailing list, 27 September 2015