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.
- 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.
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²
There are two options to unlock the coins:
- Bob signs and provides the correct chunk of data, i.e., when condition in if is false at Line 12
- 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:
- Hᵢ: hash in the contract above is updated to the hash of the next chunk
- 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.
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.
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.
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.
This article is based on nChain patent WO2020240297A1⁴.
 We assume the Merkle roots of movies are publicly available from trusted third parties like IMDB and Netflix.
 Some parts of the transactions are not shown for brevity, such as change outputs.
 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.
 nChain patent WO2020240297A1: Malleability of transactions for inclusion in a blockchain
New to Bitcoin? Check out CoinGeek’s Bitcoin for Beginners section, the ultimate resource guide to learn more about Bitcoin—as originally envisioned by Satoshi Nakamoto—and blockchain.