[PROPOSAL] The ticker and the hole (path to bitcoins worth $1M each)

[bitrebel]

Your handle should really be "RationalMonkey", as it would go better with your avatar and fit your personality well. 

[1713563578]

1713563578

[1713563578]

1713563578

[dacoinminster]

There's no need for this at all. You don't need to move value with data. You're using satoshis because you don't want to move much value with the messages, but why move any value at all?

How would you propose I notify the network that my 50 USDCoins are for sale?

What set of rules do you expect people to define to make those centrally issued currencies better than bitcoin or to have any value at all?

ANY set of rules you can imagine will work. For instance, you've been chomping at the bit to give demurrage a try with your friecoin project. You could implement it much easier in a client that supported these extended rules.

[dacoinminster]

Your handle should really be "RationalMonkey", as it would go better with your avatar and fit your personality well.  

Heh - thanks. I found the avatar picture when I was experimenting on a monkey in order to predict the stock market: http://forecastmonkey.blogspot.com/

Actually, the predictions came from a computer program, but I have a sick sense of humor.

[vector76]

The bitcoin block chain at a low level is basically two things: it's an eternity service and also a timestamping and race-resolving service.  And as such it can be used as a public communication channel.  It is possible to layer additional protocols on top of it, and although it is far from ideal, it is possible.

Implementation details aside, at the core, you are establishing a system of deposits and withdrawls and transfers between account holders.  That part is not particularly problematic, but treating the deposits as if they were a new currency does not fit very well because the deposits are not at all cash-like.  The deposits cannot be transferred without the participation of the deposit holder, so they are more like checking accounts.

Now in addition, if the 'bank' establishes an understanding that accounts will be held in some asset other than bitcoins (gold, let's say), then that could be a benefit to account holders who don't want to be exposed to the risk of bitcoin value fluctuation.  It would be incumbent on the bank to properly position their assets rather than gamble with the account holders' money, but that's up to them.


The implementation details are not great, but it is doable.

Asking an institution to hold value in something other than bitcoins is not unreasonable.  The exchanges do it after all.

But if it is not cash-like, then I don't see a lot of point to integrating it so heavily with the block chain.  Since a central institution must be involved anyway, why not simply register a key with the bank and sign checks that transfer value from your account to another account?  All of the accounting and double-spend checking has to be implemented by the bank regardless, so the advantages of the block chain are really not being used.  Even a public, synchronized communication channel is not necessary.

[dacoinminster]

The bitcoin block chain at a low level is basically two things: it's an eternity service and also a timestamping and race-resolving service.  And as such it can be used as a public communication channel.  It is possible to layer additional protocols on top of it, and although it is far from ideal, it is possible.

Implementation details aside, at the core, you are establishing a system of deposits and withdrawls and transfers between account holders.  That part is not particularly problematic, but treating the deposits as if they were a new currency does not fit very well because the deposits are not at all cash-like.  The deposits cannot be transferred without the participation of the deposit holder, so they are more like checking accounts.

Now in addition, if the 'bank' establishes an understanding that accounts will be held in some asset other than bitcoins (gold, let's say), then that could be a benefit to account holders who don't want to be exposed to the risk of bitcoin value fluctuation.  It would be incumbent on the bank to properly position their assets rather than gamble with the account holders' money, but that's up to them.


The implementation details are not great, but it is doable.

Asking an institution to hold value in something other than bitcoins is not unreasonable.  The exchanges do it after all.

But if it is not cash-like, then I don't see a lot of point to integrating it so heavily with the block chain.  Since a central institution must be involved anyway, why not simply register a key with the bank and sign checks that transfer value from your account to another account?  All of the accounting and double-spend checking has to be implemented by the bank regardless, so the advantages of the block chain are really not being used.  Even a public, synchronized communication channel is not necessary.

You have demonstrated a strong understanding of what I am proposing. I salute you!

You bring up an important use-case, which I forgot to mention. What if I have some usdcoins, and I just want to transfer them (without selling them)? That could be done in two standard bitcoin transactions:

0.00000003 BTC to the hole (meaning "I'm going to transfer some USD coins to someone else"), then send 0.00000050 BTC to the address of the new owner, meaning "I transfer 50 USD to this address".

Note that almost no bitcoins change hands to transfer ownership of the USDCoins, but considerable value might actually be transferred by the transaction.

I'll add this example to post #1.

[dacoinminster]

I've reworked post #1 to reflect that:
 - bitcoins are destroyed when the new currency is created
 - MetaData about the ticker is mostly stored in the text of the fake address that destroys bitcoins
 - USDCoins (or any other similar coins) get partially destroyed anytime they are transferred or sold when USDCoin prices are too low (this is what causes prices to come back up as people hold onto them rather than spend them or sell them).
 - Better way to handle ticker registration

[jtimon]

There's no need for this at all. You don't need to move value with data. You're using satoshis because you don't want to move much value with the messages, but why move any value at all?

How would you propose I notify the network that my 50 USDCoins are for sale?

Please, read my previous post and my middlecoin and escrowcoin proposals (the list on my sign).

What set of rules do you expect people to define to make those centrally issued currencies better than bitcoin or to have any value at all?

ANY set of rules you can imagine will work. For instance, you've been chomping at the bit to give demurrage a try with your friecoin project. You could implement it much easier in a client that supported these extended rules.

Yes, it would be cool to just add freicoin to multicoin...
But how can your centrally issued currency be valued like a Google stock share ?

[phedny]

I've been thinking about a similar setup with a friend of mine. We didn't put it up for discussion, yet, but since this discussion is going on I think it's a good time to share our ideas.

What's going on at the core is that the one that creates the ticker writes out IOUs. The way we were thinking to do this is to assign a special status to a certain Bitcoin address and make a guarantee that the underlying assets are transfered at the time someone wants to cash the IOUs. In this place, it's important to notice that you must trust the creator of the IOU to be capable and willing to handle those requests.

I think our idea is best explained with an example.

First of all, I assign a special status to one of the addresses for which I possess the private key. Let's say address miGuMc6qtVEKS6Pf1jKddaa81DeHjMzkpB (yes, this is the testnet Faucet address, but for the purpose of demonstration it's okay).

I now make the claim that I will pay $0.01 for every Satoshi that is returned to me that comes from this address and is transfered according to a small set of rules. Please note that for these special coins the exchange rate if therefore fixed to $1M per BTC. As long as ordinary BTC are worth much less than this, the scheme works.

First of all, any BTC that flows into this address in one transaction and flows out of it in the next, will hold this guarantee. So if someone gives me $100 cash, I'll transfer BTC 0.0001 from this place to a Bitcoin address that this person provides.

Second, any transaction that is made from an output that holds my guarantee creates new outputs that hold my guarantee, as long as all inputs, except for at most 1, hold this guarantee. The sum of those input (minus the non-guaranteed one) must equal the sum of all outputs. Effectively, this allows the IOUs to be transfered, split and combined like BTC. The non-guaranteed input are ordinary BTC and will not make part of the output, such that it is considered fee. Therefore, the miners will get a bit of BTC for incorporating a non-BTC transaction, without explicitly knowing this.

Actually, this is all. Now, if some special (or guaranteed) BTC are returned to me, I can just mix these coins with normal coins in a single transaction to make them lose the special status. If at a later time I want to bring a larger sum of USD into circulation, I just send some BTC to the special address and from there on I can forward it.

From here on, anyone can issue IOUs in any currency or asset type. Even an exchange like MtGox or TradeHill could issue them and I may accept, e.g. MTUSD IOUs in my online store, because I trust MtGox to credit my USD account when I return those special coins. Some service may even exchange MTUSD IOUs for THUSD IOUs.

Also, I may accept USD of EUR IOUs from a friend of mine, maybe up to a certain limit. You can pay me using IOUs from a friend, but not using your own IOUs, because I don't know you yet. In #bitcoin-otc trust may be based on rating, allowing people with a good rating to give out IOUs to buy BTC, such that those IOUs are later cashed in by a (slow) bank transfer or something.

In the future, we could also create a distributed network that allows people to exchange IOUs. For example, I'm willing to issue new IOUs in return for IOUs from people I trust. Eventually, this may lead to a distributed version of the Ripple project.

[dacoinminster]

But how can your centrally issued currency be valued like a Google stock share ?

The only thing "centralized" about this is the ticker which imports price data into the block chain.

The mechanism for maintaining the price at the ticker target is alluded to but not explicitly spelled out in the OP.

The price cannot go much over face value since the new currency can be created by anyone by destroying some bitcoins at (or slightly above) the current ticker value.

If the price of the new currency goes below face value, a portion of the currency gets destroyed each time it is transferred. That portion increases the lower the price gets, discouraging people from selling it. I stole this idea from morpheus as described in his stablecoin/goldcoin proposal: https://bitcointalk.org/index.php?topic=29135.0

[dacoinminster]

While running thought experiments on how this would work, I have discovered a flaw in my proposal:

Imagine that the ticker for gold is not updated for 8 hours for some reason. During that 8 hours, the price of gold spikes 30%. During the time when the ticker is not updated, it would be possible to buy goldcoins at a 30% discount by destroying bitcoins, even though most users would not be selling at that price.

This method of coin creation is flawed, and I will have to contemplate how to better distribute these coins in a more slow and limited way, allowing prices to fluctuate much further from the ticker.

Any suggestions would be appreciated.

[vector76]

Have you considered using OpenTransactions in addition to bitcoin?  OpenTransactions allows an issuing party to issue certificates which can be traded.  It is quite different from bitcoin but I believe it complements it well, especially in a scenario like you are attempting to construct.

It has been suggested elsewhere on this forum, but I'm not sure if you have seen it or thought about it.

[dacoinminster]

Have you considered using OpenTransactions in addition to bitcoin?  OpenTransactions allows an issuing party to issue certificates which can be traded.  It is quite different from bitcoin but I believe it complements it well, especially in a scenario like you are attempting to construct.

It has been suggested elsewhere on this forum, but I'm not sure if you have seen it or thought about it.

I have to admit I just don't understand Open Transactions. I've read all about them, but I'm apparently too dense to see how they could do what I want (decentralized currency/commodity/stock trading). The bitcoin protocol can definitely do it, but I'm continually changing the implementation details, trying to get something easy to implement, cause I'm lazy.

[hashcoin]

Let's look at how this could work.

You, Joe user, decide you want to create and issue a new distributed USD currency riding on top of the bitcoin protocol. In this case, your currency is targeted to USD. Anybody buying a unit of your currency expects to be able to sell it in the future for around 1 USD.

Why?  In order to be able to sell it for 1USD, someone must be willing to physically give you 1USD for it.  Who is going to do that?  What if noone wants to pay 1USD for them?  Then they are worthless.

This was explained pretty clearly in your other threads.. you can't do things like this without a trusted person actually holding the assets.  It should be pretty easy to understand.

[jtimon]

Ok, I think I got it.
This is basically like stablecoin being the only difference that you prevent the price to go too high by other mean. Instead of create inflation and give the new coins to the miners, the system would sell newly created coins in exchange of bitcoins being destroyed at a slightly higher price than the target.
You have an exchange of usdcoins for bitcoins inside the chain to track the btc/usdc rate and you would import the btc/usd rate using the same method that stablecoin uses so you can calculate the bitcoin target price.

Is it your idea?
If so...
I don't like the idea of destroying bitcoins and I don't think many people in the forum will. Also you would eventually destroy all the bitcoins in which your system relies. Can't the bitcoins just go to your miners?

Why not put them (for this you can't use bitcoin but some form of escrowcoin) in a reserve (see reserveCoin) and allow to sell their usdc to the system at a slightly higher price than the target? You cannot warranty the solvency of the reserve, but it would prevent the price from dropping for more time until you have to rely on destructive fees/demurrage for that.

Note: I've removed the ticker and restored the less centralized "reporting exchange prices by miners". Also I hope you have forgotten the "messaging through value" thing.

[fellowtraveler]

Have you considered using OpenTransactions in addition to bitcoin?  OpenTransactions allows an issuing party to issue certificates which can be traded.  It is quite different from bitcoin but I believe it complements it well, especially in a scenario like you are attempting to construct.

It has been suggested elsewhere on this forum, but I'm not sure if you have seen it or thought about it.

I have to admit I just don't understand Open Transactions. I've read all about them, but I'm apparently too dense to see how they could do what I want (decentralized currency/commodity/stock trading). The bitcoin protocol can definitely do it, but I'm continually changing the implementation details, trying to get something easy to implement, cause I'm lazy.

Open-Transactions is basically a server, a library, and an API. (Many different services could be built on top of it. That's why you may have trouble visualizing exactly what it does.)

For example...

An online web-wallet could be built with it.  (I'd say "like MyBitcoin" except it seems you all have recently had a "bad experience" with that service...)

An online market exchange could also be built with it. (I'd say "like MtGox", except it seems you all have recently had a "bad experience" there as well.)

Those aren't hard to visualize, are they?

Some of OT's improvements:
1) Users could utilize untraceable cash.
2) Users could use instruments such as cheques, cashier's cheques, payment plans, etc.
3) Servers cannot forge transactions, nor can they change balances without the user's signature.
4) Many different currencies might be trading on a single server, such as gold-based contracts, silver-based contracts, dollar-based contracts, etc. There could be dozens of different markets, for different combinations of asset types.
5) The same currency, with the same issuer, could be available on many different servers.
6) Basket currencies are possible.

The other big difference (coming soon) will be voting pools for bitcoin reserves stored by OT servers, to prevent unfortunate incidents where servers are hacked, or otherwise disappear with your funds. I haven't coded voting pools yet, but they will prevent incidents such as those that occurred at MtGox and MyBitcoin.

I hope this clarifies.

PS Here's an example of a user interface built using OT: https://bitcointalk.org/index.php?topic=31032.msg399675#msg399675

[phillipsjk]

I don't really trust any protocol that relies on "burning" bitcoins. How do I know that the "burner" address really is an invalid address? It is possible to have an address made up of a human-readable string just by chance.

Edit: I know it is unlikely, but it would make deliberate address collisions much worse if they ever become computationally feasable.

[dacoinminster]

Why?  In order to be able to sell it for 1USD, someone must be willing to physically give you 1USD for it.  Who is going to do that?  What if noone wants to pay 1USD for them?  Then they are worthless.

This was explained pretty clearly in your other threads.. you can't do things like this without a trusted person actually holding the assets.  It should be pretty easy to understand.

The concept is quite easy to understand. My plans (similar to Morpheus' goldcoin/stablecoin proposal) depends on people being willing to pay the current bitcoin value of the underlying asset for a token representing that asset. The concept is similar to cash-settled futures, which also track commodity prices without ever actually delivering the product.

Ok, I think I got it.
This is basically like stablecoin being the only difference that you prevent the price to go too high by other mean. Instead of create inflation and give the new coins to the miners, the system would sell newly created coins in exchange of bitcoins being destroyed at a slightly higher price than the target.
You have an exchange of usdcoins for bitcoins inside the chain to track the btc/usdc rate and you would import the btc/usd rate using the same method that stablecoin uses so you can calculate the bitcoin target price.

Is it your idea?
If so...
I don't like the idea of destroying bitcoins and I don't think many people in the forum will. Also you would eventually destroy all the bitcoins in which your system relies. Can't the bitcoins just go to your miners?

Why not put them (for this you can't use bitcoin but some form of escrowcoin) in a reserve (see reserveCoin) and allow to sell their usdc to the system at a slightly higher price than the target? You cannot warranty the solvency of the reserve, but it would prevent the price from dropping for more time until you have to rely on destructive fees/demurrage for that.

Note: I've removed the ticker and restored the less centralized "reporting exchange prices by miners". Also I hope you have forgotten the "messaging through value" thing.

Man I love this forum. So many smart people . . .

You've got it exactly. More below . . .

I don't really trust any protocol that relies on "burning" bitcoins. How do I know that the "burner" address really is an invalid address? It is possible to have an address made up of a human-readable string just by chance.

Edit: I know it is unlikely, but it would make deliberate address collisions much worse if they ever become computationally feasable.

Personally, I HATE the idea of destroying bitcoins - they are so beautiful. The problem I have is who to give these bitcoins to. My first choice is myself of course, but that would be silly - nobody would trust me not to buy massive amounts of the commodity tokens from myself and flood the market. If I give the bitcoins to the miners, then they can do the same thing (spend unlimited bitcoins to themselves, getting free tokens). The perfect solution is to split the bitcoins evenly among everyone who holds bitcoins. It turns out that destroying bitcoins does exactly that - it makes everybody else's bitcoins a little more valuable.

The problem with my idea as discussed so far is that I had an unlimited number of tokens for sale, which allowed anyone receiving bitcoins in exchange for newly minted tokens to create infinite "wealth". Over the weekend I've pondered this question, and I think I have a couple better ways to distribute these goldcoins, oilcoins, etc.

1) The first option is to do what morpheus described (and what jtimon suggested above) and give the tokens to miners. A number of the new coins could be released to the address of the most recent miner with each new block. The number of new coins would be determined by the new protocol rules, and they would be "for sale" at a price also determined by the protocol rules. The miner would not have to be participating in this new protocol. Somebody would just send bitcoins to buy the tokens he doesn't know he is selling, and he would be very surprised

The only problem with that is, why would anyone run a ticker?

2) The second option makes the person running the ticker and the hole very, very rich (and I like that thought). The tokens would be released as described in 1), but to the hole instead of the miners. People would buy these new coins as they became available by sending bitcoins to the hole. However, the new coins would NOT be unlimited. They would be released in amounts and at prices determined by the protocol.

But there's a problem with that idea too - the person running the ticker and hole might decide to buy every coin as it became available, artificially limiting supply and making himself even richer.

My current best idea is to combine 1) and 2) - distributing some of the new coins to the miners, and some to the hole. My instinct is to give more to the miners to make sure that plenty of coins make it into circulation. Perhaps 75% to the miners and 25% to the hole.

I'm worried however that someone running the ticker/hole would then have a perverse incentive to mine (so that they could control more coins, limit the supply, and cause more coins to be released . . . to them). One person controlling a large portion of the coins seems dangerous, since they could flood the market or starve the market at their whim. Maybe the split should be more like 90/10.

Finally, I am starting to lean towards using a software PID controller to keep the new currency at the target price (see http://en.wikipedia.org/wiki/PID_controller). I work with PID loops all the time in my day job (autopilot software, temperature control chambers), so I am very familiar with how they work.

P = Proportional. This just means that the corrective action taken by the protocol is proportional to the price error. If the price is a little high, the protocol releases 10 new coins. If the price is a lot high, the protocol releases 100 new coins. Similarly, if the price is a little low, the protocol might destroy 0.1% of the new currency per transaction. If the price is a lot low, the protocol might destroy 1% of the new currency per transaction.

I = Integral (what do we do if proportional correction isn't working?). The integral term takes care of steady-state error. That is, what do we do if the price is ALWAYS a little too high? The integral term would slowly "wind up", causing more and more coins to be released until the price finally came down to the target. At this point, the integral term starts unwinding, but usually overshoots the target by a large amount (driving the price too low). Similarly, if the price is always too low, the integral term winds up in the other direction, slowly increasing the % of coins destroyed in each transaction until we reach the target. The I term is the most important one for this application, because it is the guarantee that we will eventually get to the target.

D = Differential (oh crap we're gonna overshoot!). The differential term resists ANY short-term movement. Even if the price is way too high, a sudden price drop would cause the differential term to shut off the flow of new coins temporarily. Similarly, a sudden price spike would cause the D term to release a lot of coins all at once.

Obviously we prefer generating coins to destroying them, so the PID controller would have to be biased positive, being stingy with new coin releases, and aggressive at cutting back on the new coin supply when the price starts dropping.

[jtimon]

Ok, I think I got it.
This is basically like stablecoin being the only difference that you prevent the price to go too high by other mean. Instead of create inflation and give the new coins to the miners, the system would sell newly created coins in exchange of bitcoins being destroyed at a slightly higher price than the target.
You have an exchange of usdcoins for bitcoins inside the chain to track the btc/usdc rate and you would import the btc/usd rate using the same method that stablecoin uses so you can calculate the bitcoin target price.

Is it your idea?
If so...
I don't like the idea of destroying bitcoins and I don't think many people in the forum will. Also you would eventually destroy all the bitcoins in which your system relies. Can't the bitcoins just go to your miners?

Why not put them (for this you can't use bitcoin but some form of escrowcoin) in a reserve (see reserveCoin) and allow to sell their usdc to the system at a slightly higher price than the target? You cannot warranty the solvency of the reserve, but it would prevent the price from dropping for more time until you have to rely on destructive fees/demurrage for that.

Note: I've removed the ticker and restored the less centralized "reporting exchange prices by miners". Also I hope you have forgotten the "messaging through value" thing.

Man I love this forum. So many smart people . . .

You've got it exactly. More below . . .

Thank you, but what you write below is different from my proposal (which is basically reservecoin combined with the stablecoin destruction method).

[dacoinminster]

Man I love this forum. So many smart people . . .

You've got it exactly. More below . . .

Thank you, but what you write below is different from my proposal (which is basically reservecoin combined with the stablecoin destruction method).

Quite true. May the best protocol win