Bitcoin Wiki - User contributions [en]

ECDH address

2019-04-20T05:09:01Z

Almkglor: Fix obvious typo

ECDH addresses are also called ''stealth addresses'', ''reusable payment codes'', ''reusable addresses'' or ''paynyms''. Elliptic-curve Diffie–Hellman (ECDH) is a key agreement protocol that allows two parties to establish a shared secret over an insecure channel. For example, Alice and Bob can communicate cryptographic information between themselves and agree on a shared secret, Eve the eavesdropper can see _all_ their messages and yet still will not be able to calculate the shared secret.

The concept can be used in a bitcoin context by having the receiver of bitcoin publish some ECDH-information which the sender can use to calculate a shared secret. This shared secret becomes a bitcoin [[address]] which the sender sends money to. The receiver can calculate the corresponding [[private key]] to have access to the money.

== How it works (single key) ==

Lowercase symbols refer to numbers, uppercase symbols refer to elliptic curve points. <code>a.B</code> refers to point multiplication of <code>a</code> and <code>B</code>. <code>G</code> is the [[Secp256k1]] generator point. <code>H(x)</code> means the hash (e.g. SHA256) of value X.

q = ECDH address privkey (generated by receiver)
Q = q.G = ECDH address pubkey (published by receiver)

p = nonce (generated by sender)
P = p.G = nonce point (sent from sender to receiver)

p.Q = q.P = p.q.G (ECDH shared secret point, known by sender and receiver but not eavesdroppers)
c = H(p.Q) = H(q.P) (tweak, shared secret point converted to number)

sender calculates:
Q' = Q + c.G (bitcoin pubkey, send coins here)

receiver calculates:
Q' = Q + c.G = (q + c).G (bitcoin pubkey, watch for incoming coins)
q' = q + c (bitcoin privkey, for spending incoming coins)

== Dual-key ECDH address ==

Another way of creating a ECDH address system is to have two receiver keypairs. One key has the power to spend the money (spend key) and the other key is for searching (scan key). Then the scan key can be sent to a third-party server to outsource the scanning. The server won't be able to steal any money because it doesn't have the spend key. Needless to say this method is not good for privacy because the server can see track all the transactions on the ECDH address.

== Transmitting the nonce point ==

A tricky part of the ECDH scheme is transmitting the nonce point <code>P</code> from sender to receiver. There are a few different methods for this:

# Embedding the nonce point in a [[OP_RETURN]] output. This requires the receiver to scan all blocks for check for OP_RETURN outputs and corresponding ECDH payments. It also uses extra block space, and allows estimation of how many ECDH transactions have happened.
# Embedding the nonce point in an [[ECDSA]] signature. This requires the receiver to scan all blocks for check for ECDH payments. It also damages fungibility slightly by only allowing coins protected by [[ECDSA]] to be sent via ECDH.
# Delegation of scanning to a third-party server (see above, Dual-key ECDH address). Ruins privacy as the server can track everything.
# Embedding the nonce point in an extra transaction (in [[OP_RETURN]]) sent to a fixed address belonging to the receiver. This allows the receiver to outsource scanning to a server which watches the fixed address. The server can count the number of ECDH transactions but not easily track their amount, source or destination. This also uses extra block space.
# Sending the nonce-point out-of-band (by email, for example). Requires an extra step of interactivity, and damages user-friendlyness.

ECDH addresses therefore require either a costly scan process of the entire blockchain, delegation to a third-party server which can spy on transactions, an extra step of interactivity or using the blockchain as a messaging medium.

== Privacy ==

ECDH addresses improve privacy by making it easier to avoid [[address reuse]]. An adversary can see the ECDH donation address but won't be able to easily find any [[transaction]]s spending to and from it. ECDH addresses are very closely equivalent to [[Receiving_donations_with_bitcoin#Improving_privacy_by_avoiding_address_re-use|running a http website which hands out bitcoin addresses to anybody who wants to donate]] except without an added step of interactivity.

However [[ECDH address]]es do not solve all privacy problems as they are still vulnerable to [[Privacy#Mystery_shopper_payment|mystery shopper payments]]; an adversary can donate some bitcoins and watch on the blockchain to see where they go afterwards, using heuristics like the [[common-input-ownership heuristic]] to obtain more information such as donation volume and final destination of funds.

Historically it has been very hard and slow to get the bitcoin ecosystem to adopt a new address type.

== BIP47 ==

[https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki BIP47] is a standard for ECDH address (the BIP calls them ''Reusable Payment Codes''). It transmits the nonce in an extra transaction with a [[OP_RETURN]] output.

The comments on the BIP47 document unanimously discourage its implementation<ref>https://github.com/bitcoin/bips/wiki/Comments:BIP-0047</ref>

== See also ==

* [[Privacy]]

[[Category:Privacy]]

Payment channels

2018-05-02T06:07:44Z

Almkglor:

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.

=== Nakamoto high-frequency transactions ===

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 name="hearn_hft_quote" />

<blockquote>
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.
</blockquote>

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

A full description of the protocol is in [[Contract#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party|example 7 of the Contract page]].

Spillman payment channels are unidirectional (there is a payer and a payee, and it is not possible to transfer money back in the reverse direction).

Spillman payment channels expire after a specific time, and the receiver needs to close the channel before the expiration.

=== 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 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 inherent in the Spillman-style construction.<ref name="bip65" />

Like Spillman payment channels, CLTV-style payment channels are unidirectional and expire after a specific time.

=== 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] Joseph Poon & Thaddeus Dryja ''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 payment channels have indefinite lifetime. They are also bidirectional, unlike Spilman and CLTV payment channels.

The [https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md Lightning BOLT] specifications include recommended implementation of Poon-Dryja 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.

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.

Initially, the invalidation transaction may have a relative lock time of 100 days, and then its outputs go to two unidirectional payment channels, one in either direction. Both parties may then use the payment channels until one channel is exhausted. The parties may then reset the payment channels, creating a new invalidation transaction with a relative lock time of 99 days that redistributes the money correctly, but with the unidirectional payment channels reset.

The payment channel may be closed at any time by either party (without the help of the other) by broadcasting the kickoff transaction on the blockchain. In case of such a unilateral close, both parties must wait out the relative lock times until they can broadcast the payment channel finalization transactions.

Parties should prefer the bilateral (cooperative) close, which collapses the kickoff, invalidation tree, and payment channel transactions into a single simple transaction that pays out the funds to both parties.

Duplex payment channels have indefinite lifetime, but there is a limit on number of updates possible due to the invalidation tree. This limit can be multiplied by adding additional layers to the invalidation tree, with resetting of the lower layers. Finally, in case of a unilateral close duplex payment channels require significant wait times and significant number of transactions to be published on the blockchain.

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

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

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

[[Category:Technical]]

Payment channels

2018-05-02T06:05:54Z

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

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.

=== Nakamoto high-frequency transactions ===

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 name="hearn_hft_quote" />

<blockquote>
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.
</blockquote>

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

A full description of the protocol is in [[Contract#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party|example 7 of the Contract page]].

Spillman payment channels are unidirectional (there is a payer and a payee, and it is not possible to transfer money back in the reverse direction).

Spillman payment channels expire after a specific time, and the receiver needs to close the channel before the expiration.

=== 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 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 inherent in the Spillman-style construction.<ref name="bip65" />

Like Spillman payment channels, CLTV-style payment channels are unidirectional and expire after a specific time.

=== 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] Joseph Poon & Thaddeus Dryja ''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 payment channels have indefinite lifetime. They are also bidirectional, unlike Spilman and CLTV payment channels.

The [https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md Lightning BOLT] specifications include recommended implementation of Poon-Dryja 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.

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.

Initially, the invalidation transaction may have a relative lock time of 100 days, and then its outputs go to two unidirectional payment channels, one in either direction. Both parties may then use the payment channels until one channel is exhausted. The parties may then reset the payment channels, creating a new invalidation transaction with a relative lock time of 99 days that redistributes the money correctly, but with the unidirectional payment channels reset.

The payment channel may be closed at any time by either party (without the help of the other) by broadcasting the kickoff transaction on the blockchain. In case of such a unilateral close, both parties must wait out the relative lock times until they can broadcast the payment channel finalization transactions.

Parties should prefer the bilateral (cooperative) close, which collapses the kickoff, invalidation tree, and payment channel transactions into a single simple transaction that pays out the funds to both parties.

Duplex payment channels have indefinite lifetime, but there is a limit on number of updates possible due to the invalidation tree. This limit can be multiplied by adding additional layers to the invalidation tree, with resetting of the lower layers. Finally, in case of a unilateral close duplex payment channels require significant wait times and significant number of transactions to be published on the blockchain.

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

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

[[Category:Technical]]

Payment channels

2018-05-02T05:59:42Z

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

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.

=== Nakamoto high-frequency transactions ===

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 name="hearn_hft_quote" />

<blockquote>
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.
</blockquote>

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

A full description of the protocol is in [[Contract#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party|example 7 of the Contract page]].

Spillman payment channels are unidirectional (there is a payer and a payee, and it is not possible to transfer money back in the reverse direction).

Spillman payment channels expire after a specific time, and the receiver needs to close the channel before the expiration.

=== 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 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 inherent in the Spillman-style construction.<ref name="bip65" />

Like Spillman payment channels, CLTV-style payment channels are unidirectional and expire after a specific time.

=== 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] Joseph Poon & Thaddeus Dryja ''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 payment channels have indefinite lifetime. They are also bidirectional, unlike Spilman and CLTV payment channels.

The [https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md Lightning BOLT] specifications include recommended implementation of Poon-Dryja 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.

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.

Initially, the invalidation transaction may have a relative lock time of 100 days, and then its outputs go to two unidirectional payment channels, one in either direction. Both parties may then use the payment channels until one channel is exhausted. The parties may then reset the payment channels, creating a new invalidation transaction with a relative lock time of 99 days that redistributes the money correctly, but with the unidirectional payment channels reset.

The payment channel may be closed at any time by either party (without the help of the other) by broadcasting the kickoff transaction on the blockchain. In case of such a unilateral close, both parties must wait out the relative lock times until they can broadcast the payment channel finalization transactions.

Parties should prefer the bilateral (cooperative) close, which collapses the kickoff, invalidation tree, and payment channel transactions into a single simple transaction that pays out the funds to both parties.

Duplex payment channels have indefinite lifetime, but there is a limit on number of updates possible due to the invalidation tree. This limit can be multiplied by adding additional layers to the invalidation tree, with resetting of the lower layers. Finally, in case of a unilateral close duplex payment channels require significant wait times and significant number of transactions to be published on the blockchain.

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

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

[[Category:Technical]]

Payment channels

2018-05-02T03:32:30Z

Almkglor: eltoo

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.

=== Nakamoto high-frequency transactions ===

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 name="hearn_hft_quote" />

<blockquote>
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.
</blockquote>

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

A full description of the protocol is in [[Contract#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party|example 7 of the Contract page]].

Spillman payment channels are unidirectional (there is a payer and a payee, and it is not possible to transfer money back in the reverse direction).

Spillman payment channels expire after a specific time, and the receiver needs to close the channel before the expiration.

=== 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 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 inherent in the Spillman-style construction.<ref name="bip65" />

Like Spillman payment channels, CLTV-style payment channels are unidirectional and expire after a specific time.

=== 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] Joseph Poon & Thaddeus Dryja ''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 payment channels have indefinite lifetime. They are also bidirectional, unlike Spilman and CLTV payment channels.

The [https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md Lightning BOLT] specifications include recommended implementation of Poon-Dryja 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.

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.

Initially, the invalidation transaction may have a relative lock time of 100 days, and then its outputs go to two unidirectional payment channels, one in either direction. Both parties may then use the payment channels until one channel is exhausted. The parties may then reset the payment channels, creating a new invalidation transaction with a relative lock time of 99 days that redistributes the money correctly, but with the unidirectional payment channels reset.

The payment channel may be closed at any time by either party (without the help of the other) by broadcasting the kickoff transaction on the blockchain. In case of such a unilateral close, both parties must wait out the relative lock times until they can broadcast the payment channel finalization transactions.

Parties should prefer the bilateral (cooperative) close, which collapses the kickoff, invalidation tree, and payment channel transactions into a single simple transaction that pays out the funds to both parties.

Duplex payment channels have indefinite lifetime, but there is a limit on number of updates possible due to the invalidation tree. This limit can be multiplied by adding additional layers to the invalidation tree, with resetting of the lower layers. Finally, in case of a unilateral close duplex payment channels require significant wait times and significant number of transactions to be published on the blockchain.

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

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

[[Category:Technical]]

Bitcoin Core compatible devices

2017-11-28T15:25:46Z

Almkglor:

A list of devices which are able to run recent versions of Bitcoin Core.
Note that these devices have *not* been tested to meet (currently undetermined) minimum specifications.

== Desktop/Laptops ==

* All Intel architecture 32-bit and 64-bit PCs and Macs. Pre-compiled executables are available from [https://bitcoin.org/en/download Bitcoin.org] for Windows, OS X, and most popular Linuxes. Users can compile executables for other Linuxes and the BSD-derived operating systems.

== ARM-based Chipsets ==

* Raspberry Pi v1 running Raspbian or another Linux<ref>[http://blog.pryds.eu/2014/06/compile-bitcoin-core-on-raspberry-pi.html Tutorial: Bitcoin Core on a Raspberry Pi], retrieved 26 August 2015</ref>, although it will run very slowly and the initial block chain sync may take more than a week.

* Raspberry Pi v2 running Raspbian or another Linux<ref>[https://web.archive.org/web/20150909172127/http://n-o-d-e.net/post/115030545546/how-to-build-a-bitcoin-node-on-the-raspberry-pi-2 How to build a Bitcoin node on the Raspberry Pi 2], archive.org copy 09 September 2015</ref>. Being about six times faster than the original RPi, it has the potential to be much more usable.

* ODroid U2 running Linux, although it's "not reliable due to thermal issues"<ref name="gmaxwell-irc">[http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/05/09#l1431157210.0 #bitcoin IRC log] 9 May 2015</ref>

* Novena (Cortex A9) running Linux<ref name="gmaxwell-irc" />

== References ==
<references/>

{{Bitcoin Core documentation}}

Payment channels

2017-11-26T00:31:36Z

Almkglor:

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.

=== Nakamoto high-frequency transactions ===

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 name="hearn_hft_quote" />

<blockquote>
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.
</blockquote>

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

A full description of the protocol is in [[Contract#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party|example 7 of the Contract page]].

Spillman payment channels are unidirectional (there is a payer and a payee, and it is not possible to transfer money back in the reverse direction).

Spillman payment channels expire after a specific time, and the receiver needs to close the channel before the expiration.

=== 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 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 inherent in the Spillman-style construction.<ref name="bip65" />

Like Spillman payment channels, CLTV-style payment channels are unidirectional and expire after a specific time.

=== 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] Joseph Poon & Thaddeus Dryja ''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 payment channels have indefinite lifetime. They are also bidirectional, unlike Spilman and CLTV payment channels.

The [https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md Lightning BOLT] specifications include recommended implementation of Poon-Dryja 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.

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.

Initially, the invalidation transaction may have a relative lock time of 100 days, and then its outputs go to two unidirectional payment channels, one in either direction. Both parties may then use the payment channels until one channel is exhausted. The parties may then reset the payment channels, creating a new invalidation transaction with a relative lock time of 99 days that redistributes the money correctly, but with the unidirectional payment channels reset.

The payment channel may be closed at any time by either party (without the help of the other) by broadcasting the kickoff transaction on the blockchain. In case of such a unilateral close, both parties must wait out the relative lock times until they can broadcast the payment channel finalization transactions.

Parties should prefer the bilateral (cooperative) close, which collapses the kickoff, invalidation tree, and payment channel transactions into a single simple transaction that pays out the funds to both parties.

Duplex payment channels have indefinite lifetime, but there is a limit on number of updates possible due to the invalidation tree. This limit can be multiplied by adding additional layers to the invalidation tree, with resetting of the lower layers. Finally, in case of a unilateral close duplex payment channels require significant wait times and significant number of transactions to be published on the blockchain.

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.

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

Payment channels

2017-11-23T15:01:37Z

Almkglor: /* Decker-Wattenhofer duplex payment channels */

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

=== Nakamoto high-frequency transactions ===

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 name="hearn_hft_quote" />

<blockquote>
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.
</blockquote>

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

A full description of the protocol is in [[Contract#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party|example 7 of the Contract page]].

Spillman payment channels are unidirectional (there is a payer and a payee, and it is not possible to transfer money back in the reverse direction).

Spillman payment channels expire after a specific time, and the receiver needs to close the channel before the expiration.

=== 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 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 inherent in the Spillman-style construction.<ref name="bip65" />

Like Spillman payment channels, CLTV-style payment channels are unidirectional and expire after a specific time.

=== 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] Joseph Poon & Thaddeus Dryja ''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 payment channels have indefinite lifetime. They are also bidirectional, unlike Spilman and CLTV payment channels.

The [https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md Lightning BOLT] specifications include recommended implementation of Poon-Dryja 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.

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.

Initially, the invalidation transaction may have a relative lock time of 100 days, and then its outputs go to two unidirectional payment channels, one in either direction. Both parties may then use the payment channels until one channel is exhausted. The parties may then reset the payment channels, creating a new invalidation transaction with a relative lock time of 99 days that redistributes the money correctly, but with the unidirectional payment channels reset.

The payment channel may be closed at any time by either party (without the help of the other) by broadcasting the kickoff transaction on the blockchain. In case of such a unilateral close, both parties must wait out the relative lock times until they can broadcast the payment channel finalization transactions.

Parties should prefer the bilateral (cooperative) close, which collapses the kickoff, invalidation tree, and payment channel transactions into a single simple transaction that pays out the funds to both parties.

Duplex payment channels have indefinite lifetime, but there is a limit on number of updates possible due to the invalidation tree. This limit can be multiplied by adding additional layers to the invalidation tree, with resetting of the lower layers. Finally, in case of a unilateral close duplex payment channels require significant wait times and significant number of transactions to be published on the blockchain.

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.

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

Payment channels

2017-11-23T15:00:25Z

Almkglor:

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

=== Nakamoto high-frequency transactions ===

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 name="hearn_hft_quote" />

<blockquote>
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.
</blockquote>

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

A full description of the protocol is in [[Contract#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party|example 7 of the Contract page]].

Spillman payment channels are unidirectional (there is a payer and a payee, and it is not possible to transfer money back in the reverse direction).

Spillman payment channels expire after a specific time, and the receiver needs to close the channel before the expiration.

=== 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 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 inherent in the Spillman-style construction.<ref name="bip65" />

Like Spillman payment channels, CLTV-style payment channels are unidirectional and expire after a specific time.

=== 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] Joseph Poon & Thaddeus Dryja ''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 payment channels have indefinite lifetime. They are also bidirectional, unlike Spilman and CLTV payment channels.

The [https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md Lightning BOLT] specifications include recommended implementation of Poon-Dryja 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.

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.

Initially, the invalidation transaction may have a relative lock time of 100 days, and then its outputs go to two unidirectional payment channels, one in either direction. Both parties may then use the payment channels until one channel is exhausted. The parties may then reset the payment channels, creating a new invalidation transaction with a relative lock time of 99 days that redistributes the money correctly, but with the unidirectional payment channels reset.

The payment channel may be closed at any time by either party (without the help of the other) by broadcasting the kickoff transaction on the blockchain. In case of such a unilateral close, both parties must wait out the relative lock times until they can broadcast the payment channel finalization transactions.

Parties should prefer the bilateral (cooperative) close, which collapses the kickoff, invalidation tree, and payment channel transactions into a single simple transaction that pays out the funds to both parties.

Duplex payment channels have indefinite lifetime, but there is a limit on number of updates possible due to the invalidation tree. This limit can be multiplied by adding additional layers to the invalidation tree, with resetting of the lower layers. Finally, in case of a unilateral close duplex payment channels require significant wait times and significant number of transactions to be published on the blockchain.

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>

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

Payment channels

2017-11-23T14:22:09Z

Almkglor: /* Poon-Dryja payment channels */

Payment channels

2017-11-23T14:17:12Z

Almkglor:

Payment channels

2017-11-23T14:07:38Z

Almkglor: /* Spillman-style payment channels */

Payment channels

2017-11-23T13:56:13Z

Almkglor:

Payment channels

2017-11-23T13:51:21Z

Almkglor: