BSV vs BTC smart contracts

Getting your Trinity Audio player ready...

This post was first published on Medium.

We compare smart contracts on Bitcoin SV (BSV) and BTC.

Fundamental differences

Bitcoin SV

Bitcoin SV uses the original script opcodes released by Satoshi, which enables Turing-complete smart contracts. To build any application, no new opcode or any change to the base layer is needed. Permissionless innovation is welcomed and builders are free to tinker with any novel applications. All are implemented in the form of smart contracts, running on top of the base layer, instead of being hardcoded and baked in it. This offers developers and innovators speed and rapid time to market, boosting their creativity and ingenuity.

BTC

Because of many disabled opcodes, when a new use case is desired, a fork (either soft or hard) is often needed to support it. One needs to seek blessings and permissions from gatekeepers (e.g., Core developers), which is contentious and may takes years to activate a proposal, if it is one of the few lucky ones to be accepted and approved.

Use Case Examples

We list several prominent use cases proposed by BTC, which are all deemed impossible without a fork. We demonstrate not only are they possible using the original Bitcoin protocol in BSV, but also their implementation is up to many orders of magnitude faster. All examples come with open-sourced working code, which can be independently verified.

Taproot

Taproot took 4 years, 150+ developers

Taproot in BTC involved ~150 developers and took ~4 years, from proposal to activation. It has been implemented by a solo developer in one hour on BSV!
Permissionless innovation at its finest.

Graftroot

Similar to Taproot, Graftroot has been implemented on BSV, which is yet to be done in BTC.

Zero-Knowledge Proof (ZKP)

ZKP is probably the most sophisticated and advanced type of cryptography used in blockchains. It has recently garnered enthusiasm in BTC, which requires adding a new opcode. BSV has had a working ZKP verifier on chain since 2022.

Covenant

BTC has a few proposals to enable covenant, such as OP_CHECKTEMPLATEVERIFY/OP_CTV in BIP119. BSV has covenant since 2020. It even has a recursive covenant.

Blockstream published a trick to enable covenant using OP_CAT, 3 months after we released it in October 2020¹. The former does not work on BTC even today, due to lack of OP_CAT.

Vault

One of the use cases for covenant is vault, which has been implemented in BSV.

Schnorr Signature

Schnorr signature is introduced in BTC as part of the SegWit upgrade. It can be implemented as a smart contract.

SIGHASH_ANYPREVOUT (APO)

SIGHASH_ANYPREVOUT, an updated version of SIGHASH_NOINPUT, in BIP-118 is a proposal to exclude the identifier for the UTXO being spent from the signature hash (sighash). We have also implemented it. Furthermore, our approach allows arbitrarily customizing which parts of transaction data goes into sighash, much more universal and flexible.

Merklized Abstract Syntax Tree (MAST)

Merklized Abstract Syntax Tree MAST (aka, Merklized Alternative Script Trees) uses a Merkle tree to encode mutually exclusive branches in a script, which has been merged into Taproot.

Lamport Signatures

Lamport signatures, a one-time signature scheme using hash functions, is quantum resistant and has been proposed.

Oracle

On BTC, Discreet Log Contract (DLC) is used to implement oracles. However, it suffers from scalability issues since parties have to create and store signatures for every possible outcome an oracle may sign.

On BSV, we have implemented oracles using native ECDSA, which only signs the final and single outcome.

We have also implemented a more efficient alternative based on Rabin signatures.

OP_CHECKSIGFROMSTACK/OP_CSFS

OP_CSFS is a proposed opcode in BTC that allows checking whether a signature signs an arbitrary message.

OP_CheckLockTimeVerify/CLTV

BTC introduces new opcode OP_CLTV in BIP65 to realize absolute time lock, which can be implemented without it.

OP_CheckSequenceVerify/CSV

BTC introduces new opcode OP_CSV in BIP112 to realize relative time lock, which can also be implemented without it.

[1] We only released an ECDSA version since Schnorr is not natively supported in BSV, so we did not consider it. But it can be trivially adapted to work with Schnorr.

Watch: sCrypt makes smart contracts possible on the BSV blockchain