Hello, Thanks for your work and your post. I have several remarks to your post.
First, you remind what is UTXO model and locking, that’s cool but doesn’t seems useful in this place. I hope most of readers here are aware about this.
This assertion is true but it can be done through Indexers and trackers. You don’t specify in your post how a Bitcoin node should evolve to handle such states and how you’ll be able to handle those evolutive states in Bitcoin (node). Do node will directly store each states? Do we would need to build covenants trackers into the node?
The use of term covenant looks especially crafted to avoid the use of “smart contract” (SC) term which is not well defined especially in this case. Will you be able to trigger automatically new transactions with your implementation? I don’t think so, and this implies that the “smart contract capabilities” are not fully embraced. We don’t have OP_CALL on Bitcoin and as with OP_CAT we won’t be able to trigger from the protocol level new transactions (or at least it’s not discussed in your post).
This can’t be assumed as long as there is no precise definition of a smart contract in the post and the automatic trigger of a SC is not shown.
You remind what UTXO model is but you don’t explain the proof computation in STARK models neither a general definition of STARK which seems more important.
Do you mean the Bitcoin covenant?
Where does this value come from?
All the previous sections mention SC/convenants but never OP_CAT does it mean that covenants can be done without OP_CAT?
Does it mean that your covenants will be implemented in P2WSH? How exactly the Schnorr trick compensates for the absence of address tweaking? How state tracking would be managed at the node level?
Where states can be verified?
Please stop mentioning Bitcoin smart contract it’s horrible and factually wrong. We have a word for this it’s covenants.