This put up was first revealed on Medium.
Recursive covenants
As we defined in collection #1, a Bitcoin covenant is a mechanism that enables the sender of a Bitcoin transaction to impose sure situations on how the receiver can spend the cash.
A recursive covenant is a sort of covenant that applies not solely to the rapid transaction but in addition to any subsequent transactions that spend the bitcoins. Which means that the situations imposed by the covenant could possibly be enforced recursively in perpetuity.
The primary distinction between a daily non-recursive covenant and a recursive covenant is the scope of the situations. A daily covenant solely applies to the rapid subsequent transaction, whereas a recursive one extends to all future transactions that spend the bitcoins.
Right here’s a easy instance for instance the distinction:
- Common covenant: Alice sends Bob 1 BTC with the situation that Bob can solely spend the BTC if he supplies a sound signature from a selected public key. This situation solely applies to the rapid transaction.
- Recursive covenant: Alice sends Bob 1 BTC with the situation that Bob can solely spend the BTC if he supplies a sound signature from a selected public key, and that any future transactions spending the BTC should additionally present a sound signature from the identical public key. This situation applies to all future transactions that spend the BTC.
Recursive covenants could be extra highly effective and versatile than common covenants. They characterize a big step ahead within the programmability and adaptability of Bitcoin transactions, doubtlessly opening up a big selection of latest functions and use circumstances. As an example, they permit implementing extra complicated transaction logic required for interoperability with sidechains or different Layer 2 options.
Bitcoin good contracts with state
In Bitcoin’s UTXO mannequin, good contracts are inherently one-off and stateless, because the UTXO containing the contract is consumed and destroyed when spent. Recursive covenants introduce a type of state that may be maintained and up to date throughout a number of transactions. When a transaction spends a UTXO (Unspent Transaction Output) containing a stateful contract, the state of the contract is up to date, and the brand new state is saved within the output of the spending transaction, all enforced by recursive covenants. In contrast to conventional Bitcoin transactions, that are stateless and immutable as soon as confirmed, stateful good contracts allow the monitoring and modification of state over time, akin to good contracts on different blockchain platforms like Ethereum.
Allow us to illustrate the way it works with a easy counter contract. This primary contract maintains a single state: what number of occasions it has been referred to as since deployment.
Counter in a series of transactions with state 0, 1, and a couple of
The state is saved in an adjoining output subsequent to the output containing the contract itself. Extra particularly, it’s in an OP_RETURN output.
OP_RETURN OP_PUSHBYTES [counter value]
The Counter contract under resides in a Taproot output. There are two methods price highlighting:
- We select to retailer state in a separate output, as an alternative of the identical taproot output. This enables us to keep away from tweaking the taproot deal with within the contract, because the deal with stays unchanged. Tweaking entails heavy elliptic curve arithmetic, which necessitates both excessively lengthy script or new opcode like OP_TAPLEAF_UPDATE_VERIFY/OP_TLUV.
- We use covenant to get the txid of the earlier transaction, which in turns permits us to parse the uncooked transaction and entry its outputs.
Counter contract
The contract make sure the spending transactions fulfill the next properties:
- recursive covenant: the deal with of the primary enter is similar to the deal with of the primary output
- state transition: the second output (i.e., the state output) of the present transaction will need to have a counter worth precisely one bigger than that within the earlier transaction’s second output
- having one enter and one two outputs
A single run ends in the next transactions:
- Deploy Transaction ID with preliminary state 0: https://mempool.house/signet/tx/142782e6dd8ffcf06554b8222637c237a65f47aab27c373da3ddd7b46cd8428c?supply=post_page—–6a3127a24af4——————————–
- Transaction ID with state 1 after incremented as soon as: https://mempool.house/signet/tx/1d1112a7ba7d3dde969006ab3984564b67b5060d1d323d2d2bf963069b600f20?supply=post_page—–6a3127a24af4——————————–
- Transaction ID with state 2 after incremented twice: https://mempool.house/signet/tx/01a5ed59ec9497ec82d80dc2ba41025342d66a25eec6b4046ec5b8c4964295d1?supply=post_page—–6a3127a24af4——————————–
Full code could be discovered at https://github.com/sCrypt-Inc/scrypt-btc-counter.
Extra refined state machines could be applied equally, the place state transition is enforced completely on chain. There could be different locations and methods to retailer and encode states, totally different from the counter contract.
Watch: Tokens on Bitcoin? One Sat Ordinals and sCrypt