Covenants

[ProofOfKeags]

I think it's worth describing the problem in since a lot of covenant proposals are currently being discussed. Especially since one of the only two NACKs for CTV was on the grounds that the research space hasn't been adequately explored. Obviously the problem statement need not include anything to do with CTV.

I was thinking something approximating:

Bitcoin's scripting system has numerous opcodes that you can use to build conditions on spending inputs, however, once you can spend the input in question, there is no limitation on the output set for that transaction. "Covenants" refers to a means of allowing inputs to restrict the allowed spend destinations of an input to a subset of all possible destinations.

[LLFourn]

Hey Keagan,

Thanks for getting this conversation started. I had tried to think of how we should describe the goal of the problem. I think it's to come up with covenants system that is simple, flexible, efficient, enables all sorts of goodies and ...everybody likes it! I'm struggling to come up with a better way to define the scope. Any ideas? +I have a feeling that such a thing is impossible but I guess it's worth seeing if someone can do it.

Bitcoin's scripting system has numerous opcodes that you can use to build conditions on spending inputs, however, once you can spend the input in question, there is no limitation on the output set for that transaction. "Covenants" refers to a means of allowing inputs to restrict the allowed spend destinations of an input to a subset of all possible destinations.

Here's my attempt at a less abstract take -- not sure if it's better!

At present, the only constraint an output can put on the its spending transaction is that a certain group of entities signed it or that it can only be valid after a certain time. A covenant scheme would make it possible to additionally constrain the spending transaction based on its outputs. The covenant may even require that the spending transaction has another covenant output which continues the covenant perhaps until some condition is reached (or forever!).

If you feel inspired to write this problem then please go ahead. Otherwise we can use the issue to collect related research for now. Here's some to get started:

1. https://arxiv.org/pdf/2006.16714.pdf -- Deleting keys (for trusted hardware)
2. https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf -- CHECKSIGFROMSTACK
3. OP_CAT enables covenants: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
4. JR CHECKSIGFROMSTACK ML post: https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg10211.html
5. TLUV: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html

[ProofOfKeags]

Overall I think your description is a better one for an intro, though I'll make a couple of adjustments:

Original text:

At present, the only constraint an output can put on the its spending transaction is that a certain group of entities signed it or that it can only be valid after a certain time. A covenant scheme would make it possible to additionally constrain the spending transaction based on its outputs. The covenant may even require that the spending transaction has another covenant output which continues the covenant perhaps until some condition is reached (or forever!).

Edited:

At present, the only constraint an output can put on the its spending transaction is that a certain group of entities signed it, it can only be valid after a certain time, or a secret must be revealed. A covenant scheme would make it possible to additionally constrain the spending transaction based on its outputs. The covenant may even require that the spending transaction has another covenant output which continues the covenant perhaps until some condition is reached (or forever!).

To assess whether it's better we probably have to define the audience. In my mind, if these are open research problems we shouldn't necessarily shy away from formal statements of the problem. That said, the introductory statement should still convey intuition I think.

[LLFourn]

At present, the only constraint an output can put on the its spending transaction is that a certain group of entities signed it, it can only be valid after a certain time, or a secret must be revealed. A covenant scheme would make it possible to additionally constrain the spending transaction based on its outputs. The covenant may even require that the spending transaction has another covenant output which continues the covenant perhaps until some condition is reached (or forever!).

Ah so this is interesting. I thought about that myself but in the end came to the conclusion that secrets being revealed isn't a constraint on the spending transaction if you conceptually separate witness data from the transaction itself. You could argue that time locks aren't a constraint on the spending transaction either but because of the way they are implemented they actually are -- CLTV and CSV check the locktime field or the sequence number are above certain values on the spending transaction (they don't actually check the time directly at all). Maybe bringing this implementation quirk into the low resolution opening sentence here was a mistake.

Further thoughts on capturing the problem: perhaps the best way would be to list applications that should be possible with the problem solved. What about non-interactive setup of an oracle contract: I can just post some cryptogrpahic data somewhere online and anyone can come and grab it, finish funding it and broadcast it and then we've got a bet.

[ProofOfKeags]

So it is true that Covenants themselves are a constraint on outputs, and not really on the witness. But any constraints are still advanced through the scripting system which takes into account aspects of the transaction itself as well as the witness. While CLTV is checking an aspect of the transaction rather than the witness, it still provides a means for the input constrain how it shows up in a full transaction. To me the defining characteristic of a covenant solution is that it allows you to constrain outputs to a smaller set than the set of all outputs. How good the covenant system is is related to the following question: given an arbitrary subset you wish to constrain to, what covenant system has the best chance of most concisely expressing that subselect.

Generally speaking the scripting system in Bitcoin, I think, aims to approach defining a predicate on the entire transaction (including the witness). The script VM operationally doesn't look like this since it's very laden with the operational semantics of the stack mechanics and sequencing of opcodes, but the desired API it provides is allowing users to define arbitrary predicates on the transaction that spends the input.

I think for the purposes of stating the problem, we should try to state it in its most general form, though perhaps not in the introductory paragraph. That said, the problem also needs additional constraints, since I think any serious covenant proposal cannot alter some of the main assumptions of Bitcoin (UTXO model must be preserved, cost of verification must be bounded without execution of any part of the script + witness).

I think selecting useful problems in the world that it solves is important to score the overall system but I think it is appropriate in a research forum to have the goal being more generalized than specific use cases. A good covenant system must solve a large number of practical problems we have today, but generalizing the system will give us the ability to solve problems we have not yet encountered.

[LLFourn]

A treatise on covenants that seems relevant: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020225.html

[ProofOfKeags]

OH very much so. Coming up with a computational model for covenants separate from the implementation of them in the current Bitcoin Script VM is pretty important to be able to conduct security analyses. Having that fundamental algebra, and theorems around it are what allow you to prove expression equivalence and allow you to scale your assumptions safely. I actually think this ought to be the primary area of investigation when it comes to the scope of problems represented by this site. I don't necessarily think it's a prerequisite for having certain covenant proposals activated, but being able to evaluate them against the same theoretical model is going to be helpful.