Payment Channels

Revision as of 13:46, 17 October 2019 by Brendan (talk | contribs) (Undo revision 211 by Brendan (talk))

Payment channels are peer to peer channels that can be used to exchange information, money and more.

Properties

Payment channels have the following properties:

  • Payment channels can be opened and closed arbitrarily
  • You do not need do an on-chain transaction to open a payment channel (but you can have one)
  • 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
  • On-chain payments close channels

Connecting and using payment channels

  1. User peer connects to provider peer via known endpoint
  2. Provider gives peer new endpoint (can be CGA) and Tx template
  3. User peer completes TX by adding funding inputs
  4. Provider supplies data and information to access next item (e.g. movie frames)
  5. Peers keep track of channel state using Sequence

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

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:

  • Sv is the Viewer's signature
  • Pv is the Viewer's pubkey
  • Hv is the Viewer's PKH
  • Sp is the service provider's 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<\sub> being the first frame data
  • Pf is the PKH the user pays to in order to prematurely end or pause the stream

The sequence no. for the input script being spent is set to 1 and an ntimelock setting of (say) 48 hours in the future is set

The transaction pays out two scripts as as follows:

! Script No. ! Purpose ! Script ! Amount
1 Iteration 1: Content Request HP<\sub> CHECKSIGVERIFY Hc0<\sub> SHA256 EQUALVERIFY Pv<\sub> CHECKSIGVERIFY Price of first frame
2 Change Viewer's change script Change amount

The transaction pays out the price of the first frame to the service provider and the remainder is returned to the viewer as change.

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

! Script No. ! Purpose ! Script ! Amount
1 Iteration 2: First frame HP CHECKSIGVERIFY Hc0 SHA256 EQUALVERIFY Pv CHECKSIGVERIFY Price of first frame
2 Change Viewer's change script Change amount



INPUT SCRIPT

1: Sv Pv Sp Pp The interpreter add an OP_CODESEPARATOR after Pp<\sub> to terminate the input.

<finalization_message_hash>