there’s a lot of talk about “covenants” but not a lot of understanding what that entails. lets do a little dive into how i think about the opcode proposals and how they relate to “enabling covenants on bitcoin”

what is a covenant?

great question. a covenant is the ability to specify what the transaction that spends your bitcoin must look like. for example, you could say “the transaction that spends this bitcoin must pay 500k sats to this address” or “the transaction that spends this bitcoin must have a locktime set to block 880,000”

in order to make these kinds of assertions in bitcoin transactions, you need the ability to find out what information is in the transaction that is spending an output. this information needs to be accessible when the script is running.

bitcoin script is a limited programming language that you use to write locks for bitcoin. one of the limitations is what data you have access to while the program is running.

so in order to write more “expressive” bitcoin scripts, which can say “one output must be to my address and pay 500k sats”, for example, you need to be able to look at the outputs on a transaction.

this ability to look at the info on a transaction is called “introspection”. being able to introspect a transaction is a big missing piece in bitcoin. adding introspection enables you to write covenants.

so how do you get introspection in bitcoin script?

you have to add a new opcode for it. in fact, we’ve added two opcodes to bitcoin that enable introspection already: op-checklocktimeverify (op-cltv) and op-checksequenceverify (op-csv)

these look at the locktime/sequence of a transaction and require a certain value to be set in order to be valid. they were added in order to enable lightning, which uses both op-cltv and op-csv to make “primitive” covenants. these were added to enable LN, to help scale bitcoin.

today you could write a bitcoin script that asserts “the transaction that spends this bitcoin must have a locktime set to block 880,000”. you’d use op-cltv to make that script, and any coins locked to that script wouldn’t be spendable til block 880,000.

there’s no way to look at the output fields in a transaction though. you cant write a script that requires funds to go somewhere, you’d have to use presigned txs (like how lightning does) to make that kind of assertion.

ok so the goal of introspection is to let you look at what information is in a transaction that’s spending a bitcoin output. we can do this already with op-cltv and op-csv. but this is limited just to timelocks, and doesn’t let us make assertions about outputs, or other inputs.

in the next post i’ll talk about how the current opcode proposals (op-ctv, op-txhash, op-tx, op-cat) work and how they enable more broad tx introspection !

if you found this interesting, check out nostr:npub1vmpf90hq56wzyxht6teg3llpa74rzcepw9suj5unxl3tph24zd4qgtxhm7 and our classes on bitcoin transactions!