Bitcoin lets users choose rules to control how their funds can be spent and have them automatically enforced by the network. This programmatic facility enables users to set their own policies, from simple ones like multisignature to complex ones like trustless exchange. However, some policies do not currently have an obvious expression in the Bitcoin system. In this post we’ll talk about one such example, covenants, and describe how they can be implemented with a small extension to the Bitcoin script language that already exists in Elements.
A financial covenant is an agreement that restricts how funds (typically loans) may be used. The Bitcoin scripting language can be programmed to allow authorization schemes restricting who is allowed to create transactions spending particular funds. However, any party that is able to satisfy the authorization requirements is allowed to create any transaction with those funds. With covenants, one can create scripts that, not only enforce authorization schemes, but can also restrict the sorts of transactions that the funds can be spend with. For example, we can use the Möser-Eyal-Sirer vault to time lock transactions and detect malicious access to one’s funds.
Like Bitcoin, the Elements Alpha script language does not have direct access to the transaction data. Transaction data is only accessible indirectly through the OP_CHECKSIG and OP_CHECKSIGVERIFY operations. These operations take an elliptic curve public key and digital signature as inputs along with a signature hash type. They compute a double SHA-256 hash of the transaction data, modified in accordance with the specified signature hash type, and then perform a digital signature verification of the doubly hashed message data with the digital signature and public key. If the operation is successful, OP_CHECKSIG returns a value of 1 on the stack, otherwise it returns 0.
Elements Alpha’s new OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY operations...