Hard to forbid or impossible to forbid? Instead of OP_CHECKSCIP, can there be a way to incorporate SCIP into Bitcoin scripts in a way that disallows covenants?
Hard/ugly not impossible. Don't allow a transaction with a SCIP checksig to pay to a SCIP scriptpubkey, and don't fix the fact that there is no sighash flag that lets you built a transaction that can only ever be spent by one other. (otherwise a covenant could require you to form every output as two-stage "you must pay to a future transaction which has the required SCIP code").
I keep thinking that it's possible to pass the output data being signed through some kind of malleable encryption so that the signer, and only the signer, can substitute the ouputs... but every system I've come up with is either insecure (third parties can replace the outputs) or can still make a covenant (as they only make a single replacement possible, and a covenant could require you to construct two candidate outputs and then make sure both meet the covenant criteria).
I don't currently think we should forbid covenants, though perpetual ones are utterly moronic. Ones that last one or two transactions sound useful to me... and the considerations required to forbid them are too ugly.
I failed to understand (for example I have no idea why you said "lie about their time"), could you please try to explain the above in a way that might be more clear?
One thing that I can see is that the Bitcoin script language could be extended to include a new opcode (unrelated to SCIP) that puts on the stack the timestamp of the block in which this transaction resides, and similarly an opcode that puts on the stack the timestamp of the previous block (relative to the block in which this transaction resides), and then bind the SCIP program to use these two public inputs, and the SCIP program would be completely trivial i.e. it would just check the difference between its two inputs. So except for enforcing the covenant, SCIP isn't needed here, because the regular Bitcoin script can directly check the condition on the difference between the two timestamp values.
Yes, everything that doesn't require zero-knowledge could be instead done with a sufficiently powerful script. SCIP avoids the complexity of implementing every possible interface you might want and then executing in those things in the network.
WRT lie about the time: Say you do something (e.g. a OP to provide them as public inputs, or better to compare them to static values and fail the transaction, and provide the static values as public inputs) to make the times visible to the SCIP so the SCIP can test them. The SCIP validation isn't execution, it's verification of a witness, and you cannot change the inputs to ones other than the prover used. While you might happen to pick a convenient time that wouldn't be a lie, if the transaction ever gets mined it likely will be due to a lie. (and, practically, no one is going to accept dynamic data as TX validation inputs, no one wants to ever run validation more than once per network block per transaction).
Another thing that I can see is that the specified SCIP program (verification key) will have the hash of the genesis block (or a more recent checkpoint block hash) hardcoded into it, and will receive non-public input which is the all the next blocks, and the SCIP program checks that the entire hash chain is valid, and fetches the timestamp value from the last block that it hashed.
Thats not a great way to do that, because it doesn't bind to a specific chain. For example, say it started at the genesis, I could just mine a diff 1 fork which met whatever criteria you wanted. If you want to do something to bind a chain I suggest an opcode which you use to push a header hash and max_distance, and iff its valid in the current chain the value gets combined with the data being signed. Otherwise, the transaction fails. This way the SCIP-script can know that a specific block (and all blocks before it) is in the chain. I don't see any way to get tests on _this_ block except by opcodes that push constrains on this block.