Covenant: A generally formal, solemn and binding agreement.
This word has become one of the most loaded words in the Bitcoin space. They are the best from sliced ​​bread. They are the most dangerous from the atomic bomb. They really are not going to do anything to climb Bitcoin, but they are fine.
Everyone has a completely different attitude towards them. We have the Pro faction, the faction, the ambivalent faction. To worsen things, the pact is frankly a very vague term in its description of mature and concrete proposals to the protocol that would be classified as agreements.
The degrees of difference between the functionality of different proposals that have been presented are huge. Some of them create completely new design spaces for which it is possible to build on Bitcoin, while others strictly speaking do not add any new functionality, simply optimize things that are currently possible with a large degree of complexity and general expenses.
We believe a new specific definition for Bitcoin.
Covenant: Any script that guarantees some, or all, of the outputs created by a transaction that spends an entry with a pact script will have to adapt to certain specified criteria so that the spending transaction is valid of consensus.
Then, in less strict terms, if a bitcoin script currently restricts WHO You can spend a currency demanding an authorization test, that is, a cryptographic firm, or when It can be spent, that is, after an expire timelock or the speaker can show the preimagen to a hash, a restricting pact script as It can be spent, that is, to whom, how much of which person, etc., a pact script can even restrict a currency so that it should be spent to another pact script.
That last part is the core of what has turned the pact into such a contentious word. Many people have great reservations about adding a new way of “blocking” bitcoins that can self -propel and ensure that future currencies are similarly restricted. Many people are concerned that this is used to damage the fungibility or censorship regimes of the institute.
I feel that it is necessary to point out that both can be achieved at this time, without covenant of pact commands, simply using Multisig. Any authority can refuse to allow retreats to be processed from exchanges unless they are a multisig of 2 of 2 where this authority has a key. From there, they can simply refuse to sign transactions that are sent to addresses where they do not have a required key, and establish any blacklist scheme or the white list that wish opaciously and completely outside the chain.
That said, it is still important that Bitcoin users have an understanding and understanding of the power and flexibility difference between all the different pact proposals that currently exist.
There are two central things that agreements seek to enable restrictions to as coins are spent, introspection and Reheat data.
Introspection is the ability to inspect different parts of the transaction that is being evaluated while trying to spend a specific currency. Then, for example, if you want to restrict a currency so you have to spend in a specific direction, you must compare the address specified in the script of the entrance pact with the specified address at the output of the transaction that spends it. The operation codes that enable introspection are those that give us the ability to compare different parts of the spending transaction against the restrictions included in the script that is being evaluated. The more granular can obtain with introspection about which particular parts of a transaction can examine, the more powerful it will be.
The transport of data forward is related to introspection and, in many ways, a consequence of this, which allows you to ensure that some information is carried out and included in each new script of the pact so that it can be used in the next evaluation of the script of the pact. This is achieved through the use of introspection to restrict certain parts of the transaction so closely that they must include the desired exact data or are not valid. The more powerful the introspective capacity, the more flexible the data can carry forward and, the more flexible, you can use that data.
This is only the first introduction to a series of articles that will arrive in the coming weeks analyzing all the main pact proposals that are in a mature state, have received a recent interest or are conceptually critically important enough for developers to agree on their usefulness but that is not yet a specific design. This will not be 100% complete, but it will be relatively complete. Some of them are not strictly agreements per se, but are very well composed with them.
These will include:
- Check
- Checksigfromstack
- Shit
- Op_vault
- Verify Contractverify
- CAT
- Tweakverify
