Topic: Using short-run coin generation rules to dampen exchange rate volatility (Read 2162 times)

Since bitcoins is meant to be its own currency,  it should not directly have any ties or pegs to any other currency.  And just which currency did you mean to peg it to?   Why that one?   Or if a basket of currencies,    what did you really solve , while making more issues by the peg?

Yeah but what the heck, the trust issues in currency are already huge.

How many wheelbarrows full of paper does it take to buy a loaf of bread?

Adding all the audits and "legal requirements" doesn't sound that great an idea when I think about the purported agency of MtGox's big recent problem (an auditor) and the agencies of the wheelbarrows of money to buy a loaf of bread scenarios (the lawmakers).

Nice thing, purportedly, about free markets is anyone and their dog can put a currency of their own on the market and the market will decide whether the dog's currency or the anyone's is worth anything.

In the Galactic Milieu, the Hackers, being possibly about as mythical as the preposterous mythical planet known as Earth, are reckoned pretty amazing so their currency (Bitcoins) is reckoned pretty valuable. The Martians are not reckoned as advanced but are thought to be mighty in war so theirs too is reckoned maybe ok, maybe especially if you think "sending in the Marines" might some day be necessary. The Brits and Canucks are held in reasonable esteem among Democratic nations so theirs too is widely traded. And so on.

A big question is whether the major holders of bitcoin who picked up huge quantities early on did so in order to be able to build reserves of fiat to uphold bitcoin's value or are just ponzi players cashing out and leaving bitcoin in the dust.

-MarkM-

You are right in principle. If the coins are fully backed by the issuer with gold, USD, etc. Then the peg cannot be broken. The issuer could never touch the principal in the warchest, though they could earn income through interest for example by depositing the money in FDIC insured accounts. This system has huge trust requirements. Really huge. The issuer would need to be audited regularly. Perhaps interest would be enough to pay for the audits and legal requirements. The issuer could also collect income through transaction fees.

I like the idea of merchants issuing the currency. Merchants need to be rewarded for participation. Still the trust issues are huge.  

Basically this would be like a paypal clone without chargebacks and with minimal adminastrative overhead. If the trust issue can be solved, this would be pretty awesome. Big If.

This is why some of the groups creating or thinking of creating their own currencies have been thinking of issuing half their coins up front.

Basically unless the issuer is the speculator, the speculator's warchest of the cryptocurrency can only exceed the fiat warchest of the issuer if the issuer fails to retain as reserves the fiat that the speculator, or who-ever the speculator obtained the cryptocurrency from, paid for the cryptocurrency.

How can someone possibly obtain more dollars worth of what you sell than you have dollars that you sold it for?

Only if you cash out instead of acting as a responsible backer holding what you sold it for as reserves with which to "back" it.

Such considerations have led to the current work that is being done on implementing "mining licenses".

EDIT: Consider PayPal, issuing database entries of PayPal Dollars (PPUSD). If they fail to have enough actual dollars to "buy back" those PPUSD with, they are acting as a "fractional reserve bank", which might be beyond their mandate/license (or might not?)

-MarkM-

No.

You seriously want to make a major change to the protocol in production just because you're not comfortable with price movements? There's absolutely no guarantee you'll achieve anything useful, while the danger of breaking up everything is clear there.

Bitcoins are volatile, and will probably remain volatile for years. Get used to it.

Yeah, I thinking of a function in which current difficulty and a series of past difficulty levels are the right hand-side arguments. Every node should agree on these right hand-side arguments. A specific formula that works may take some time to come up with. I may screw it up on the first try. I will think about it for a few days and post an example then. In the meantime I welcome any suggestions from others on a working formula.

It has nothing to do with security. To reverse part of the chain, you always need to do at least as much work on average as was put in the part of the chain you're trying to revert, whether that is 1 block or 1000 blocks.

The 1 block per 10 minutes rule is a compromise between usability and chance for stale blocks because of network delays.

What formula would you propose to achieve this? To be implemented, it would have to be strictly mathematically defined (and every node should come up with the same answer, so it cannot be dependent on external information).

Same title, but the topic is actually completely different. I will change the title.

This same topic already was created recently, in the right forums:

http://forum.bitcoin.org/index.php?topic=28296.0

Its not about number of coins per block. The 1 block/10 minutes is designed to increase security.

Fixed exchange rate systems are susceptible to speculative attacks and currency crises. If the speculator's cryptocurrency warchest is larger than the central bank's fiat warchest (merchants are the central bank here), the speculator can break the peg and cause the cryptocurrency's value to plummet. By buying up options to sell the cryptocurrency at the peg value beforehand, the speculator can profit by simply exercising the options.

I doubt the merchants will keep big enough war chests to fend off these attacks.  

Here is a famous example to make things more concrete:
http://en.wikipedia.org/wiki/Black_Wednesday

In short, I don't think the fixed exchange rate systems make sense.  The goal of my system is not to prevent bitcoin from changing in value, but to establish some roadblocks to slow down the process of appreciation and depreciation.

Some of the alternate chains have been discussing a concept they call "reputable merchants" or "reputable suppliers".

They basically seem to be likening a seller of digital cryptographic coins to a dealer in antique coins or other collectables.

The basic idea is the dealer you buy your coins from would be happy to buy them back at the same price, minus ("of course") a small transaction fee.

So basically they figure if they consistenly remain willing to buy back the coins they sell, at very little "spread" from the price thye sold them at, then at least the people who buy *from them* need not be so concerned about "volatility".

They have even suggested this strategy could work in a limited way in blockchains where anyone anywhere could choose to mine and to "dump" the coins they mine at lower than the rate these "reputable dealers" buy back the coins they themselves sell.

Two approaches: one, keep track for each customer (under a Know Your Customer system) of how many coins you sold them, and only buy that many back from them (at lest at the "money back if not satisfied with your purchase" rate). Two, watch the blockchain, and only buy back the specific coins (at the "money back" rate) that you sold.

-MarkM-

Yes, keeping to the coin generation schedule is a big issue. I don't see why the 50..25..12.5 coins per block commitments are important, however. What matters is that there must be approximately x million bitcoins at the end of 2011, approximately y million bitcoins at the end of 2012, and a maximum of 21 million bitcoins in the infinite future. You can approximate these rules without holding to the nitty-gritty details of the short-run generation schedule. I think these nitty-gritty details could be adjusted to dampen short-run swings in the exchange rate.

Some points:

1) volatility will die down naturally if merchant adoption succeeds on a large scale. Thus the fact that volatility cannot be dampened eternally is not worrisome.

2) The biggest problem is short run volatility- say booms and busts within a 1-2 month time frame.
 
3). My suggestion is two adjustment schedules for the number of coins per block. A short run adjustmenent schedule will cause the number of coins per block to rise when difficulty growth exceeds long run trends and fall when difficulty growth falls short of long run trends. The definition of short-run here could be say 1 week. A long run schedule will try to keep the long-run average number of coins per block set at 50 or 25 etc. with the definition of long-run here being say 6 months.

4) This suggestion would make the hashrate more volatile and harm security. Accordingly, you cannot allow the number of coins per block to drop to zero or shoot up to infinity, since the hashrate volatility associated with this will make the system insecure. I think you could allow the number of coins per block to drop and fall within say a 20 coin to 125 coin band without causing unacceptable damage to security.

Implementing this should enable some short run exchange rate volatility to be passed on to miners. I think that miners can bear volatility better than merchants.

If it was say 60 an hour, you would have about one a minute. This may sound good, but, because they are easier to make, to be sure that a payment will not be a double spend you now have to wait for about 10 blocks to get the same certainty that 1 would have provided. You'd pretty much be looking at "10 minutes of network computing power" so if they came out faster you'd just have to get more confirmations anyways. The 10 minutes seems to be a pretty good pace. I know it's not instant but sure faster than VISA or banks!

This is not relevant because you can also vary the number of coins per block to achieve the same effect.

From what I've read from the whitepaper, 1 block every ten minutes was selected as a happy medium for network propagation and the likelyhood of forking the chain to do malicious things.

More can be found here:

http://www.scribd.com/doc/34237903/Bit-Coin-Whitepaper

On the surface this sounds like a good idea.  But then how would it work in terms of the bitcoin creation schedule?  What would happen to the 21 million coins around 2030?  If you gave out more coins when the difficulty was higher that would just encourage the difficulty to go higher.  If you gave out fewer when the difficulty were lower that would encourage the difficulty to go lower.  The whole point of the mining schedule is to build up a nice stable base of miners to support the network.  The point of the creation schedule is to give people confidence that bitcoins won't be debased by a central bank and that their money will retain value.

I wanted to start a post for brainstorming about the currency generation rate.

Back when difficulty was booming,  it might have been better to have released more than 6 blocks per hour. Tossing more bitcoin on the market might have prevented the exchange rate from appreciating rapidly. When difficulty growth slowed down it might have been better to release fewer coins per hour to prevent the exchange rate from dropping so rapidly. Adjustments along these lines would make mining rewards more volatile and the exchange rate less volatile. Since exchange rate volatility is a big problem for merchants, would modifications along these lines improve bitcoin? Note that it might be better to change the number of coins per block instead as this would achieve the same effect withoout screwing up the transaction processing rate.