Difference between revisions of "Payment Channels"

(Undo revision 249 by Brendan (talk))
Tag: Undo
 
(33 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Payment channels are peer to peer channels that can be used to exchange information, money and more.
+
''Payment Channels'' are a mechanism where two or more parties can directly exchange and update a transaction. The mechanism includes methods for establishing, or opening a payment channel, updating the channel, and finalising, or closing the payment channel. The mechanism also covers the possibility of any of the parties becoming unresponsive, usually by enabling the recovery of funds after a fixed time.
 +
 
 +
Payment channels support extremely rapid transaction updates with only the final closing transaction being timestamped on the blockchain.
 +
 
 +
Payment channels can be useful for streaming data, operating a sequence of events, or operating with a live dataset in applications such as gaming and more.
  
 
==Properties==
 
==Properties==
Payment channels have the following properties:
+
*Payment channels can be opened and closed arbitrarily.
*Payment channels can be opened and closed arbitrarily
+
*Payment channels can be opened directly with the participating peers, without needing a third party.
*You do not need do an on-chain transaction to open a payment channel (but you can have one)
+
*It is possible to open a payment channel with or without an on-chain action.
*Payment channels can be private or public
+
*Payment channels can be private or public.
*You can have many peers in a channel
+
*You can have many peers in a channel.
*You can add and remove peers from a channel
+
*You can add and remove peers from a channel.
*Payment channels are data conduits
+
*Payment channels are data conduits.
*On-chain payments close channels
+
*Channels are typically closed with an on-chain payment, however an on-chain payment can be made outside the channel which causes it to update.
  
==Connecting and using payment channels==
+
==Overview of the Mechanism==
#User peer connects to provider peer via known endpoint
+
A payment channel uses a transaction that has an [[nSequence]] that is less than 0xFFFFFFFF, and a nLocktime set to a time or block height in the future. The transaction can be updated many times between the peers until either, the nLocktime is reached, or nSequence is finalised and one of the parties transmits the transaction to the blockchain.
#Provider gives peer new endpoint (can be CGA) and Tx template
 
#User peer completes TX by adding funding inputs
 
#Provider supplies data and information to access next item (e.g. movie frames)
 
#Peers keep track of channel state using Sequence
 
  
 
==Example - Streaming Movie==
 
==Example - Streaming Movie==
The following goes through the sequence of opening, using and closing a payment channel for the purposes of serving streamed content.
+
The following goes through the sequence of opening, using, and closing a payment channel for the purposes of serving streamed content.
  
 
===STEP 1===
 
===STEP 1===
User browses catalog for titles to watch. Content can be on-chain or off-chain, but should be provably linked to a hash of the overall data. This hash can be the merkle root of all of the chunks that will be served to the user. The user sends this hash to the service provider to select the content.  
+
User browses catalog for titles to watch. Content can be on-chain or off-chain.  
  
 
===Step 2===
 
===Step 2===
 
User selects the content. At this point, there can be a few ways to manage the channel:
 
User selects the content. At this point, there can be a few ways to manage the channel:
*In public via mining network
+
*In public via mining network.
*In private with pre-funded UTXO per channel
+
*In private with pre-funded UTXO per channel.
*In private with separate channels for content purchase and service delivery per user
+
*In private with separate channels for content purchase and service delivery per user.
  
 
===Step 3===
 
===Step 3===
In this example, peers will use a timelocked UTXO in a public channel managed by miners to serve the content.
+
In this example, peers will use a timelocked UTXO in a public channel managed by Miners to serve the content.
 
For the sake of this example we will assume a single UTXO is being used. This UTXO goes into a double spend monitoring pool.
 
For the sake of this example we will assume a single UTXO is being used. This UTXO goes into a double spend monitoring pool.
  
Line 37: Line 37:
  
 
Where:
 
Where:
* S<sub>vn</sub> is the Viewer's  nth iteration of the channel signature
+
* S<sub>vn</sub> is the Viewer's  nth [[iteration]] of the channel signature.
* P<sub>v</sub> is the Viewer's pubkey
+
* P<sub>v</sub> is the Viewer's pubkey.
* H<sub>v</sub> is the Viewer's PKH
+
* H<sub>v</sub> is the Viewer's PKH.
  
* S<sub>pn</sub> is the service provider's nth iteration of the channel signature
+
* S<sub>pn</sub> is the service provider's nth iteration of the channel signature.
* P<sub>p</sub> is the service provider's pubkey
+
* P<sub>p</sub> is the service provider's pubkey.
* H<sub>p</sub> is the service provider's PKH
+
* H<sub>p</sub> is the service provider's PKH.
* H<sub>c0</sub> is the hash of the merkle root of the content being selected
+
* H<sub>c0</sub> is the hash of the [[merkle root]] of the content being selected.
* H<sub>cn</sub> is the hash of each content frame with H<sub>c1<\sub> being the hash of the first frame
+
* H<sub>cn</sub> is the hash of each content frame with H<sub>c1</sub> being the hash of the first frame.
* C<sub>n</sub> is the content frame with C<sub>1<\sub> being the first frame data
+
* C<sub>n</sub> is the content frame with C<sub>1</sub> being the first frame data.
* H<sub>fm</sub> is the hash of a message the user can trigger to prematurely end or pause the stream
+
* H<sub>fm</sub> is the hash of a message the user can trigger to prematurely end or pause the stream.
* F<sub>m</sub> is a message that the provider uses to end the stream
+
* F<sub>m</sub> is a message that the provider uses to end the stream.
  
The sequence no. for the input being spent is still 1
+
The sequence no. for the input being spent is still 1.
  
 
The transaction iterates between the two scripts as as follows:
 
The transaction iterates between the two scripts as as follows:
  
 
==Iteration 1==
 
==Iteration 1==
 +
 +
The user signs the inputs they want to spend in, as payment using SIGHASH_ALL with the following outputs:
  
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
|! Script No.
+
! Script No.
|! Purpose
+
! Purpose
|! Script
+
! Script
|! Amount
+
! Amount
 
|-
 
|-
 
| 1
 
| 1
Line 74: Line 76:
 
|}
 
|}
  
The Viewer also supplies the following input script:
+
The Viewer also supplies the following data allowing the content provider to spend the payment channel output if the payment channel is closed:
  
*''S<sub>v0</sub> P<sub>v</sub>''
+
*''S<sub>v0</sub> P<sub>v</sub>'' where the signature is signed as SIGHASH_ANYONECANPAY | SIGHASH_NONE. The user can do this as the payment channel's current TXID can be generated allowing the user to sign the output against the most recent revision of the payment channel.
  
which would allow the service provider to countersign the tx and settle on the network, guaranteeing payment for the first frame.
+
This would allow the service provider to close the channel by countersigning the tx and settling on the network, guaranteeing payment for the first frame.
  
The transaction pays out the price of the first frame to the service provider and the remainder is returned to the viewer as change. If the viewer cancels their session without watching, the transaction can still be processed on the network  
+
The transaction pays out the price of the first frame to the service provider and the remainder is returned to the viewer as change. If the viewer cancels their session without watching, the transaction can still be processed on the network, and using the provided second signature the service provider can claim their money.
  
 
===Step 4===
 
===Step 4===
Line 87: Line 89:
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
|! Script No.
+
! Script No.
|! Purpose
+
! Purpose
|! Script
+
! Script
|! Amount
+
! Amount
 
|-
 
|-
 
| 1
 
| 1
 
| Iteration 2: First frame
 
| Iteration 2: First frame
| ''SHA256 H<sub>c1</sub> EQUALVERIFY'' DUP HASH160 H<sub>p</sub> EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 H<sub>v</sub> EQUALVERIFY CHECKSIG
+
| SHA256 H<sub>c1</sub> EQUALVERIFY DUP HASH160 H<sub>p</sub> EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 H<sub>v</sub> EQUALVERIFY CHECKSIG
 
| Price of second frame
 
| Price of second frame
 
|-
 
|-
Line 101: Line 103:
 
| Viewer's change script
 
| Viewer's change script
 
| Change amount
 
| Change amount
|}
+
|}  
In this iteration, they sign to indicate they have received the first frame and provide the streaming service with payment for the second frame. This can be optimized for each service provider's fee model.  
+
 
 +
They also provide a new signature ''S<sub>p0</sub>'' for this output, allowing the user to countersign and broadcast the previous iteration should they wish to close the channel.
 +
 
 +
When the user receives this new output, they sign the inputs against the updated content to indicate they have received the first frame and provide the streaming service with payment for the second frame. The amounts can be optimised for the service provider's fee model.
  
They also provide a new signature ''S<sub>p0</sub>'' for this output, allowing the user to countersign should they need to close the channel.
+
If the payment channel were closed, this output could be subsequently spent by providing the second packet of movie data as part of the input. This is not the ideal way for the output to be created on-chain, as there are higher transaction fees involved, but is done this way to allow both parties to acknowledge the progression through the content.
  
 
===Step 5===
 
===Step 5===
The viewer iterates the transaction as shown:
+
The viewer completes the transaction as shown:
  
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
|! Script No.
+
! Script No.
|! Purpose
+
! Purpose
|! Script
+
! Script
|! Amount
+
! Amount
 
|-
 
|-
 
| 1
 
| 1
| Iteration 2: First frame
+
| Iteration 3: Second frame
 
| SHA256 ''H<sub>c2</sub>'' EQUALVERIFY DUP HASH160 H<sub>p</sub> EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 H<sub>v</sub> EQUALVERIFY CHECKSIG
 
| SHA256 ''H<sub>c2</sub>'' EQUALVERIFY DUP HASH160 H<sub>p</sub> EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 H<sub>v</sub> EQUALVERIFY CHECKSIG
 
| Price of second frame
 
| Price of second frame
Line 126: Line 131:
 
| Change amount
 
| Change amount
 
|}
 
|}
As in the previous iteration, they sign to indicate they have received the frame and provide the streaming service with payment for the next frame. This can be optimized for each service provider's fee model.  
+
As in the previous iteration, they sign to indicate they have received the frame and provide the streaming service with payment for the next frame. This can be optimised for each service provider's fee model.  
  
 
They also provide a new signature for this output, ''S<sub>v1</sub>'', allowing the service provider to countersign should they need to close the channel. In this example, the keypairs being used don't need to change for each iteration, but they could.
 
They also provide a new signature for this output, ''S<sub>v1</sub>'', allowing the service provider to countersign should they need to close the channel. In this example, the keypairs being used don't need to change for each iteration, but they could.
  
 
===Step N===
 
===Step N===
The user can request that the provider close the channel. Streams can also be paused, or take place at any framerate or even use larger transactions to move chunks at a time.  
+
The user can request that the provider close the channel. Streams can also be paused, or take place at any framerate, or even use larger transactions to move chunks at a time.  
 
In this case the user is deciding to close it.
 
In this case the user is deciding to close it.
  
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
|! Script No.
+
! Script No.
|! Purpose
+
! Purpose
|! Script
+
! Script
|! Amount
+
! Amount
 
|-
 
|-
 
| 1
 
| 1
| Iteration 2: First frame
+
| Iteration N: Final frame
| SHA256 ''H<sub>fm</sub>'' EQUALVERIFY DUP HASH160 H<sub>p</sub> EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 H<sub>v</sub> EQUALVERIFY CHECKSIG
+
| SHA256 H<sub>fm</sub> EQUALVERIFY DUP HASH160 H<sub>p</sub> EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 H<sub>v</sub> EQUALVERIFY CHECKSIG
 
| Price of second frame
 
| Price of second frame
 
|-
 
|-
Line 153: Line 158:
  
 
The user puts the finish message hash at the front of the output. The streaming provider sees this and knows the customer wants to close the channel.  
 
The user puts the finish message hash at the front of the output. The streaming provider sees this and knows the customer wants to close the channel.  
The user provide a new signature for this output, ''S<sub>vn</sub>''. This allows the streaming service provider to finalise the channel.  
+
The user provides a new signature for this output, ''S<sub>vn</sub>''. This allows the streaming service provider to finalise the channel.
 
 
  
 
===Step N+1===
 
===Step N+1===
The user can request that the provider close the channel. Streams can also be paused, or take place at any framerate or even use larger transactions to move chunks at a time.
 
In this case the user is deciding to close it.
 
  
The provider signs the transaction and solves the puzzle with the following script:
+
The provider broadcasts the final transaction and spends their payment with the following script:
  
 
''S<sub>vn</sub> P<sub>v</sub> S<sub>pn</sub> P<sub>p</sub> F<sub>m</sub>''
 
''S<sub>vn</sub> P<sub>v</sub> S<sub>pn</sub> P<sub>p</sub> F<sub>m</sub>''
  
In this way rather than closing the transaction with a potentially large blob of content data at the front, just a short code need be used.
+
In this way, rather than closing the transaction with a potentially large blob of content data at the front, just a short code need be used.

Latest revision as of 04:25, 25 April 2022

Payment Channels are a mechanism where two or more parties can directly exchange and update a transaction. The mechanism includes methods for establishing, or opening a payment channel, updating the channel, and finalising, or closing the payment channel. The mechanism also covers the possibility of any of the parties becoming unresponsive, usually by enabling the recovery of funds after a fixed time.

Payment channels support extremely rapid transaction updates with only the final closing transaction being timestamped on the blockchain.

Payment channels can be useful for streaming data, operating a sequence of events, or operating with a live dataset in applications such as gaming and more.

Properties

  • Payment channels can be opened and closed arbitrarily.
  • Payment channels can be opened directly with the participating peers, without needing a third party.
  • It is possible to open a payment channel with or without an on-chain action.
  • Payment channels can be private or public.
  • You can have many peers in a channel.
  • You can add and remove peers from a channel.
  • Payment channels are data conduits.
  • Channels are typically closed with an on-chain payment, however an on-chain payment can be made outside the channel which causes it to update.

Overview of the Mechanism

A payment channel uses a transaction that has an nSequence that is less than 0xFFFFFFFF, and a nLocktime set to a time or block height in the future. The transaction can be updated many times between the peers until either, the nLocktime is reached, or nSequence is finalised and one of the parties transmits the transaction to the blockchain.

Example - Streaming Movie

The following goes through the sequence of opening, using, and closing a payment channel for the purposes of serving streamed content.

STEP 1

User browses catalog for titles to watch. Content can be on-chain or off-chain.

Step 2

User selects the content. At this point, there can be a few ways to manage the channel:

  • In public via mining network.
  • In private with pre-funded UTXO per channel.
  • In private with separate channels for content purchase and service delivery per user.

Step 3

In this example, peers will use a timelocked UTXO in a public channel managed by Miners to serve the content. For the sake of this example we will assume a single UTXO is being used. This UTXO goes into a double spend monitoring pool.

The viewer sends a transaction with the following output script to the provider to initiate the channel:

Where:

  • Svn is the Viewer's nth iteration of the channel signature.
  • Pv is the Viewer's pubkey.
  • Hv is the Viewer's PKH.
  • Spn is the service provider's nth iteration of the channel signature.
  • Pp is the service provider's pubkey.
  • Hp is the service provider's PKH.
  • Hc0 is the hash of the merkle root of the content being selected.
  • Hcn is the hash of each content frame with Hc1 being the hash of the first frame.
  • Cn is the content frame with C1 being the first frame data.
  • Hfm is the hash of a message the user can trigger to prematurely end or pause the stream.
  • Fm is a message that the provider uses to end the stream.

The sequence no. for the input being spent is still 1.

The transaction iterates between the two scripts as as follows:

Iteration 1

The user signs the inputs they want to spend in, as payment using SIGHASH_ALL with the following outputs:

Script No. Purpose Script Amount
1 Iteration 1: Content Request Hc0 DROP DUP HASH160 Hp EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 Hv EQUALVERIFY CHECKSIG Price of first frame
2 Change Viewer's change script Change amount

The Viewer also supplies the following data allowing the content provider to spend the payment channel output if the payment channel is closed:

  • Sv0 Pv where the signature is signed as SIGHASH_ANYONECANPAY | SIGHASH_NONE. The user can do this as the payment channel's current TXID can be generated allowing the user to sign the output against the most recent revision of the payment channel.

This would allow the service provider to close the channel by countersigning the tx and settling on the network, guaranteeing payment for the first frame.

The transaction pays out the price of the first frame to the service provider and the remainder is returned to the viewer as change. If the viewer cancels their session without watching, the transaction can still be processed on the network, and using the provided second signature the service provider can claim their money.

Step 4

The provider responds with a new version of the transaction that modifies the output as shown:

Script No. Purpose Script Amount
1 Iteration 2: First frame SHA256 Hc1 EQUALVERIFY DUP HASH160 Hp EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 Hv EQUALVERIFY CHECKSIG Price of second frame
2 Change Viewer's change script Change amount

They also provide a new signature Sp0 for this output, allowing the user to countersign and broadcast the previous iteration should they wish to close the channel.

When the user receives this new output, they sign the inputs against the updated content to indicate they have received the first frame and provide the streaming service with payment for the second frame. The amounts can be optimised for the service provider's fee model.

If the payment channel were closed, this output could be subsequently spent by providing the second packet of movie data as part of the input. This is not the ideal way for the output to be created on-chain, as there are higher transaction fees involved, but is done this way to allow both parties to acknowledge the progression through the content.

Step 5

The viewer completes the transaction as shown:

Script No. Purpose Script Amount
1 Iteration 3: Second frame SHA256 Hc2 EQUALVERIFY DUP HASH160 Hp EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 Hv EQUALVERIFY CHECKSIG Price of second frame
2 Change Viewer's change script Change amount

As in the previous iteration, they sign to indicate they have received the frame and provide the streaming service with payment for the next frame. This can be optimised for each service provider's fee model.

They also provide a new signature for this output, Sv1, allowing the service provider to countersign should they need to close the channel. In this example, the keypairs being used don't need to change for each iteration, but they could.

Step N

The user can request that the provider close the channel. Streams can also be paused, or take place at any framerate, or even use larger transactions to move chunks at a time. In this case the user is deciding to close it.

Script No. Purpose Script Amount
1 Iteration N: Final frame SHA256 Hfm EQUALVERIFY DUP HASH160 Hp EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 Hv EQUALVERIFY CHECKSIG Price of second frame
2 Change Viewer's change script Change amount

The user puts the finish message hash at the front of the output. The streaming provider sees this and knows the customer wants to close the channel. The user provides a new signature for this output, Svn. This allows the streaming service provider to finalise the channel.

Step N+1

The provider broadcasts the final transaction and spends their payment with the following script:

Svn Pv Spn Pp Fm

In this way, rather than closing the transaction with a potentially large blob of content data at the front, just a short code need be used.