|
|
| Line 20: |
Line 20: |
| | ==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===
| |
| − | 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:
| |
| − | * S<sub>vn</sub> is the Viewer's nth iteration of the channel signature
| |
| − | * P<sub>v</sub> is the Viewer's pubkey
| |
| − | * H<sub>v</sub> is the Viewer's PKH
| |
| − |
| |
| − | * 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
| |
| − | * 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>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
| |
| − | * 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
| |
| − |
| |
| − | The sequence no. for the input being spent is still 1
| |
| − |
| |
| − | The transaction iterates between the two scripts as as follows:
| |
| − |
| |
| − | ==Iteration 1==
| |
| − |
| |
| − | {| class="wikitable"
| |
| − | |-
| |
| − | |! Script No.
| |
| − | |! Purpose
| |
| − | |! Script
| |
| − | |! Amount
| |
| − | |-
| |
| − | | 1
| |
| − | | Iteration 1: Content Request
| |
| − | | H<sub>c0</sub> DROP DUP HASH160 H<sub>p</sub> EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 H<sub>v</sub> EQUALVERIFY CHECKSIG
| |
| − | | Price of first frame
| |
| − | |-
| |
| − | | 2
| |
| − | | Change
| |
| − | | Viewer's change script
| |
| − | | Change amount
| |
| − | |}
| |
| − |
| |
| − | The Viewer also supplies the following input script:
| |
| − |
| |
| − | *''S<sub>v0</sub> P<sub>v</sub>''
| |
| − |
| |
| − | 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:
| |
| − |
| |
| − | {| class="wikitable"
| |
| − | |-
| |
| − | |! Script No.
| |
| − | |! Purpose
| |
| − | |! Script
| |
| − | |! Amount
| |
| − | |-
| |
| − | | 1
| |
| − | | 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
| |
| − | | 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<sub>p0</sub>'' for this output, allowing the user to countersign should they need to close the channel.
| |
| − |
| |
| − | ===Step 5===
| |
| − | The viewer iterates the transaction as shown:
| |
| − |
| |
| − | {| class="wikitable"
| |
| − | |-
| |
| − | |! Script No.
| |
| − | |! Purpose
| |
| − | |! Script
| |
| − | |! Amount
| |
| − | |-
| |
| − | | 1
| |
| − | | Iteration 2: First frame
| |
| − | | 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
| |
| − | |-
| |
| − | | 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<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===
| |
| − | 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.
| |
| − |
| |
| − | {| class="wikitable"
| |
| − | |-
| |
| − | |! Script No.
| |
| − | |! Purpose
| |
| − | |! Script
| |
| − | |! Amount
| |
| − | |-
| |
| − | | 1
| |
| − | | Iteration 2: First frame
| |
| − | | 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
| |
| − | |-
| |
| − | | 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<sub>vn</sub>''. This allows the streaming service provider to finalise the channel.
| |
| − |
| |
| − |
| |
| − | ===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:
| |
| − |
| |
| − | ''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.
| |