Thank you all for your comments.

dacoinminster I will take a look at your whitepaper.

grebit I posted the thread here because it seems to fall under "technical discussion"--if that was inappropriate I am happy for it to be moved.  At present I am only offering a description of cvTokens.  If the whitepaper is well received and a development effort begins, I can post a thread under "project development" instead.

phillipsjk I have kept the description of cvTokens light on technical details because an actual implementation with existing transaction scripts is exceedingly complex by comparison to cvTokens themselves, and I did not want to distract from the main concept.  By "existing transaction scripts" I mean the full set of scripting operations currently available on testnet3.   With that caveat, here are some answers for you:

• There is no m of n signing as a control mechanism in cvTokens.
• No private keys that control bitcoins are held in the network or between multiple parties.
• The structure which allows bitcoins to be claimed by the relevant parties is created by the original BTC holder during the backing process, and a correctly formatted structure is also the definition of becoming a backer--otherwise the resulting cvTokens will not be considered fungible by cvToken users.
• Although the coloured bitcoins used as cvTokens can be handled by normal coloured coin software following proper validation (because it will preserve the colouring), a small amount of additional code is required to differentiate valid cvTokens (with a correctly structured backing composition) from correctly coloured but invalid cvTokens.
• An implementation of the rolling auction inside of the blockchain requires horrendous amounts of space.
• cvToken minting and cashout operations in existing script implementations require very large transactions and for this reason cvTokens must be cycled back through cashout and minting every x spends, or cashout operations will become too large to create a transaction for.

At this point it should be fairly obvious that I prefer not to implement cvTokens by using existing transaction scripts.  My hope is rather that, should the Bitcoin community see value in cvTokens, there would be little resistance to the addition of new transaction scripts which place minimal load on blockchain verifiers such as miners and full nodes.

Some new script operations that would make cvToken implementation easier while still yielding broad utility for a diverse set of use cases include:

• A coloured coin membership test
• Timing and time-out operations within transactions
• Ancestry tests
• Operations on previous transactions, referenced by transaction hash
• Several items from the hard-fork wishlist (output malleability, generation modifications, timejacking fix)

Regarding the window for backers to meet pay-out requests, this is a balance between the rate at which cvTokens can respond to a crisis and the corresponding demands placed on backers.  Most likely backers would be allowed to set the value themselves, within reason.  Alternatively constraints on this window may be set by the first backer of a new cvToken (along with several other "magic numbers" in the protocol) according to the intended use of the token.

When all backers fail to intervene in the pay-out process, the structure of their original backing transactions allows holders to claim the collateral themselves.  Without going into too much detail about this, please refer to the example here.

Because of the many possible ways to implement cvTokens, I would request that further questions focus on the protocol description itself rather than on particular ways the protocol could be implemented.  I hope that an astute reader will note an implementation is at least possible even if currently difficult and subject to change.  The only other important thing to note regarding implementation is that implementations need not be inherently expensive computationally speaking--the main downfall of Zerocoin, for example.