Quote from: gmaxwell on August 19, 2013, 07:31:20 PM

Quote from: iddo on August 19, 2013, 06:46:21 PM

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

Right, I wrote it less clearly than you. So the oracle only prevents double-spending in a generic way and he's oblivious to the fact that he assisted to destroy the coin, but the signature that the oracle provides for the particular off-chain transaction that destroys the coin is required for the verification (by Bitcoin nodes) to pass when trying to redeem that coin back into the Bitcoin network.

Quote from: gmaxwell on August 19, 2013, 07:31:20 PM

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.

Maybe the distinction between soft-fork and hard-fork is less important than I thought, but I'm still a bit confused on why this is a soft-fork. With regard to a valid transaction that passes the SCIP verification (from the off-chain system back into the Bitcoin network), can you please explain why the older nodes would consider it to be a valid transaction? If that's the case, it means that the older nodes would allow anyone to spend such outputs, without checking anything at all?