Yes, this is not a typo

We’re used to associating the Ethereum blockchain to smart contracts. In fact, Ethereum’s success has been based on developing and implementing smart contracts for various decentralized applications. However, not everyone realizes that the Bitcoin protocol allows for this technology to be used as well.

But before we start, let’s figure out why anyone would want to use the Bitcoin blockchain if a solid platform has already been invented specifically for these purposes.

Why Bother?

Leaving practical curiosity aside, we can say that the possibility of using BTC as an object of exchange, rather than ETH, might already seem like an advantage to some of us. Also, the bugs in the Solidity code are pretty hard to find and the infamous situation with DAO has shown that there’s definitely room for improvement in this area (in case you haven’t heard of it yet, here’s a great piece on DAO’s case by Maria Gelvec). Bitcoin, in turn, might offer a smaller window of attack for hackers. Bitcoin’s blockchain offers a higher level of security and a safer environment, and at the end of the day, that is one of the most important things. After all, who needs a multifunctional smart contract that can be easily hacked?

What We Have Now and What Can Be Improved

Bitcoin transactions have a scripting language within them that can define the conditions you need in order to redeem a certain amount of BTC. The only condition that is set while executing most BTC transactions today is to have the right private key to confirm it and that’s exactly how smart contracts work. However, it can go much further than that, and one can input a lot more complicated scripts. For example, you can set time conditions for when you can collect these BTC, or require multiple signatures, or combine them both and make very complex programming contracts.

If you want to add advanced functionality to Bitcoin-based smart contracts, you will have to use various improvement proposals. Let’s try to figure out what improvements are already out there and could be implemented.

Timelocks

If the BTC transaction is executed the regular way, you will be able to spend your digital money as soon as you receive it. But what if you want the receiver to be able to spend this funds only after a certain date? Let’s say you want to save up for your next vacation so you decide to lock the funds until the first day of your trip. In this case, a specific smart-contract could be quite helpful. But can we put it into action? In 2015, a Bitcoin soft-fork introduced the concept of timelocks with an opcode called CheckLockTimeVerify. It allows transaction outputs to be restricted with a timelock. When a timelock is present, the output cannot be spent until a certain date.

Sidechains

Sidechains might solve a lot of existing problems like scalability and speed, and can also contribute to enabling bitcoin-based smart contracts. One example was already offered by Rootstock (RSK), a two-way pegged sidechain to Bitcoin that was designed specifically to enable its smart contract functionality.

Basically, when you want to execute a smart contract on the RSK sidechain, you send your BTC to a specific address where they are then locked. In exchange, you get the same amount of RSK coins and use them to execute this smart contract. After it’s done, you send these coins back via the two-way peg and unlock the bitcoins in the mainnet.

MimbleWimble Protocol

The ‘mysterious’ MimbleWimble protocol suggests implementing a zero-value output kernel that cannot be spent. This way you won’t jeopardize the transaction as it would be necessary to know the number of expendable outputs. Add multi-signatures and the protocol becomes almost invincible. When we explored the MimbleWimble protocol earlier, we mentioned that not storing the transaction inputs leads to lighter nodes and greater decentralization. It means more privacy as you cannot match the input and output of the transaction which is extremely important when it comes to executing smart contracts.

Schnorr Signatures

Using multiple signatures instead of one when confirming a transaction obviously makes it a lot safer. Replacing the current signature model that is used in bitcoin with Schnorr signatures could help make some space on the blockchain and solve two major issues: the transaction backlog and high fees. It can also push bitcoin smart contract’s limits as it suggests using a universal signature for several stakeholders. Imagine that there is a separate public key for everyone who is involved in smart contract execution. Those keys are linked to one another and everyone gets a single public key. The public key, in turn, should be protected by the private signature that was created specifically for it.

One of the advantages of Schnorr signatures is that they are more compact and that most of the computations can be done before you execute a transaction thus increasing the speed when you actually send it.

Let’s give the Schorr algorithm a closer look. The size of the transaction also depends on the size of your signature data. So the more your signature data weighs, the less transactions that can be included in the block, and that means lower speed and higher fees. When using ECDSA (cryptography behind Bitcoin’s private and public keys), if you want to send your friend 1 BTC from several sources, each source will have its dedicated signature and take up a lot of that precious block space. If you use the Schnorr algorithm, you will only have one universal signature and less space will be occupied.

Conclusion

These are only a few examples of the improvements that can contribute to bringing smart contracts to the safe environment of the bitcoin ecosystem. Bitcoin-based smart contracts are clearly an interesting idea worth exploring.

Got an Opinion?

The Lumi Wallet team would be happy to hear your thoughts on this or any other blockchain related subject. Drop us a line on Telegram, or follow us on TwitterFacebook, and Reddit. We’re devoted to explaining difficult crypto stuff in simple words to you!


Leave a Reply

Your email address will not be published. Required fields are marked *