Difference between revisions of "Payment Channels"

Revision as of 13:03, 5 May 2020

Payment Channels are a mechanism where two or more parties can directly and trustlessly exchange and update a transaction. The mechanism includes methods for establishing, or opening, a payment channel, updating the channel, and finalizing, 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 confirmed in 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 typically uses a transaction that has an nSequence that is less than 0xFFFFFFFF. The transaction can be updated many times between the peers until the 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:

S_vn is the Viewer's nth iteration of the channel signature
P_v is the Viewer's pubkey
H_v is the Viewer's PKH

S_pn is the service provider's nth iteration of the channel signature
P_p is the service provider's pubkey
H_p is the service provider's PKH
H_c0 is the hash of the merkle root of the content being selected
H_cn is the hash of each content frame with H_c1 being the hash of the first frame
C_n is the content frame with C₁ being the first frame data
H_fm is the hash of a message the user can trigger to prematurely end or pause the stream
F_m 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

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

The Viewer also supplies the following input script:

S_v0 P_v

which would allow the service provider to countersign the tx and settle 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

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 H_c1 EQUALVERIFY DUP HASH160 H_p EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 H_v EQUALVERIFY CHECKSIG	Price of second frame
2	Change	Viewer's change script	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_p0 for this output, allowing the user to countersign should they need to close the channel.

Step 5

The viewer completes the transaction as shown:

Script No.	Purpose	Script	Amount
1	Iteration 2: First frame	SHA256 H_c2 EQUALVERIFY DUP HASH160 H_p EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 H_v 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 optimized for each service provider's fee model.

They also provide a new signature for this output, S_v1, 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 H_fm EQUALVERIFY DUP HASH160 H_p EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 H_v 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 provide a new signature for this output, S_vn. This allows the streaming service provider to finalise the channel.

Step N+1