Access blockchain data from Bitcoin smart contracts: Part 5
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:
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:
Watch: CoinGeek New York panel, Bitcoin & Blockchain – Can Real Value Come from Real Utility?
Source: Read Full Article
