Pages:
Author

Topic: [PROPOSAL] The Second Bitcoin Whitepaper - page 3. (Read 6343 times)

full member
Activity: 372
Merit: 114
But it is the same thing then, just with voting on "hyperbitcoins per bitcoin" or some other exchange than "bitcoins per current block difficulty". Either way you must assume people will vote in their own interest.

I think you underestimate the failure scenario.  Its not hard to design some kind of fund and describe how it will run while it remains solvent; that is easy.  The hard part is deciding what happens if he fund is insolvent.  As you hinted in your OP there is really no way to do this reliably.  

In other words, handling the case of bitcoins win, commodities lose where you have escrowed bitcoins is totally obvious.  Clearly if the losers assets are in escrow, they can be handed to the winners.  What is not obvious, and infact impossible, is to handle the case where bitcoins lose, commodities win when you have only escrowed bitcoins.  To do that, the commodities must be in escrow too,  or you must hold more coins in escrow than you have bet.  

Also, think about what will happen: commodity betters will vote commodities won, and bitcoin betters will vote bitcoins won.  So in the end the result will have nothing to do with exchange rates but simply a game of "pick the bigger side".

Intuitively, NOONE can peg a bitcoin to a commodity except someone who holds both of them.  More accurately, only a bitcoin holder can keep a price above some value and only a commodity holder can keep a price below some value.

If you wanted to do this fund, here is how you could do it.  Find people like yourself who believe bitcoins will outperform oil.  Pool your cash and split it, buying bitcoins with some fraction and using the rest as collateral with a broker, sell an oil futures contract.
legendary
Activity: 1260
Merit: 1031
Rational Exuberance
Its not different.  Think all the way through.  You are suggesting people vote on the exchange rate, and then based on the outcome, the network will do some action to produce the desired effect.  What such action can be taken?  It seems to me the only action possible is adjustment if generation parameters.

I.e, if coins are too cheap,  an adjustment is made to produce fewer coins per block, and vice versa.  

But now, knowing this, how will people behave?  They will not vote for the true exchange rate, but rather for a rate that triggers their desired behavior (increasing or decreasing generation).

So its better to let them vote on that directly.

I think perhaps you misunderstand what I am proposing. I am NOT suggesting that the protocol would change the number of blocks generated for bitcoins. I have no desire to change the way bitcoins are generated, which is an algorithm that many people have accepted and are already invested in.

Instead, I propose that people be given the option to transfer risk for bitcoin price fluctuations through the protocol in a way that can guarantee them a stable store of value as long as bitcoin remains a viable currency. The risk would be transferred to speculators.

The only thing the distributed exchange rates would be used for in my proposal would be to set trading fees. The closer people trade to the external exchange rate, the lower their trading fees. This is my proposed mechanism for ensuring that prices eventually converge with the exchange rates outside the network. See the example above for details: http://forum.bitcoin.org/index.php?topic=31645.msg400477#msg400477

No, my scheme would not inherently be some kind of new vs old.  If it became that, there would be stability:  whoever has more CPU power in the long run wins.

In other words, rules would always be set by "current adopters".  If the network is in infancy, that means newcomers.  If mature, AND early adopters still participate, that means early adopters.
 
The main point is to allow rules to change as the community grows, rather than fixed arbitrarily.  by the earliestlt adopter as in bitcoin.  If a majority of CURRENT participants wants inflation, they get it.  Ditto for deflation or stability.

Also check out post10 there for avoiding "tyranny of majority".  A participant could have a range of acceptable parameters and refuse to accept blocks outside of them.  They could then be off in their own world with whoever agrees with them.

I will watch your scheme unfold with great interest.
full member
Activity: 372
Merit: 114
Its not different.  Think all the way through.  You are suggesting people vote on the exchange rate, and then based on the outcome, the network will do some action to produce the desired effect.  What such action can be taken?  It seems to me the only action possible is adjustment if generation parameters.

I.e, if coins are too cheap,  an adjustment is made to produce fewer coins per block, and vice versa.  

But now, knowing this, how will people behave?  They will not vote for the true exchange rate, but rather for a rate that triggers their desired behavior (increasing or decreasing generation).

So its better to let them vote on that directly.

No, my scheme would not inherently be some kind of new vs old.  If it became that, there would be stability:  whoever has more CPU power in the long run wins.

In other words, rules would always be set by "current adopters".  If the network is in infancy, that means newcomers.  If mature, AND early adopters still participate, that means early adopters.
 
The main point is to allow rules to change as the community grows, rather than fixed arbitrarily.  by the earliestlt adopter as in bitcoin.  If a majority of CURRENT participants wants inflation, they get it.  Ditto for deflation or stability.

Also check out post10 there for avoiding "tyranny of majority".  A participant could have a range of acceptable parameters and refuse to accept blocks outside of them.  They could then be off in their own world with whoever agrees with them.
legendary
Activity: 1260
Merit: 1031
Rational Exuberance
If you want to peg coins to something, you need to get real-world info into the chain to adjust supply.  There are two ways to do this: trust someone, or do it by vote and trust voters to do what you want.

In other words, your proposal is effectively the same as "let coin generation parameters be setr by vote" and "hope people will vote to peg prices".

I described a scheme for doing this here:
 http://forum.bitcoin.org/index.php?topic=24929

I plan to build such a system after meeting work deadlines, about 4 weeks.

I looked over your proposal. It looks very interesting. Allowing people to vote on how many coins are generated is very different than having them vote on what they think the USD/bitcoin exchange rate is. If I'm understanding your proposal correctly, early adopters would vote for less coins generated, and would use their CPU/GPU power simply to prevent other people from getting coins. Newcomers would vote for lots of coins to be generated. That doesn't sound like a recipe for price stability to me, but maybe I am missing something.
legendary
Activity: 1260
Merit: 1031
Rational Exuberance
User A buys a USDCoin at current market rate, say 1/14 BTC.  Current market rate moves to $15/BTC and user trades in his USDCoin for 1/15 BTC.  Fantastic.  User B decides $/BTC will move down, so he buys a USDCoin for 1/15 BTC.  He is right and wants to cash in his USDCoin.  Whoops!  Either the value of the bitcoins in escrow has to somehow fluctuate with the asset (impossible), or you have to pray it doesn't move against the hedge.

You are quite right that trades cannot be made between users and escrow. The protocol would have to match users to each other directly. That is what I mean by the exchange rate fluctuating separately from real life.

Here is the example I would use:

User converts his bitcoins to USDcoins
Behind the scenes, his bitcoin client puts his bitcoins into the escrow fund. In return he gets USDCoins. The protocol gets those USDCoins by either 1) Buying them from another user who is selling them OR 2) Creating them out of thin air, and also creating balancing AntiUSDCoins, which it sells to another user. One of those options will be a net win for the escrow fund, and that will be the option chosen.

User later converts his USDCoins back to bitcoins
Behind the scenes, his bitcoin client either 1) Sells his USDCoins to another user, or 2) Buys AntiUSDCoins from another user and destroys both the USDCoins and the AntiUSDCoins. One of those options will be a net win for the escrow fund, and that will be the option chosen. The resulting bitcoins are then credited to the user.

In order to converge prices on reality, the protocol could charge a slightly higher fee the further you trade from the current external exchange rate.

Obviously the example above is more of a "market order" type of trade. Limit orders would also be needed to provide liquidity.
full member
Activity: 372
Merit: 114
If you want to peg coins to something, you need to get real-world info into the chain to adjust supply.  There are two ways to do this: trust someone, or do it by vote and trust voters to do what you want.

In other words, your proposal is effectively the same as "let coin generation parameters be setr by vote" and "hope people will vote to peg prices".

I described a scheme for doing this here:
 http://forum.bitcoin.org/index.php?topic=24929

I plan to build such a system after meeting work deadlines, about 4 weeks.
legendary
Activity: 1904
Merit: 1002
I should add that the price of oil-denominated bitcoin, gold-denominated bitcoins, etc would have to be allowed to fluctuate somewhat separately from the official exchange rate. That way, bitcoin traders of those commodities could affect the real-life prices, and vice versa.

User A buys a USDCoin at current market rate, say 1/14 BTC.  Current market rate moves to $15/BTC and user trades in his USDCoin for 1/15 BTC.  Fantastic.  User B decides $/BTC will move down, so he buys a USDCoin for 1/15 BTC.  He is right and wants to cash in his USDCoin.  Whoops!  Either the value of the bitcoins in escrow has to somehow fluctuate with the asset (impossible), or you have to pray it doesn't move against the hedge.
legendary
Activity: 1260
Merit: 1031
Rational Exuberance
I should add that the price of oil-denominated bitcoin, gold-denominated bitcoins, etc would have to be allowed to fluctuate somewhat separately from the official exchange rate. That way, bitcoin traders of those commodities could affect the real-life prices, and vice versa.
legendary
Activity: 1260
Merit: 1031
Rational Exuberance
This thread is now locked!

I have decided that I like morpheus' idea better than my own, so I am locking my threads about this stuff, and I encourage anyone interested in concepts like this to check out his thread:

https://bitcointalksearch.org/topic/goldcoin-and-stablecoin-proposals-29135

==============================================================


Imagine:

You download the latest bitcoin client, and upon opening it, you see that while your wallet is still enumerated in bitcoins, you now have the option (in a drop-down menu) to store that value at a guaranteed constant value pegged to your choice of USD, Euros, ounces of gold, ounces of silver, barrels of oil, and a couple dozen other currencies and commodities. You can also peg your value to fluctuate with the inverse of any of these. Finally, you have the option to continue to hold your value in bitcoins or in something called "hyperbitcoins". You can convert your holdings between any of these, or hold a combination of them, and each conversion costs you only the current bitcoin transaction fee.

Is this possible? I believe it is, and I believe it is the next step for bitcoin, and will lead to a million-fold increase in bitcoin prices (I describe my logic for the latter claim here: http://forum.bitcoin.org/?topic=7985.0)

This is not the "white paper" referenced in the title of this post, but I'm calling out for such a white paper to be created, and I'm describing some protocol changes the white paper could describe.

Here's how it would work:

People holding bitcoins denominated in USD, Euros, gold, oil, etc, deposit their bitcoins into an escrow fund held by the network. In exchange, they get a token guaranteed to be redeemable for bitcoins from the escrow fund at the pegged value at any point in the future. These tokens could be bought, sold, used in commerce, etc, just like bitcoins. You could send them to any bitcoin address, and that person would receive them as bitcoins. In this way, somebody could buy a t-shirt using oil-denominated bitcoins which they pay to the bitcoin address of a vendor who holds gold-denominated bitcoins. This would be completely transparent to both of them.

The key to making this possible without ever completely depleting the escrow fund is holding additional bitcoins in that fund by the protocol selling hyperbitcoins, which are a big bet on the rise of bitcoins versus ALL the other possible stores of value listed.

You can think of buying hyperbitcoins as buying shares in a company. If you convert a bitcoin to a hyperbitcoin, you are depositing that bitcoin (forever!) in the escrow fund described above to ensure its solvency.

In exchange, when bitcoin prices quadruple (and everything else indexed does not), there is now a surplus of bitcoins held in escrow. Some or all of that surplus value would be distributed to existing hyperbitcoin holders similar to how a company distributes profits to shareholders.

Hyperbitcoins would also be bought, sold, traded, etc, just like bitcoins or any of the currency/commodity tokens described above.

As an example, imagine you believe big-time in the future of bitcoins, so you convert your one bitcoin (worth $15) to a hyperbitcoin. Let's imagine that the escrow fund consists of 1M bitcoins, 250k of which came from hyperbitcoin sales to people like you.

Later, the value of bitcoins rises 100x versus the other currencies and commodities tracked. The escrow fund now holds 100x as much value as before. It only needs 5k bitcoins to cover its liabilities to the token-holders, but it has 1M bitcoins. Consequently, the escrow fund slowly starts distributing bitcoins to hyperbitcoin holders. To be conservative, the escrow fund makes these payments over many months, to protect itself in case the rise was only temporary.

Excess bitcoins could be distributed either by paying "dividends" in bitcoins, or by buying back hyperbitcoins on the open market. In the former case, once all excess bitcoins were distributed, you (the hyperbitcoin holder) now still have your hyperbitcoin (which you can always sell if you want) plus nearly 4 new bitcoins worth $1500 each (You did a lot better than if you had just held onto that one bitcoin). I believe the hypercoin buyback scenario would drive up hyperbitcoin prices, yielding a similar or possibly even greater profit.

The counter-example is if bitcoin prices crash, Now we run into the possibility that there aren't enough bitcoins in escrow to cover all the tokens being held if they were cashed out at once. Perhaps this would trigger a run on the escrow fund by people holding the tokens. I used to think that this scenario must be avoided at all costs, but after contemplating a doomsday scenario thought experiment (http://forum.bitcoin.org/index.php?topic=31645.msg403514#msg403514) I decided that the protocol will probably have to give up supporting the currency/commodity values when there aren't enough hyperbitcoin holders to absorb volatility.

There are several technological hurdles, including how to do a distributed exchange rate (the same way bitcoin currently does a distributed timestamp), and how to create a distributed exchange between bitcoins/hyperbitcoins, GoldCoins/AntiGoldCoins, OilCoins/AntiOilCoins, etc, that the protocol could run and use.

I first introduced the concept of hyperbitcoins in this thread: http://forum.bitcoin.org/index.php?topic=30741.0
The concept was extrapolated in this thread: http://forum.bitcoin.org/index.php?topic=31032.0

I believe this concept is so important to bitcoin's future that I am currently PAYING BITCOINS for intelligent posts in the latter thread, and I'm officially extending those payments so that posts in this thread are eligible as well. See this thread for details on the payments: http://forum.bitcoin.org/index.php?topic=31057.0
Pages:
Jump to: