Is it possible to design a new opcode enabling recursive covenants that could result in a full node stuck in an infinite loop of verifying transactions? (Obviously this would never be considered for a Bitcoin soft fork, I'm just wondering about the limits of the design space for covenant opcodes)
e.g. A -> B -> C
A, B, C are transactions. B spends A, C spends B. A imposes constraint on spending conditions of B. B imposes constraint on spending conditions of C. But the spending conditions of C have to check something in A (something that wasn't hashed, perhaps the first few bits of a signature in the witness). As a result of that verification B has to check something in A and the infinite verification loop is set in motion.
I'm leaning towards no but not 100 percent sure. It isn't enough for C to check something in A, it needs to change A in some way such that B needs to verified again. This might even be prevented by the UTXO model (versus account model). In an account model you could refer to the balance of any previous block and get into an infinite verification loop that way.