The way I understand Bitcoin, value is transferred around by crytographically signing a transaction to prove that you have the private key. This requirement should prevent the CV Token network from "collapsing back into bitcoin" when the backers fail to act.
For CV tokens to work, they must do one of two things:
- Store private keys in the network. This is bad because a bad actor can simply use those private keys to send coins to themself.
- Somehow transfer value in and out of the bitcoin network without using private keys. This is bad because it breaks (at least my) fundamental assumptions about how the protocol works.
I admit, I am not as familiar with the gory details of the Bitcoin protocol as I would like. It is possible that there is something that I am missing. So far Croesus has refused to give concrete details, citing complexity.
There are definitely more ways than that to transfer value around in Bitcoin, though they aren't as well known. You can use scripts to build complex conditions which must be satisfied, and then anyone who can satisfy them can spend the coins. Just off the top of my head:
-you can build transactions that anyone can claim (has actually been used)
-you can build transactions claimable by some subset of a group of keys ("m of n" signing, actually in use)
-you can build transactions which can be claimed by anyone who knows a secret password or piece of data (could be a file, a word, or an answer to a math problem, not just a private key corresponding to a public key or its hash, and has also actually been used)
-you can build transactions which go to the first person performing some amount of computational work, similar to how mining works (but separate from it)
-you can build transactions that no one knows the output of until they are spent (pay to script hash, where the transaction only has a hash of the script and the person collecting the transaction has to provide a script that hashes to that hash when spending it. I believe this is already in use, but I'm not sure)
-you could build a transaction that could only be claimed by the owner of a certain pgp key (might be a big script, don't know how efficiently you could implement RSA signature verification in transaction scripting)
-you can build a transaction that isn't valid until after a certain time
-you can build a transaction which only becomes valid when someone else adds more money to it
-you can build a transaction with a sequence number which can later be replaced with a later sequence number
-you can build transactions where a portion of it can be modified later without requiring a new signature as long as the part that was signed remains unchanged
-you can build transactions that can be updated repeatedly without publishing them to the blockchain, and then only publish the final copy when all is said and done
and lots more I'm sure I'm forgetting. Satoshi built a ton of cool features into Bitcoin--we just have most of them turned off right now because there aren't any commonly used use cases so it isn't worth the risk that the feature has been improperly implemented in one or more clients/miners and might result in a security exploit.
croesus has been light on details, but what she/he describes seems technically possible to me. Just take a look at the contracts page on the wiki and you will find a whole slew of things that can be done with transaction scripting.