Access blockchain data from Bitcoin smart contracts: Part 5

Getting your Trinity Audio player ready...

This post was first published on Medium.

Building upon the foundation laid out in previous parts of the series, we have demonstrated how to implement relative locktime in Bitcoin, without new opcode OP_CheckSequenceVerify.

Timelock

A timelock restricts the spending of some bitcoins until a specified future time or block height. There are two types of timelocks:

1. Absolute: for example, one can provably lock up 1,100,000 bitcoins until block height 800,000, or until January 1st, 2025.
2. Relative: for example, one can lock up 21 bitcoins that can only be spent after 100 blocks or 3 days.

To enable absolute and relative timelocks, new opcodes OP_CheckLockTimeVerify/OP_CLTV and OP_CheckSequenceVerify/OP_CSV were introduced in BIP65 and BIP68/112/113, respectively.

Relative locktime without OP_CSV

Restoring the original Bitcoin protocol, Bitcoin SV has reverted the aforementioned changes. It turns out OP_CSV can be implemented with the original protocol.

In Part 1, we have shown how to access the block containing a given contract UTXO. Combining this block header with the specified relative timelock, we can know the earliest block that the UTXO can be spent. We demand any block after the deadline to be available for unlocking the UTXO, essentially placing a relative timelock on it as OP_CSV does. The full code is listed below.

Line 11 shows unlocking based on unix time (e.g., in seconds). validateHelper() function at Line 33 verifies both the block containing the UTXO and a latest block are valid (Line 41–42). It also verifies the former block actually contains the UTXO (Line 34–38) using the same technique as in Part 1. Line 15 ensures required time has elapsed since the UTXO is mined.

Line 19 shows unlocking based on block height (e.g., number of blocks). Line 24–25 get heights of the two blocks as in Part 3. Line 27 checks specified number of blocks have been mined after the UTXO.

Summary

Besides OP_CSV, we have previously implemented OP_CLTV without any change to the original Bitcoin protocol. There are two implications:

1. Both opcodes are not necessary to enabled UTXO-level timelocks, as previously thought.
2. All use cases enabled by OP_CSV/CLTV, such as lightning networks, sidechains, and CLTV-style payment channels, can be directly built on the original Bitcoin, if desired.

Watch: CoinGeek New York panel, Bitcoin & Blockchain – Can Real Value Come from Real Utility?