A Primer to Covenants
Written by Guest Author Grant Hunter.
Edited by ecurrencyhodler
Covenants
The word covenant comes from historical English Common Law, meaning to make a solemn promise to perform a certain action or refrain from a certain action. It’s recent, and more commonly known, use has been in Property Law, where it is a set of conditions which accompany land that affect how it is used. They are usually restrictive and can only be effectively put in place if these restrictions benefit the land.
Litecoin Covenants are therefore aptly named. Covenants effectively allow a restriction to future use of the coins after the transaction has completed. Each transaction output consists of an amount and an output script program. Covenants Protocol are enabled by adding a new operation to the scripting language that restricts both of these fields. Specifically, the operation takes an output index, an amount, and a pattern (this replaces the original LTC PubKey in an output). It verifies that the output at the given index exists, that it carries the required amount, and that its script matches a given pattern.
A basic Covenant output scheme
Specifically, the operation takes an output index, an amount, and a pattern. It verifies that the output at the given index exists, that it carries the required amount, and that its script matches a given pattern. To ensure that the covenant is kept in all subsequent transactions, the following recursive covenant can be applied:
These output scripts allow Covenants to apply to one, several, or an unlimited number of subsequent transactions. It is in this way that a single Litecoin transaction can be repurposed, divided, and repeatedly transferred covenants.
Covenants also extends Litecoin’s output script program by allowing two exceptions: CheckLockTimeVerify and CheckSequenceVerify. These make an output unspendable until a certain point in time is reached enabling Covenant transactions to time out. This allows a user to repurpose a coin to self-terminate after a set time or with a specific private key. This sets the foundation for Colored Coins to be used on top of the Litecoin blockchain.
Colored Coins
Colored Coins use the Covenants Protocol to attach a ‘distinguishable mark’ to specific coins. This allows users to gain more control over their coins. Typically when LTC is sent, all the Litecoins get mixed together when they’re compiled into a block. Distinguishing them with Covenants allows them to be tracked and retrieved. Colored Coins are also working with Hyperledger to provide this framework across multiple blockchains to create an industry standard.
One obvious use case for Colored Coins is to create ICO utility tokens like Ether. Another one is to use Colored Coins as a digital asset exchange mechanism by associating a physical asset to a certain coin or set of coins. For example, one could attach an arbitrary amount of Litecoins to a certain amount of gold, deposited with a trusted party. This coin(s) could then be used to represent ownership of the gold and be easily traded as a singular item; the blockchain acting as a settlement layer and a dispute resolution mechanism that secures the assets if needed. Digital assets can be transferred with low validation times, high quality control and low fees. For any system of exchange to be used more widely, it needs to function faster, more efficiently and less costly than the competition. This combined with the Lightning Network, will certainly give the Litecoin blockchain a powerful suite of tools for financial services.
Let’s now consider a third possible use case for Colored Coins except this time with self-termination. As an Airbnb host, you could potentially send your renters colored coins that time out at the end of three days. These colored coins would function like keys that give your renters access to the apartment. Should they be tempted to stay longer, they would be shut out because the colored coins will have expired.
Vaults
Alongside financial instruments, Covenants allow extra security measures to be built. One ‘novel use case,’ which is suggested in the white paper, MES16, is Recoverable Vaults.
Vaults focus “on improving the security of private cryptographic keys. Historically, maintaining these keys securely and reliably has been a critical vulnerability for users. Vaults disincentivize key theft by preventing an attacker from gaining full access to stolen funds.” They use two mechanisms for this:
Funds stored in a vault can be recovered using a recovery key in case the vault key is compromised. This allows for less stringent methods to be used in securing private keys. Private keys are literally the only access a user has to their funds. Correctly managing private keys is therefore one of the central challenges for users to protect themselves from loss and theft. Cold storage has been a preferred way to keep the private keys stored safely on a device not connected to the internet. However, to use the funds, it needs to be connected to the internet, and this presents a vulnerability to attack. Not to mention, the chance for a user to lose their cold storage and all funds attached to the private keys within.
Incase the recovery key is compromised as well, the owner can still prevent the attacker from moving the coins. The worst the attacker can do is to prevent the owner from regaining full control over the funds. As this reduces the motivation for key theft, users can be more permissive in their storage of the private keys, reducing the chances of key loss.
Vault transactions can prevent an attacker from spending ‘stolen’ coins by putting a time delay on the transaction. It works on the principle that the transaction has to be publicly on the chain, with its completion locked for a specified time. This gives time for the owner to issue the recovery key and have the funds sent to a new vault address in a new transaction. Therefore stopping the attacker spending spending the coins. They basically use a double spend protocol to intercept the theft transaction and re-route the funds to a new wallet address of their own. This can be done repeatedly and infinitely, which can assist in situations where an attacker may have had access to the recovery key; the owner can keep recovering the funds from the attacker. Although this may not completely stop theft, it certainly makes it a harder and a more time consuming task.
As illustrated above, this is done by the user sending funds to a vault fund transaction. This is basically how to ‘place’ a designated amount of coins in a vault. The outward transaction requires a signature corresponding to the vault key and contains a covenant instruction that restricts the movement of funds through a vault spend transaction. The vault spend offers two possibilities to redeem its funds:
The funds can be sent to a standard address, but only after a certain number of blocks has passed. This is now the timer on the vault.
The funds can be sent at any time without having to wait for the locktime to expire using the recovery key in another vault spend transaction, identical to the first one.
*A sincere thanks to Malte Möser, Ittay Eyal, and Emin Gün Sirer for writing their paper on Bitcoin Covenants which we used as our source.
Grant’s Donation Addresses
BTC — 1KssP7Y47doZMFKf4ke5b7qAPiYyXLaN82
LTC — LfnmBLtnogxNEBq4wS62y9DDvUTpddK8S3