I've been discussing how Bitcoin might overcome the adoption/volatility problems in the event that the adoption rate stagnates before they've solved themselves. I ended up proposing a solution that jtimon said looked a lot like Beertoken, so I thought I'd post it here for posterity, and to see if beertoken could be adapted to be suitable for this purpose.
Namely, it'll need to be able to pay out interest - both postive and negative - to currency owners at per-block rates specified by the central issuer. The transactions do not need to occur for every address, during every block, obviously, but only at the time a transaction is made. In the meantime the client can just calculate effective balances of addresses.
The CHECKMULTISIG OP code is also required, but that's for the Bitcoin developers to enable. It's not stated below, but it'll also require nLockTime for trust-free exchanges of cryptocurrencies - something also for the Bitcoin devs to enable.
Here is the use case:
The problems to be solved are the temporary hurdles of price volatility and merchant adoption, while effectively avoiding splitting the user base, and making the network effect - and thus reduction in price volatility - harder to achieve. Any potential long run problems like steady deflation or lack of mining incentives should be looked at separately, and can be easily overcome later on if the time comes that they are relevant. As I believe cunicula agrees, they should not be a consideration at this time.
Based on the conversations here, these problems appear to require human management to be most effectively solved, and any decentralized solutions have been admittedly lacking. So to solve these problems while keeping the user base effectively contiguous, I proposed having all of the new currency be issued through a "distributed central bank". By distributed, I mean that any transactions it engages in must be signed by some threshold number of the organizations that run it. This is possible using the OP code CHECKMULTISIG which isn't currently enabled in Bitcoin. The bank would uphold a promise to redeem its currency 1-1 for bitcoins, plus any variable fees.
It can credibly keep this promise, without any risk of a run, by using demurrage when it wants to devalue the currency instead of inflation. Demurrage results in excess reserves being held by the bank, which can be used later on to pay interest to currency holders in order to fight undesirable currency devaluation, as well as to subsidize merchants and developers. In this way, the price chart of the new currency could look more like a moving average of Bitcoin's if the bank does a good job.
Gresham's law would need to be enforced during times of deliberate currency devaluation, since otherwise people would just dump the currency on the bank 1-1 for bitcoins. This can be done by deterring redemption at these times with fees. Conversely, while the bank is supporting the currency with interest, arbitrageurs need to be deterred with fees from buying up a ton of the new currency from the bank 1-1 for bitcoins, and soaking up all the available excess reserves to be paid out.
Txn fees can also be used to devalue the currency, and collect revenue to be distributed as interest, or merchant and developer subsidies.
Despite the increased centralization, trust should not be an issue as it can be distributed over multiple organizations in the way described above. Management can also be distributed over multiple jurisdictions, and because the backing is non-physical, it should be resistant to confiscation by states, unlike gold for example. Also, because this is a measure designed to overcome the temporary hurdles described above, the arrangement doesn't have to last forever, or even very long, hopefully. Afterward, the bank can stop issuing new currency, gradually redeem all of what remains in circulation, and then finally disband once it's achieved its purpose.
This solution effectively avoids splitting the user base since the relative valuation of the new currency and Bitcoin is completely determined by the bank's transparent monetary policy. This means that added trading depth in one should lead to added stability in the other as well by the actions of arbitrageurs.
It also avoids having to solve the initial distribution problem and builds off of the work already done by Bitcoin toward solving the initial adoption and volatility smoothing problems. People are incentivized to buy into and hold onto the new currency because it offers them improved stability, and out of the sense that by doing so, they're helping to aid the the adoption and development of Bitcoin, thereby increasing the value of their holdings in the long run.
If this is successful in giving us a widely adopted, steadily deflating currency, then at that point the protocol and blockchain can be forked to solve the steady deflation problem, if it is indeed a problem. Or if human feedback is desired, then a new "distributed central bank" can form with this new purpose. I'd prefer the latter solution, as it would be more effective, and the transition wouldn't be at all economically disruptive. That, or a gradual transition to the former via the latter. In the same way any potential future miner incentive problem can be addressed.
Mmmm. Your idea seems pretty centralized to me.
I suggest you read beertoken, stablecoin and reservecoin proposals in the list of my sign.
Thanks jtimon, I will read them.
I think there are distinct short term and long term problems, and that only the short term ones are relevant now since there exists an obvious way down the road to address the long term ones when they become relevant. (The particular solution details are not obvious - they're what you guys are coming up with here - but the way to roll them out is.) So because the added centralization from this proposal only exists temporarily to give Bitcoin a leg up over the adoption hurdle, I don't see it as a problem. Especially considering the organizational structure I proposed.
I also see it as necessary since these short-term problems clearly require, or would at least be much better solved using, external inputs and human management.
And it's especially beneficial since it avoids splitting the user base and causing economic disruption, unlike rolling out a whole new block chain or forking the existing one.
I'd also like to state that I remain quite hopeful that Bitcoin will make it over the adoption hurdle without this kind of help, and that this should only be seen as a kind of contingency plan.
Don't think I can make the case any better than that, so there you have it.
I was thinking another way the managers might be kept accountable and competent might be if several of these banks were operating for profit and in competition with one another. There's nothing to stop viable for profit competitors from springing up if the stability etc. they offer is compelling enough.
Are you okay with managing the exchange rate through currency creation and currency destruction? I don't like fixed exchange rates.
In my proposal the market exchange rate between the bank's currency and Bitcoin is not actually fixed - it will wiggle around 1-1 since the currency will occasionally be paying either positive or negative interest. Furthermore, there is currency creation and destruction going on via interest payments and demurrage, respectively. But I think I see what you mean - you're suggesting the bank issue and absorb currency through "open market operations", right?
I proposed this method instead 1) to reinforce a common (on the larger time scale) currency unit, 2) to avoid introducing risks of insufficient reserves, and 3) because it seemed to me to do the best job of evenly/fairly distributing purchasing power gains/losses (cut the speculators out, they're not necessary when issuing a Bitcoin-like currency).
Also if you want to fix the exchange rate, then you will need physical control over some location where people can redeem their coins. This might prove difficult. Control over creation and destruction can be managed by anyone with access to a computer interface and the right password.
Physical key storage is an unfortunate fact of having human control over currency issuance/redemption, I think. But I tried to mitigate this by suggesting using the CHECKMULTISIG OP code to require some majority of the managers' signatures in order to produce a valid transaction. This way, some minority of them can at any given time lose their keys or be corrupted somehow, and the bank will go on functioning smoothly.
