Topic: cvTokens - Stable currency without trust (Read 4081 times)

 the user 'bytemaster' had something along these lines: https://bitcointalksearch.org/topic/m.2263515

 -bm

Yup! But it's not a deal-breaker. Upon further consideration, I realized it's just another form of "you have to pay to put data in the block chain" which is fine. It doesn't prevent message-based protocols from working.

But back to this thread: I'm really looking forward to reading the whitepaper!

I was thinking you would follow this up by agreeing with me.  If you want liquidity, you should only allow issuance of one type of uniform cvToken.

It would be great if bitcoin could be the basis for your project. But it can't... So it is either a) not in bitcoin or b) not at all.

@bunicula @dacoinminster  Stability is achieved via liquidity.  Therefore Bitcoin, as the most liquid cryptocurrency, is really the only obvious choice for basing a cvToken.  No altcoin currently has the liquidity to support any decent volume of cvTokens, much less the responsiveness to handle a rapid growth in demand.  These ideas of alternative incentives are interesting, but I believe that simplicity is paramount.  One simple economic model will be difficult enough to explain and validate, without adding many other experimental aspects on top of it.  Like Bitcoin, if the main concept succeeds there will be plenty of alternative approaches tried.

@phillipsjk I can assure you cvTokens are not a scheme to burn developer time.  They are not even ready to be implemented--that will need to wait until the whitepaper has been published and received significant review.  You are right about code being a simpler explanation, however, and the next step will be to design a simple code model that allows hands-on examination of the cvToken principle.  When it is completed I believe that many of the questions raised here will be easily answered.

Are you aware of this pull on github (#2577: Treat dust outputs as non-standard, un-hardcode TX_FEE constants)?

I called your proposal a "colored coin" proposal because it is built upon moving satoshis around. At current fees in the default client, moving those satoshis around costs 5430 satoshis. That tiny price will quickly add up if you try building stuff on top of the standard protocol.

Edit: to answer my own question:

The interesting thing about building on top of the bitcoin protocol is that it doesn't really matter if it is a good idea or not - there's really no way to prevent it from happening. Therefore, it will happen if someone is willing to pay the tiny price of having their experiment encoded in the bitcoin block chain.

Also, my paper is not about colored coins, although the same arguments apply.

You may be correct. I didn't want to mention my conspiracy theory until I had at least shred of evidence. (Essentially I was thinking these Decentralized exchange related threads were part of an Intelligence operation to burn developer time: each proposal sounding promising, yet being flawed in a specific pre-determined way. With the lack of technical detail I may have jumped to conclusions.)

I believe this situation is why pseudo-code was invented. You don't have to explain the logical steps with a real scripting language.


I don't think coloured coins are a good idea. I have no problem with alternate, niche block chains. If they fill a valid niche, they will not die out. That, and failed experiments don't have to be stored forever in the Bitcoin block-chain (as would be the case with your coloured coin proposal).

I disagree strongly. There's nothing about this proposal which requires an alt coin. Also, the consensus of the community is rapidly converging on something like this, and even if the majority never agree with Croesus, everything described here can be built right on top of bitcoin, no hard-forks required. Consensus is not required to build on top of bitcoin.

I am a little worried that the proposal may be relying on advanced scripting features which may not be well-supported by the bitcoin network in the future. I hope Croesus will do something a bit more future-proof in a completely new protocol layer rather than trying to leverage advanced bitcoin features. Then he can sell us the "coins" of the new protocol layer we could all be investors!

But maybe that's just me trying to influence him to implement MY idea instead of his idea

3) A more elaborate suggestion: Consider this.

There are three types of cryptocurrency: "A coins" = vanilla coins for backing cvTokens; "B coins" = cvTokens of a single, hard-coded, type; "C coins" = shares in cvToken txn fees.

Regardless of liquidity, the B coin is automatically convertible into the A coin at the market exchange rate (measured via some average of recent distributed auctions or other means). A coins are not convertible into B coins, except through market purchase (via distributed auction or other means).

On initial creation, B coins are backed by n times their market value in A coins. Say n=2 or n=5. Thus, B coin holders are insured against adverse movements in the A vs. B exchange rate. Due to convertibility, they are also insured against illiquidity in A vs. B coin order book. (To discourage excess issuance, perhaps B coins should suffer demurrage at a rate of 1-5%/year. Not sure about this.)

B coins and C coins are created simultaneously using A coins. To create 1 B coin and 1 C coin, holders of A coins escrow n times the market value of a B coin in the blockchain. The C coin entitles its owner to a share in all txn fees associated with transfers of B coins.

Consider incentives here. Collectively, C coin holders earn something like a tax on transfers of B coins (say 0.1%). If B coins have a stable USD price relative to A coins, they are likely to dominate A coins as unit of exchange. People will buy stuff with B coins and write contracts in B coins, generating tax revenue. Meanwhile, investors will hoard A coins as an investment asset.  

If I own enough C coins,  I will want to try to stabilize the USD value of B coins to promote their use as a unit of account. C coin holders will a) Buy up A coins and convert them to B coins when demand for B coins increases. b) Buy up B coins and convert them to A coins when demand for B coins falls.

Ideally, the number of B coins will fluctuate a lot in % terms, but the USD value of B coins will not.
A coin numbers will fluctuate too, but there should be a large enough issuance of A coins so that these fluctuations are small in % terms. Instead, A coins fluctuate in USD price, absorbing the lion's share of changes in the entire systems market capitalization.

[Note: The idea of giving token issuers a share in token txn fees is a good one, even if the above scheme has problems/needs lots of work.]

My views on this:

1) This will not attract interest the immediate interest you want. It is far out of left-field, complex, and against the principles of a bunch of people in the bitcoin community. I mostly agree with you, but few others will. Develop this separately in an altcoin, designed specifically for this purpose. If that works out, then perhaps you would have better luck persuading bitcoiners.

2) In the alt coin, force users to make 'cvTokens' of one single type. A single backed unit of account would be a) simpler to implement b) easier to understand c) more liquid. Scale is essential for the tokens to be useful. Generality is elegant and all, but usefulness should take priority here.

You seem to misapprehend me.  cvTokens are certainly possible to implement--however I do prefer not to spend too much time on the details of an implementation which will be inefficient.  Also, your third statement is simply incorrect.  I hope that if I explain why you will understand that my preference towards a minimalist description of possible implementations is not by way of avoidance but simply to provide focus on the problem which cvTokens specifically aim to solve (an economic one, rather than a technical one).  Let's examine the statement again:

So, trivially, we can spend a transaction fee which will go to a specific miner in the future who is unknown to us.  Nonetheless I know this is not what you meant.  I assume rather that you mean specifically someone who inherits this property in a sequence, the length of which is unknown.  Let us also use a simpler example than cvTokens.  Say instead that I have a close friend working as a contractor for me, and I want their fee to pay out in 6 months.  I trust them completely, but I wish to avoid any appearance of impropriety (such as by giving them the money early).  In addition, they trust me completely, but they wish to be able to reassign their wage to another party (say, as alimony to an ex-spouse).  Similarly that party may wish to reassign the wage again (as collateral to a bank), and so on.  The example won't match the scenario exactly, but it's good enough for our purposes.

I already have the money, so I create a timelocked transaction which will become spendable in 6 months, with a sequence number of zero.  It sends the full amount for the contract to my close friend who we shall denote 'C'.  I sign this transaction and publish it to the network.  Notice that if my friend dies or is unable to complete the contract, I will be able to publish a new transaction with sequence 1 or higher spending the funds to myself instead.

Next, C creates a transaction which spends my timelocked transaction to their ex-spouse, who we shall call 'X'.  C signs the transaction and gives it directly to X.

Finally, X creates a transaction spending that transaction to a bank B, signs it, and gives it to B along with the signed transaction from C.  Note that X does not need C's permission or cooperation to do this.

Now, if I do nothing, in 6 months the bank will publish their transactions and collect the amount of money I paid my friend.  However, if I update my original transaction, the bank's transactions will be invalid, and they will receive nothing.  Depending on my choice, an unknown specific party will receive this money.

Now of course, simply by making the original timelocked transaction final, I could have guaranteed that this unknown specific party would receive my funds.  However I included the usage of sequence numbers to show how something happens at a specific time because of my inaction.

In the course of a larger explanation, I might casually refer to that situation as "when I fail to act, the network does x" or "when I fail to act, the protocol reassigns my funds to the bank".  I do this merely for the sake of the explanation, assuming that the reader will take terms like "the protocol", "the escrow", etc. to refer generally to whatever underlying mechanism implements the desired result.  The only alternative would be a very lengthy explanation which would greatly confuse the purpose and mechanisms of the larger cvToken system, and so I hope that for brevity's sake the reader will excuse such wild anthropomorphising of undetailed technical complexity.  In no way do I mean to suggest that the network itself is doing anything that is not being done by some individual actor within it.

dacoinminster I am reading your paper now.

I understand your position. However, I lost all enthusiasm for your proposal when I realized it was impossible to implement. In particular, it is not possible to sign transactions over to unknown specific parties ahead of time.

Given the vague details, I may try to figure out how it is possible to do what you are talking about with testnet3 scripts, but it is not currently a high priority for me. If the new scripts "do the impossible", they may actually be a security risk.

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.

Having though about if for more than a day, I think there is a fundamental problem with the proposal: The 'network' appears to have more information than the participants. Namely: the Bitcoin private keys for "collapsing back into Bitcoin" if no backers are available.

Questions:

• How are bitcoins signed over to the CV token network?
• If no backers are available, how are all of the participants paid out?
• If the network has the private signing keys for those bitcoins, what prevents a bad actor from simply spending them?
• On the assumption you are using n-m type contracts, does that mean each time the rolling auction updates, a new massive transaction (with many inputs and outputs) has to hit the Bitcoin block-chain? What happens if not enough people sign the previous contract? What happens if there is a delay confirming the transaction on the Bitcoin network?
• How much time do the backers have to back pay-outs? Do they risk loosing all of their Bitcoins backing the CV tokens if their Internet connection goes down for an hour?
• You say that this can be implemented either with existing transaction types on the Bitcoin network, or new transaction types. What new transaction types would you like to see?

I completely agree. Something like this is going to make someone implausibly rich someday.

Shouldn't this be moved to the 'project development' thread, the OP isn't really talking about developments to the Bitcoin protocol/client

I bookmarked this thread.

Governments can use CVtokens to accept tax payments backed by bitcoin. I bring that example up because governments would have the capital to set such system up. (And I do not want to disclose exactly who I shared the link with at this time)

This thread has not received the attention it deserves!

Oh wow.

I'm still absorbing this thread, but I have to post some encouragement. After my speaking on "Bitcoin in the Future" on a panel at the San Jose bitcoin conference, somebody came up to me and pointed me to this thread.

I wrote a whitepaper about something very similar. Have you read it? (see my signature).

It sounds like you are one of the few people in the world who see the enormous potential of using escrow and speculators to stabilize a token, which can then track the value of any currency or commodity desired.

As far as I can tell, the biggest difference between my proposal and yours is that I tried to provide a mechanism for a "kickstarter" type fundraiser to get things rolling on a new layer of coins running on top of bitcoin, which also lets people invest in the success of the idea and profit if it works.

You and I need to talk

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.