Quote from: gmaxwell on August 19, 2013, 05:36:34 PM

In general you'd provably destroy the coins in the off-chain system, in a way which binds the destruction to the bitcoin address you want to pay or in some other way visible to the off-chain users unbind them.

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 program that references the pubkey of the oracle.

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?

Quote from: gmaxwell on August 19, 2013, 05:53:55 AM

This CoinWitness idea is something of a less ambitious example of what Eli suggested in his talkeffectively running blockchain validation under SCIP to produce UTXO checkpoints that have cryptographic proof of their correctness. But instead of validating all transactions from a public blockchain, here I suggest validating small sequences of private transactions to avoid ever making them public at all and, in doing so, improve the scalability, flexibility, privacy, and fungibility of Bitcoin. (And, in fact, this idea may in fact be trivially obvious to those working on the SCIP tools, but I expect it will blow some minds here).

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.