Right, I see now. The thing that I missed is that you'd provably destroy the coins in the off-chain system. So for example in the anti-replay oracle system, the proof of destruction will be of a computation that includes a signature by the oracle that he considers the coin to be destroyed, so when a user initially sends a coins into this off-chain system he sends it to a SCIP compiled program that references the pubkey of the oracle.
The oracle doesn't have to know the coin is destroyed, though it could if you wanted to. In my example the coin is just paid to some hashed destination as far as the oracle can tell (well, technically the oracle doesn't even know there is a coin: It's just timestamping some data with a prefix that its never seen before). Other uses of the off-chain system know that destination isn't them, and thats sufficient to prevent double-spending. The witness knows the destination is Bitcoin because the redeemer provides the nonce. The distinction isn't super important, but it does inhibit certain kinds of DOS attacks (like the oracle refusing to let you take coins out of the system and put them back into Bitcoin).
But why do you say that it's a soft-fork? Isn't it true the current Bitcoin nodes cannot verify such proofs-of-computation, and therefore they will disagree with the newer nodes regarding whether the transaction of the user who exited the off-chain system is valid, so the network would split unless the older nodes upgrade?
Correct. A soft-fork change is one which strictly decreases the set of valid transactions. Old nodes accept valid ones under the new rules, but they also accept transactions which are invalid under the new rules so the network risks diverging unless at least a significant super-majority of mining hash-power enforces the new rules. We've made soft-forking changes a number of times, and I think we can make them pretty safely... or at least will continue to be so long as there remains a single codebase used for the full-nodes behind almost all mining. But they are still inherently risky and imply a long term commitment to the change and a public consensus to make it, so they can't be made lightly or experimentally.
Yes, this new idea has much more beneficial properties (compared to just "compressing" the blockchain in order for nodes to be able to get UTXO checkpoints in a trustless manner, instead of getting the entire blockchain history from archival nodes). From what I know, I doubt that this idea was trivially obvious to anyone before now. If I remember correctly, you've said in the past that the properties that this kind of system can accomplish is what Ripple should have tried to accomplish.
There are many neat off-chain systems possible including ones with really good scaling properties (e.g. no global consensus, indeed what ripple could have been before the change in ownership), but even when they are themselves zero-trust or nearly zero-trust getting value in and out of Bitcoin without trust is a hard problem. I hope here that I've shown a potential tool we could employ to address that challenge.
New cryptographic tools make many things possible which were unthinkable before. Someday people will look back at the things we invent between then and now and with a surprised tone exclaim "What? wasn't that obvious??", as some do even now about Bitcoin itself. I thought the idea was interesting, or else I wouldn't have posted about it but I can't deny that at least half of the idea comes from simply having a basic understanding of these new tools. The potential to make
easy discoveries like this is why tools like SCIP and Bitcoin are the new frontier and thats one reason I enjoy thinking about them and working with them.