Access other blockchains from Bitcoin trustlessly

Getting your Trinity Audio player ready...

This post was first published on Medium.

Previously, we have shown how to access BSV blockchain data from smart contracts running on it using SPV (simplified payment verification). We extend the idea to access other SPV-compatible blockchains.

As an example, anyone can mint a token on Bitcoin SV as long as she locks up BTC for a certain period of time. We provide first-ever implementation, which can be a foundation for a plethora of other applications.

How ‘Lock to Mint’ works

Recently, there has been a surge of interest in the “Lock to Mint” mechanism. This mechanism facilitates the time-locking of Bitcoin assets to mint BSV-20 fungible tokens on the Bitcoin network.

It is an instantiation of using a smart contract to control the minting of BSV20 tokens (v2) we introduced before. The “Lock to Mint” mechanism serves as a constraint in the token minting process of BSV-20. The contract ensures that the spending transaction must include a secondary output in a time-lock.

More details about how this process works in a BSV-only context can be found in this gist.

Cross-Chain

This smart contract can be extended to require the time-locking of funds on a different chain that supports timelocks and SPV, such as BTC. This is achieved by validating an SPV proof within the smart contract. Essentially, the contract, before minting, verifies the inclusion of a time-locked transaction with the correct parameters (locktime and payment destination) in a BTC block. The efficiency of SPV allows for this validation to be computationally viable. This is especially amenable for BTC, because it enjoys the highest hashing difficulty in its proof of work and thus renders it extremely costly to produce a valid but fake block header not in the main chain.

Implementation

The following code is an implementation of such a smart contract. We leverage the scrypt-ord library for easy integration of ordinals.

The contract exposes a single public method named “mint.” Suppose that we would like to mint 10 new tokens.

Before we call it, we have to construct and broadcast a time-locked transaction on BTC with the appropriate amount and lock-time. The transaction will be a standard P2WSH for a redeem script of the following format:

After this transaction has been mined and confirmed, we construct an SPV proof for it, consisting of a Merkle-proof and its block header. Now, we are able to call the public method by passing the serialized transaction along with the proof and the rest of the parameters, which are the token destination address, lock public key and token amount. To make it more reliable, we can ask for more than one confirmation.

The following is such a BTC time-lock transaction on testnet.

70bd8b876bacd6ad9df1100f8e691bada729e28ee3d311e949868c75d0bf690b

It is fed into a minting transaction on Bitcoin SV testnet.

db4d5b33eb2a095ee29ff1443613f5bc6db55c1eef724d1a5d93d0e6a2381fc7

The full code of the smart contract, along with a test is available on GitHub.

Here are also two Python scripts that we used to construct transaction for the deployment and redemption of a time-lock transaction on BTC.

Extensions

There are many ways to extend the example. It basically allows a smart contract on Bitcoin SV to access other compatible blockchain data, such as blocks and transactions, without trusting an oracle. We list some more examples below:

• Trustless One-Way Peg-In: as in a sidechain, one can send some BTC to a given address and is sure she can mint a wrapped token on Bitcoin SV. Note it is one way due to BTC’s lack of capability to verify SPV proofs.
• Randomness: one can use a BTC block as an entropy source, such as its block hash, for a game on Bitcoin SV. It is orders of magnitude more expensive to create fake headers than on Bitcoin SV.

Cybersecurity: Blockchain is a technology of trust