Bitcoin improvements can be achieved by implementing covenants. This article explains covenants, how they work and the debate around them.
Drawbacks of Bitcoin covenants
Various prominent Bitcoin experts, including Adam Back, Jimmy Song and Andreas Antonopoulos, have raised some concerns over the implementation of restrictive covenants, in particular with the BIP119.
In particular, Antonopoulos has voiced concerns over "recursive covenants" that the new update could convey, thereby deteriorating the network. A recursive covenant occurs when a programmer restricts a transaction, but he does it in a way that restricts another transaction after that, starting a domino effect resulting in future limitless recursive covenants.
Blacklisting and risks of censorship and confiscation
While locking up where a Bitcoin can be spent is advantageous to ensure more security, it also provides grounds for censorship, and control by governments, which would hinder the very existence of Bitcoin. Authorities could potentially force exchanges to withdraw only to covenants with some control over the coin.
While this same risk already exists, since governments can ask exchanges to send only to addresses with a taproot spend path or multi-sig controlled by them, could the implementation of covenants facilitate malicious purposes where it would make it easier for governments to enforce a sort of on-chain KYC?
Fungibility threats
Covenants might interfere with Bitcoin’s fungibility — the ability of each Bitcoin to be identical in function and quality.
While useful for security and scalability, covenants would change the properties of specific Bitcoin units, essentially creating different types of digital currency, distinct according to what could be spent or where it could be sent.
As a result, those who oppose the change argued that limiting how you can spend your Bitcoin would ultimately limit Bitcoin’s use as a digital currency, with inevitable consequences in its value.
There are strong opinions on covenants' pros and cons; however, debates are healthy and necessary to improve a decentralized and leaderless network. Ultimately, the final decision will be down to the users and node operators who will download the software that better reflects their viewpoint.
Advantages of Bitcoin covenants
Improving Bitcoin security is one of the most significant advances constantly sought by developers, and covenants might offer a great helping hand in enhancing it.
Besides improved scalability, covenants are helpful for security, especially against some form of the $5 wrench attack. Taking steps to protect your Bitcoin property so that it becomes harder for people to steal is an excellent use case.
Another good security approach provided by covenants would be to restrict your UTXO to be sent to a multi-sig address after a year, for example. Covenants can also address the difficulty of secure key management, and implementing secure vaults can help with one of the biggest problems of cryptocurrency security. Vaults enhance end-user security by disincentivizing the theft of coins.
The user employs a mechanism that prevents an attacker from gaining full control over funds despite stealing the private keys used to secure them. This mechanism includes the use of pre-signed transactions with key deletion to enforce a time-lock on funds.
Covenants can also implement a restrictive mechanism to prevent double-spending attacks in Bitcoin-NG, a Byzantine fault-tolerant blockchain protocol that has been recently proposed to improve Bitcoin’s throughput, latency and overall scalability.
This mechanism is translated into so-called poison transactions that can be implemented progressively as an overlay on top of the Bitcoin blockchain.
How do Bitcoin covenants work?
Covenants can be defined as linguistic primitives (the smallest and simplest “unit of processing” available to a programmer) that extend the Bitcoin script language allowing transactions to restrain the scripts of the redeeming ones.
In a typical Bitcoin transaction, your Bitcoin is protected with a locking script, whose conditions should be met if you want to spend the coins. Examples of locking conditions can be the denial of expenditure without a signature proving you have the private key that matches the public key; or timelocks, which are similar to covenants and indicate that coins can’t be spent until after a certain number of blocks.
So whereas in a “normal” Bitcoin script, we only require specific conditions to be met to unlock a particular requirement (sign a transaction with a private key, for example), in a covenant, we go a step further by restricting what you can do with that coin, or where a coin can be spent.
A Bitcoin covenant is often defined as “a mechanism to enforce conditions on how the control of coins will be transferred in the future” and includes a set of conditions on an unspent transaction[TX] output (UTXO), which defines how the transaction’s relevant coins can be spent.
For example, one wallet can place a covenant on the Bitcoin it holds whitelisting a few related addresses. When this wallet broadcasts a Bitcoin transaction to another wallet, in turn, this wallet can only send the same Bitcoin to addresses included on that whitelist.
Can Bitcoin be improved?
Bitcoin can undoubtedly be improved, and BIPs, including covenants, represent proposed changes to Bitcoin’s consensus.
Covenants are included in Bitcoin Improvement Proposals (BIPs), the upgrade and improvement process Bitcoin undergoes to modify and advance issues like scalability, security and usability.
Covenants allow a Bitcoin script language to prevent an authorized spender from spending on specific other scripts. They describe how to improve Bitcoin in smart contracts, information included in a code that executes when certain conditions are met.
These Bitcoin contracts could prevent users’ funds from being stolen in case of hacking and can also help scale the network. There are many proposed applications for covenants, from scaling Bitcoin transaction capacity to congestion control, trust-minimized loans and more. These use cases are described in the controversial BIP119, presented by developer Jeremy Rubin as a soft fork, and discussed by the community.
This Bitcoin Improvement Proposal introduces a change to Bitcoin’s code, which seeks to use a new operation code (opcode). The opcode is OP_CHECKTEMPLATEVERIFY (CTV-style covenant) and enables a limited set of precious use cases without incurring significant risks.
CTV can potentially help scale Bitcoin through the implementation of Congestion Controlled Transactions. When transaction traffic is very high, fees increase exponentially. Using this CTV, large payment processors can include all their payments in a single transaction for confirmation purposes, saving block space and resulting in faster and cheaper execution.
What are covenants?
A covenant is used in private property law as a contract to restrict an object’s use, for example, the interdiction to extend a building or change a facade's color.
Since Bitcoin is private property, the term covenant seems perfectly fitted to indicate restrictions on its transactions. You have ownership of the property but can be limited in what you can do with it.
Specifically, Bitcoin covenant proposals restrict how a coin can be spent after you bought it and where coins can be transferred. These restrictions can be compared to those that banks might place on specific merchants suspected of engaging in illicit activities.
Covenants can be useful to upgrade Bitcoin; however, since they are complex to implement and trigger controversy over the cryptocurrency’s fungibility and censorship-resistant property, they have not been seriously considered for inclusion in Bitcoin for a long time.
You can get bonuses upto $100 FREE BONUS when you:
💰 Install these recommended apps:
💲 SocialGood - 100% Crypto Back on Everyday Shopping
💲 xPortal - The DeFi For The Next Billion
💲 CryptoTab Browser - Lightweight, fast, and ready to mine!
💰 Register on these recommended exchanges:
🟡 Binance🟡 Bitfinex🟡 Bitmart🟡 Bittrex🟡 Bitget
🟡 CoinEx🟡 Crypto.com🟡 Gate.io🟡 Huobi🟡 Kucoin.
Comments