The path to general computation on Bitcoin (with OP_CAT)

The email provides a critique and analysis of a blog post discussing Bitcoin's Unspent Transaction Output (UTXO) model, locking scripts, smart contracts, and particularly the concept of covenants within the Bitcoin network. The sender expresses concerns about various aspects of the original post, including the clarity and accuracy of terms and concepts presented.

Firstly, the sender questions the necessity of explaining the UTXO model and locking scripts to the presumed knowledgeable audience of the post. They point out that while Bitcoin scripts are not inherently stateful, the capability to handle evolving states through indexers and trackers was not adequately covered. Specifically, the discussion on how Bitcoin nodes could evolve to store state information directly or whether there is a need to integrate covenant trackers into nodes is highlighted as missing. The critique extends to the post's use of the term "covenant" over "smart contract," suggesting an avoidance of the latter term due to its vague definition in the context of Bitcoin. The sender argues that the post fails to demonstrate how new transactions could be automatically triggered under the proposed implementation, a feature they deem essential for full smart contract capabilities within Bitcoin.

Moreover, the critique addresses the absence of a detailed explanation of proof computation in STARK models and a general definition of STARK, which the sender considers more critical than reiterating known information about the UTXO model. The sender also challenges the claim made in the original post regarding the ability to build general smart contracts on Bitcoin based on the described covenant system, pointing out the lack of a precise smart contract definition and the mechanism for automatic trigger of such contracts.

Additionally, the email brings up the use of OP_CAT for concatenation and questions its necessity for covenant implementation, suggesting that states could be stored using other output types like Pay2WitnessScriptHash (P2WSH). The sender asks for clarification on how the Schnorr trick compensates for the absence of address tweaking and how state tracking would be managed at the node level.

A specific implementation is referenced, namely the Circle-STARK verifier with a working demo that verifies a STARK proof of a statement related to Fibonacci numbers on Bitcoin signet, accessible through a provided link. This serves as a practical example of where states can be verified.

Finally, the sender criticizes the repeated mention of Bitcoin smart contracts throughout the original post, labeling it as "horrible and factually wrong" and suggests sticking to the term "covenants" to accurately describe the discussed concepts.