Netflix over Bitcoin payment channels

Getting your Trinity Audio player ready...

This piece was first published on Medium.

Malleability as a feature, not a bug

We demonstrate a cost-efficient way to provide movie streaming and other types of services on demand, based on payment channels.

Malleability

In the context of Bitcoin, malleability means the ability to modify a transaction without invalidating it. There are two levels:

• Script level: signature does not cover unlocking script, so modifying it does not alter signature validity
• Transaction level: SIGHASH flags can be used to control which inputs/outputs are signed.

We focus on script-level malleability here.

Streaming

Suppose Alice wants to purchase a movie stream from Bob.

The movie is broken into multiple small chunks: D₀, D₁, D₂, …, Dn. Alice and Bob create a so-called payment channel to exchange messages off chain. Bob shares the leaves of the Merkle tree with Alice (H₀ to H₇ below). Alice can verify its fidelity by calculating its root hash (T₀) and compare it against a publicly known hash of the given movie¹.

Figure 1: A Merkle Tree

Alice creates a sequence of transactions: TX₁, TX₂, …, TXn. It locks up coins into the following smart contract, funded by her UTXOs referenced in the input.

Figure 2: Transactions with Scripts Shown²

Contract Netflix

There are two options to unlock the coins:

1. Bob signs and provides the correct chunk of data, i.e., when condition in if is false at Line 12
2. Both Alice and Bob sign, when condition in if is true at Line 12

Every time Alice receives Dᵢ, TXᵢ is updated with only two changes:

1. Hᵢ: hash in the contract above is updated to the hash of the next chunk
2. Output amount is increased by 100 satoshis, to pay for an additional chunk.

Note Alice needs to sign again. The following diagram shows the exchanges between Alice and Bob, from the opening to the closing of the channel.

Payment Channel⁴

Channel Closure

At any moment, Alice or Bob can stop the streaming unilaterally or jointly. If Alice stops the payment, Bob will stop streaming; and vice versa. No one can cheat³.

2-way: Bob sends TXp, the payment transaction, to Alice. Alice malleates it by replacing Dᵢ with her signature as Figure 2 shows. Note the new transaction TXp’ is still valid and can still unlock the old contract using Option 2, instead of Option 1. Bob prefers to close the channel this way because:

• It saves transaction fee. In general, each chunk is significantly bigger than a signature (only 72 bytes on average). In the extreme case, a 4GB chunk using OP_PUSHDATA4 is pruned, leading to a whopping ~60,000,000X reduction.
• The data chunk is private and sensitive. Bob does not want to expose the movie chunk on chain for everyone to view.

1-way: if Alice refuses to sign, Bob can always use Option 1 to collect the payment.

Only two transactions end up on chain. All the intermediate transactions can be safely discarded afterwards.

Discussion

Compared to existing paid streaming sites such as Netflix, this payment channel-based streaming has salient advantages:

• Pay as you go: only pay for parts of a movie that are watched
• Low transaction cost, thanks to Bitcoin’s micropayment capability
• No signup required.

For it to be more practical, additional measures have to be taken to prevent Alice from doubling spend funding transactions (UTXOs referenced in TXᵢ) outside of the channel, and broadcasting stale transactions (e.g., broadcast TX₁ when we are already at TX₉). Please refer to the patent⁴ for more details.

Also, it would be possible for Bob to only share the next chunk and its Merkle proof iteratively using this technique, to avoid sharing the all tree leaves at once at the beginning.

Summary

We use streaming movies only as an example. It is fairly straightforward to extend this approach to “stream” other types of data/service, e.g., Wi-Fi, utility (water and electricity), rental (car and house). Many pay-as-you-go services can be offered conveniently this way.

Acknowledgements

This article is based on nChain patent WO2020240297A1⁴.

[1] We assume the Merkle roots of movies are publicly available from trusted third parties like IMDB and Netflix.

[2] Some parts of the transactions are not shown for brevity, such as change outputs.

[3] Technically, Alice can cheat by not paying Bob after he delivers one chunk. But this is not an issue in practice since it is of very low value.

[4] nChain patent WO2020240297A1: Malleability of transactions for inclusion in a blockchain