Quote from: edmundedgar on May 16, 2013, 11:14:05 PM

OK, so it's regular human-run escrow with some trusted people who have access to the money? (Possibly mitigated by useful Bitcoin features like multi-sig, so the people running the escrow can't steal the money without cooperating with each other.)

That makes sense now, I was confused because for some reason I was expecting something a bit more cyber... And that also answers the riddle of how the exchange rate information gets into the system: The humans in charge of the escrow check it, using publicly available data and common sense.

No. No humans. No trusted people. No one is "in charge of the escrow", any more than there is "someone who agrees that m signatures are present in m of n signing" or "someone who agrees that a zero-knowledge proof has been submitted in zerocoin." It is only the case that, due to the special way the relevant "escrow deposit" and "cash-out attempt" operations were formulated, a period exists for each entity in that chain of events to preclude the next step from happening. When they do not do so, we say "the escrow seizes control" or something to this effect merely as a useful oversimplification. In actuality these other possibilities were written into the structure of these earlier operations, and only "take effect" because certain key entities did not exercise an opportunity to preclude their validity. To see an example of the type of complexity we are avoiding, consider something like the following:

Bill creates a transaction anyone can spend, and with nLockTime far in the future. He signs and posts it in a private forum for miners (rather than publishing it to the Bitcoin network). Next Bill creates a conflicting transaction to Joe which can be spent with any two of Stacy's, Alice's, and his signatures, and gives it directly to both Alice and Stacy. We could describe this situation as follows:

1) Some money is "in escrow" for Joe.
2) Bill can cancel the escrow.
3) Alice and Stacy can award it to Joe.
4) Any miner who doesn't like Joe can donate it to mining efforts instead.
5) If Alice and Stacy don't give Joe the money by some approximate time, the escrow goes to a miner instead.

Notice that in step 5, no one is really deciding this at that time. It's merely what will invariably occur with attentive, self-interested parties. Similarly, no one is "deciding" to reassign the escrowed funds for a cvToken--there's just a situation of transaction inter-reliance created so that the appropriate outcome will invariably occur with attentive, self-interested parties.

This example is substantially simpler than how cvTokens would have to be implemented with existing Bitcoin transaction scripts, which is why I offer it.