A general misconception is that bitcoin is less smart-contract friendly than some other blockchains.
The bitcoin scripting language is designed to be as primitive as possible. Using a set of OP codes, the language achieves maximum security while minimizing attack surfaces through intentional limitations, which often leads to an underestimation of bitcoin’s true potential. In fact, by simply focusing on the bitcoin scripting language, there is a risk that many other interesting features of the protocol may be overlooked. To understand how bitcoin is smart-contract friendly, one needs to zoom in and out on the bitcoin transaction as well as the entire stage on which the bitcoin transaction plays its role.
By doing this, it becomes apparent that there are many ways to construct smart contracts on bitcoin. We can summarise them roughly as
- smart locking scripts,
- smart use of sighash flags, and
- payment channels.
This article is dedicated to explaining how payment channels make bitcoin smart-contract friendly.
What is a payment channel?
A payment channel is a communication channel in which participants communicate via bitcoin transactions. All information communicated is represented in bitcoin transactions.
Some essential knowledge
For each bitcoin
transaction, you can have more than one input. For each input, there is a
parameter called the sequence number. This number is an indication of whether
the transaction that includes this input is finalised or not. If the parameter
does not take the maximum value (0xFFFFFFFF), then the validation process will
look at the locktime field (defined at the transaction level), which specifies
a time when the transaction becomes valid, i.e. a transaction is not valid
until the locktime. This can be useful when the time specified is in the
future. (The furthest you can choose for locktime is roughly 9,500 years in the
future, at the time of writing.) Before the locktime of a given transaction
matures, a new version of that transaction, with a larger sequence number, can
invalidate the earlier version that spends the same input but with a smaller
sequence number.
This feature comes with
the original bitcoin protocol and is essential for the type of payment channel
that is commonly referred to as a Nakamoto
Payment Channel.
A generic paradigm for smart contracts on bitcoin
The core element in our paradigm is a so-called funding transaction. It is a transaction that opens a payment channel as soon as it is confirmed on-chain. A typical funding transaction looks like this:
Paired with this funding transaction is a corresponding refund transaction, which would return the initial funds to the participants, after a given locktime matures:
Once transaction TxID0 has been submitted to the blockchain, a payment channel for the contract specified in the funding transaction is opened. All subsequent communications between Alice and Bob are via bitcoin transactions. These transactions not only are bitcoin-compatible but also follow the rules specified by the payment channel, i.e. the contract established in the funding transaction. The validation can be done by either participant. In simple terms:
- Alice sends a transaction to Bob with her signature.
- Bob checks the transaction.
a. If he is happy, he also signs it, and sends it back to Alice. This creates a checkpoint for the payment channel (last agreed transaction).
b. If he is not happy, he updates the transaction, and sends it to Alice. - Each update of the transaction increments the sequence number by 1 or more.
- Alice and Bob repeat this process until they need to settle the contract on chain.
How is this a smart contract?
We need to agree that a contract becomes smart if it can be automated, enforced, and requires no trust. If we do, then we can verify the requirements one by one.
Automation
Both Alice’s and Bob’s actions can be fully automated. When creating the funding transaction, the source code of the implementation can be added to the OP_RETURN payload. As the transaction is signed by both parties, it implies that the implementation of the automation is verified and approved by both Alice and Bob.
Enforcement
If either party is trying to cheat, the other party can simply publish the last agreed transaction to claim the output. Given the nature of bitcoin transactions, it is not possible for the cheating party to gain more than what the last agreed transaction suggests. In other words, the enforcement is inherited from the pair of transactions: the funding transaction and the refund transaction.
Trust
The payment channel does not require Alice or Bob to trust each other. Once the funding transaction is on-chain, they will try to communicate in the payment channel to achieve a consensus. If they do not, they can always revert to the last agreed transaction. This is inherited from the enforcement property.
How is this better?
We claim this is better than other smart contract platforms because it offers scalability, flexibility, privacy, and cost-effectiveness.
Scalability
A payment channel in general requires only two transactions be recorded on-chain, the funding transaction and the settlement transaction. All the communications in the payment channel are peer-to-peer. Miners do not need to verify the intermediate transactions exchanged in the payment channel, unlike other blockchains where every single smart contract is executed by all miners in the network. This localised peer-to-peer paradigm provides the capabilities for scaling.
Flexibility
There is no requirement on what programming language to implement contracts, what platform to run on, or what additional rules participants need to follow. The only requirement is that all participants of the payment channel agree on the funding transaction which specifies all the parameters and rules.
Privacy
It is not necessary to put the contract in the funding transaction explicitly. To add more privacy, one can always choose to put a hash value in place of the raw information within the OP_RETURN payload.
Cost-effectiveness
There is no need to pay
fees to miners as they are not required to provide any service to the execution
of the smart contract.
In addition to the listed advantages, a funding
transaction template can be shared in a marketplace for similar use cases. For
example, a funding transaction for a payment channel that allows two
participants to play chess can be reused for any other two players. We can also
have a funding transaction for a mining pool where the template can be adapted
to any other mining pool. The challenge for designing such templates is to
ensure that the rules specific to the payment channel are not biased to any
participant.
Conclusion
What we have presented is a generic paradigm for smart contracts on bitcoin, which is a feature that many people assume to be lacking in bitcoin. We have seen that a payment channel can offer this functionality in a way that is scalable, flexible, private and cost-effective. Possible use cases include micropayments for utilities and content streaming, live gaming and e-sports, commercial agreements involving frequent payments, and many others. Now, it is your turn to be creative. *In this article, bitcoin referrers to the original bitcoin protocol, which is represented by Bitcoin SV.
Contact: Wei Zhang, Senior Researcher, nChain, [email protected]
© 2019 nChain Limited. All rights reserved. This article is provided without any warranties whatsoever and shall not result in the grant of any license, whether implied or otherwise. nChain Limited shall not be liable in any way for the use of the information provided herein.