The path to general computation on Bitcoin (with OP_CAT)

[victorkstarkware]

@Laz1m0v

This assertion is true but it can be done through Indexers and trackers.

Not sure what “it” means here

@Laz1m0v

Do node will directly store each states? Do we would need to build covenants trackers into the node?

The state is stored onchain. You would need to track the transaction at the tip of the “smart contract” chain

@Laz1m0v

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.

@Laz1m0v

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.

There is a loose definition for “smart contract” in the text:

A smart contract here means some sort of stateful logic, with a collection of functions that can be invoked to transition the state to a different, valid one, according to predefined rules.

@Laz1m0v

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).

Correct, this “smart contract” doesn’t have all the capabilities of smart contracts from other blockchains. I am open to suggestions for a better name for this functionality (i.e. an SC but without the ability to call other SCs)

@Laz1m0v

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.

There is whole discussion dedicated to proof systems and delegated computation (of which a STARK is a particular example) in Section 6. Going into more details about STARKs specifically is distracting in my opinion.

@Laz1m0v

Do you mean the Bitcoin covenant?

No, I mean a smart contract as loosely defined above.

@Laz1m0v

Where does this value come from?

From StarkWare, whose proof systems in production have settled over $1T

@Laz1m0v

All the previous sections mention SC/convenants but never OP_CAT does it mean that covenants can be done without OP_CAT?

See the text in the introduction:

Finally, we’ll discuss OP_CAT and how it enables the tools mentioned above. We’ll also reference some of our efforts in this direction and discuss what’s to come.

I don’t know how to achieve the same type of construction with other opcodes, see my comment to moonsettler above.

@Laz1m0v

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?

Not sure I understand the Schnorr trick question.

Regarding state tracking, there is a freedom of choice on where to store the hash preimage. If it is small, you could provide the hash preimage in the tx witness. If it’s large, perhaps it needs to be split across multiple tx, which is also doable and out of scope for the article.

@Laz1m0v

Where states can be verified?

Not sure I understand the question

@Laz1m0v

Please stop mentioning Bitcoin smart contract it’s horrible and factually wrong. We have a word for this it’s covenants.

I disagree. A covenant is a well-known concept that is used as a tool to build smart contracts, as loosely defined above.