Multicoin, Namecoin, Goldcoin, Silvercoin, OilCoin, 1971coin, backed by bitcoin!

[vector76]

I see two things mixed together
1. a derivative system to stabilize value while someone else gets leverage, and
2. something akin to a fractional reserve banking system

I'm not sure how one ties into the other or why they must be connected.

Hyperbitcoins are leveraged and it is therefore possible for them to be underwater.  The owner can walk away, presumably losing their initial bitcoin 'collateral' but it is still a default.

If a hyperbitcoin were leveraged 2:1, say if it's effectively one bitcoin plus a derivative that's long bitcoins and short USD, then if bitcoins fall to below half their value, the hyperbitcoin is worth less than zero and the owner can discard it.  I don't see this as particularly unlikely since bitcoins today are less than half their high for the year.

[1714038025]

1714038025

[1714038025]

1714038025

[jtimon]

Dacoinminster, your idea depends on bitcoin (almost) always going up. That's what I don't like about it. In case of default, you can't print more bitcoins outside the bitcoin network, just IOUs.

vector76, what if we have the derivative contracts inside the chain an also an automated broker that liquidates/covers your position if the reserves get too low?
This way, you eliminate the default risk. If you want your position to exist longer, just put more funds in the escrow.
To make them fungible, the "additional funds" (the difference between the needed funds and the actual funds), should be returned to the seller when the oil-coin is sold. The buyer of the oil-coin can add more funds to the contract within the same transaction to avoid the contract to be liquidated because of a small change in price a block after the transaction is made.

I think it could work, but yes, you would need a counter-party in the derivative for each oil-coin issued. All contracts would be btc (or derivativecoin) denominated.

The network would rely on derivativecoin creation and/or in fees for the contracts creation and trades. The fees can be charged in bitcoins, derivativecoins or both.
There's no need to create another currency for this though. This way we could also see if fees are enough on their own.

[dacoinminster]

I see two things mixed together
1. a derivative system to stabilize value while someone else gets leverage, and
2. something akin to a fractional reserve banking system

I'm not sure how one ties into the other or why they must be connected.

Hyperbitcoins are leveraged and it is therefore possible for them to be underwater.  The owner can walk away, presumably losing their initial bitcoin 'collateral' but it is still a default.

If a hyperbitcoin were leveraged 2:1, say if it's effectively one bitcoin plus a derivative that's long bitcoins and short USD, then if bitcoins fall to below half their value, the hyperbitcoin is worth less than zero and the owner can discard it.  I don't see this as particularly unlikely since bitcoins today are less than half their high for the year.

My intention is to have the protocol sell more hyperbitcoins to speculators as bitcoin prices fall, decreasing everyone's leverage by diluting the hyperbitcoins which will also drive down hyperbitcoin prices faster than bitcoin prices (the leverage) and adding bitcoins to the escrow fund. When bitcoin prices rise, hyperbitcoins will be purchased from speculators by the protocol, increasing everyone's leverage and driving up hyperbitcoin prices faster than bitcoin prices (the leverage) using excess bitcoins from the escrow fund. I believe that by having the protocol control the hyperbitcoin supply and resulting leverage, the escrow fund can remain solvent in a sustainable way and prevent default as long as bitcoin remains a viable currency.

Dacoinminster, your idea depends on bitcoin (almost) always going up. That's what I don't like about it. In case of default, you can't print more bitcoins outside the bitcoin network, just IOUs.

vector76, what if we have the derivative contracts inside the chain an also an automated broker that liquidates/covers your position if the reserves get too low?
This way, you eliminate the default risk. If you want your position to exist longer, just put more funds in the escrow.
To make them fungible, the "additional funds" (the difference between the needed funds and the actual funds), should be returned to the seller when the oil-coin is sold. The buyer of the oil-coin can add more funds to the contract within the same transaction to avoid the contract to be liquidated because of a small change in price a block after the transaction is made.

I think it could work, but yes, you would need a counter-party in the derivative for each oil-coin issued. All contracts would be btc (or derivativecoin) denominated.

The network would rely on derivativecoin creation and/or in fees for the contracts creation and trades. The fees can be charged in bitcoins, derivativecoins or both.
There's no need to create another currency for this though. This way we could also see if fees are enough on their own.

I agree that the math is easier when bitcoin prices are going up, but I believe the protocol's control of hyperbitcoin prices and effective leverage also prevents default as described above. A more extreme situation, with panic-selling of both bitcoin and bitcoin-backed pegged-value tokens would require a more extreme response, for which I outline a couple possibilities in the first post of the sister thread: http://forum.bitcoin.org/index.php?topic=31645.0

You are correct that all currencies and commodities tracked would need a real-life counter-party (the escrow fund itself cannot be taking positions that have a net long or short position against oil/gold/Euros/etc). That is the intended function of GoldCoins vs AntiGoldCoins, etc.

[dacoinminster]

One non-obvious consequence of the rules described in my last post should be noted.

I stated that with falling bitcoin prices, hyperbitcoins are sold to speculators, diluting the existing hyperbitcoins and reducing their leverage.

However, for someone holding bitcoins, the effective leverage achieved by trading them for hyperbitcoins actually increases as prices fall. The system is effectively offering greater and greater leverage in exchange for your bitcoins, while existing hyperbitcoin holders get less and less value and leverage.

It might be desirable to amplify this effect when bitcoin prices are falling rapidly, perhaps actually destroying a small percentage of the hyperbitcoins held by each user to make the deal better for new hypercoin buyers. This would be an even more conservative approach to managing the escrow fund. I believe it might be possible to mathematically guarantee solvency with some high degree of probability.

[jtimon]

I agree that the math is easier when bitcoin prices are going up, but I believe the protocol's control of hyperbitcoin prices and effective leverage also prevents default as described above. A more extreme situation, with panic-selling of both bitcoin and bitcoin-backed pegged-value tokens would require a more extreme response, for which I outline a couple possibilities in the first post of the sister thread: http://forum.bitcoin.org/index.php?topic=31645.0

I've read this thread and I still think that your system has the risk of default (and the subsequent collapse).
Since you can't print bitcoins (not even for a while), you can default.

I don't know what is wrong with the derivatives with bitcoin escrows. You still get what you want, oil-coins.

You are correct that all currencies and commodities tracked would need a real-life counter-party (the escrow fund itself cannot be taking positions that have a net long or short position against oil/gold/Euros/etc). That is the intended function of GoldCoins vs AntiGoldCoins, etc.

If I've understood vector76 properly, you would have an oil-coin versus a derivative short oil and long bitcoin.
The problem I didn't get about fungibility is that any of the parties could redeem the contract at any time.
That problem could be reduced if the system can look for contracts enders on both sides of the bet.
Remember that both sides of the derivative are always solvent (or the contract is automatically redeemed).

I also came to the conclusion that you cannot use bitcoins for the escrow, because maybe you need to transfer bitcoins of it from a user to the other and you don't own the private keys.
You need derivativeCoin.

[dacoinminster]

I've read this thread and I still think that your system has the risk of default (and the subsequent collapse).
Since you can't print bitcoins (not even for a while), you can default.

My proposal in the sister thread actually mentions that temporarily printing bitcoins might be an emergency measure added to the protocol: http://forum.bitcoin.org/index.php?topic=31645.0

I don't know what is wrong with the derivatives with bitcoin escrows. You still get what you want, oil-coins.

Bitcoin-denominated derivatives are only slightly useful if bitcoin values are bouncing all over the place. I might be right that oil will rise 5% over the next six months, but my gain is dwarfed by a 50% drop in bitcoin values that I used to escrow my bet. I have to have some kind of bitcoin option strategy to hedge against a drop in bitcoin values, which is getting way too complicated for anyone but an options expert.

If I've understood vector76 properly, you would have an oil-coin versus a derivative short oil and long bitcoin.
The problem I didn't get about fungibility is that any of the parties could redeem the contract at any time.
That problem could be reduced if the system can look for contracts enders on both sides of the bet.
Remember that both sides of the derivative are always solvent (or the contract is automatically redeemed).

I also came to the conclusion that you cannot use bitcoins for the escrow, because maybe you need to transfer bitcoins of it from a user to the other and you don't own the private keys.
You need derivativeCoin.

Everything I have proposed so far requires changes to the existing bitcoin protocol. It might also be possible to engineer something that runs distributed, is backed by bitcoins, but does not need to touch the bitcoin block chain. I would be very interested to hear proposals on how that might work.

[jtimon]

I've read this thread and I still think that your system has the risk of default (and the subsequent collapse).
Since you can't print bitcoins (not even for a while), you can default.

My proposal in the sister thread actually mentions that temporarily printing bitcoins might be an emergency measure added to the protocol: http://forum.bitcoin.org/index.php?topic=31645.0

I know, that's why I'm telling you that you can't.

I don't know what is wrong with the derivatives with bitcoin escrows. You still get what you want, oil-coins.

Bitcoin-denominated derivatives are only slightly useful if bitcoin values are bouncing all over the place. I might be right that oil will rise 5% over the next six months, but my gain is dwarfed by a 50% drop in bitcoin values that I used to escrow my bet. I have to have some kind of bitcoin option strategy to hedge against a drop in bitcoin values, which is getting way too complicated for anyone but an options expert.

Well yes, since they're bitcoin denominated, the price in dollars of the commodity doesn't matter at all.
Since you got inputs from markets to the chain, you could also denominate them in dollars Even in dollars from 1971 or any other reference currency. Miners would have to agree on what PCI to look at.

If I've understood vector76 properly, you would have an oil-coin versus a derivative short oil and long bitcoin.
The problem I didn't get about fungibility is that any of the parties could redeem the contract at any time.
That problem could be reduced if the system can look for contracts enders on both sides of the bet.
Remember that both sides of the derivative are always solvent (or the contract is automatically redeemed).

I also came to the conclusion that you cannot use bitcoins for the escrow, because maybe you need to transfer bitcoins of it from a user to the other and you don't own the private keys.
You need derivativeCoin.

Everything I have proposed so far requires changes to the existing bitcoin protocol. It might also be possible to engineer something that runs distributed, is backed by bitcoins, but does not need to touch the bitcoin block chain. I would be very interested to hear proposals on how that might work.

It is very simple how it would work, you create another chain with your rules, if you need it, with its own currency.
After proposing to add demurrage to bitcoin (freicoin) I would say that is not easy to convince people when you have to modify the rules of what blocks are acceptable.
I have a second proposal that may be more acceptable by the bitcoin community. If it can't be added to bitcoin or namecoin, middlecoin will be needed.

[dacoinminster]

I know, that's why I'm telling you that you can't.

I yield on this issue. Bitcoins can't be created out of thin air. I've decided this after contemplating a doomsday scenario thought experiment here: http://forum.bitcoin.org/index.php?topic=31645.msg403514#msg403514

Well yes, since they're bitcoin denominated, the price in dollars of the commodity doesn't matter at all.
Since you got inputs from markets to the chain, you could also denominate them in dollars Even in dollars from 1971 or any other reference currency. Miners would have to agree on what PCI to look at.

So what happens if bitcoin prices fall 90%? I don't understand how the dollar-denominated contracts would stay valid without an escrow fund.

It is very simple how it would work, you create another chain with your rules, if you need it, with its own currency.
After proposing to add demurrage to bitcoin (freicoin) I would say that is not easy to convince people when you have to modify the rules of what blocks are acceptable.
I have a second proposal that may be more acceptable by the bitcoin community. If it can't be added to bitcoin or namecoin, middlecoin will be needed.

I agree that something like this might be the way to go, especially if the bitcoin community is lukewarm on the idea of polluting the protocol with my crazy ideas

[jtimon]

Well yes, since they're bitcoin denominated, the price in dollars of the commodity doesn't matter at all.
Since you got inputs from markets to the chain, you could also denominate them in dollars Even in dollars from 1971 or any other reference currency. Miners would have to agree on what PCI to look at.

So what happens if bitcoin prices fall 90%?

No matter the denomination, the contracts will be automatically redeemed before some of the parties is insolvent.
The problem with this is that the contracts can expire before the contracted date, but the funds in escrow for the other part are the maximum you should expect to win. If you're losing, you can always add more funds to avoid that the contract gets redeemed.
In fact you don't even have to liquidate the contracts when they are become "insolvent", both parties know the funds that are in escrow from the other party, they shouldn't expect to gain more than that.

I don't understand how the dollar-denominated contracts would stay valid without an escrow fund.

I'm just noting that the contracts could be denominated in a stable currency. The currency doesn't have to even exist, it can be defined as a basket of commodities or the dollar plus the increase in CPI from shadowstats. It doesn't have to be a currency. The contract could have rice vs gold or mac vs google.

I still think that the hardest part is to define what information must the miners include in the block and how is it going to be calculated that a block is valid or not.

I agree that something like this might be the way to go, especially if the bitcoin community is lukewarm on the idea of polluting the protocol with my crazy ideas

I like your idea for a distributed option market, but it requires many changes and some of them (the voting for the input of information from markets) are very risky. You need to move coins from an address to other with the only authorization from the original address of the contract, and the result of the contract depends on voting.

[dacoinminster]

No matter the denomination, the contracts will be automatically redeemed before some of the parties is insolvent.
The problem with this is that the contracts can expire before the contracted date, but the funds in escrow for the other part are the maximum you should expect to win. If you're losing, you can always add more funds to avoid that the contract gets redeemed.
In fact you don't even have to liquidate the contracts when they are become "insolvent", both parties know the funds that are in escrow from the other party, they shouldn't expect to gain more than that.

I'm just noting that the contracts could be denominated in a stable currency. The currency doesn't have to even exist, it can be defined as a basket of commodities or the dollar plus the increase in CPI from shadowstats. It doesn't have to be a currency. The contract could have rice vs gold or mac vs google.

I still think that the hardest part is to define what information must the miners include in the block and how is it going to be calculated that a block is valid or not.

I think I understand what you are suggesting. No counter-party risk is possible because the contract is liquidated before that can happen when bitcoin prices are diving.

While I would love to see something like this implemented, it does not address my primary desire of transferring risk from users who want stability to users who want to speculate.

I like your idea for a distributed option market, but it requires many changes and some of them (the voting for the input of information from markets) are very risky. You need to move coins from an address to other with the only authorization from the original address of the contract, and the result of the contract depends on voting.

I have to re-iterate, the result of the contract does not depend on voting at all. The external exchange rates only affect the fee structure when trades take place, encouraging people to trade near the external spot price. The actual trading price is determined by supply and demand within the bitcoin network. There is pretty much nothing to gain from taking over 51% of the bitcoin network hashing power to force a different exchange rate into the block chain. All you would accomplish would be to annoy people by changing the fee structure slightly. Much more lucrative uses of that hashing power can be found.

[jtimon]

I think I understand what you are suggesting. No counter-party risk is possible because the contract is liquidated before that can happen when bitcoin prices are diving.

When bitcoin prices are diving or when the prices of the commodities in the contract are.

While I would love to see something like this implemented, it does not address my primary desire of transferring risk from users who want stability to users who want to speculate.

Imagine you're a user that wants a stable value.
You hold some of the bitcoin from your sales (or wage or whatever) and invest some of them in a "1971 dollar vs bitcoin" contract.
The more bitbulls the more you will be able to gain if bitcoin falls. If bitcoin rises, you lose from the contract but gain from the bitcoins you hold, so with the right proportion you stay the same.

I like your idea for a distributed option market, but it requires many changes and some of them (the voting for the input of information from markets) are very risky. You need to move coins from an address to other with the only authorization from the original address of the contract, and the result of the contract depends on voting.

I have to re-iterate, the result of the contract does not depend on voting at all. The external exchange rates only affect the fee structure when trades take place, encouraging people to trade near the external spot price. The actual trading price is determined by supply and demand within the bitcoin network. There is pretty much nothing to gain from taking over 51% of the bitcoin network hashing power to force a different exchange rate into the block chain. All you would accomplish would be to annoy people by changing the fee structure slightly. Much more lucrative uses of that hashing power can be found.

The result of the contract (who gains, who loses and how much) depends on the voting, on the real price of the commodities.
The price you mean may differ is the price specified in the contract as a "draw" where neither party gains or loses.

[dacoinminster]

Imagine you're a user that wants a stable value.
You hold some of the bitcoin from your sales (or wage or whatever) and invest some of them in a "1971 dollar vs bitcoin" contract.
The more bitbulls the more you will be able to gain if bitcoin falls. If bitcoin rises, you lose from the contract but gain from the bitcoins you hold, so with the right proportion you stay the same.

Yes, I agree that kind of contract would accomplish what I want. It would not be seemless and easy for Grandma to use, but a sophisticated trader could make it work just fine. Maybe that is really all we need to attract those trillions of dollars, since most of them are controlled by sophisticated traders.

The result of the contract (who gains, who loses and how much) depends on the voting, on the real price of the commodities.
The price you mean may differ is the price specified in the contract as a "draw" where neither party gains or loses.

The voting affects the external price which affects the fees, but nobody forces you to buy or sell at that price within the bitcoin network. If you're willing to pay slightly higher fees, you can trade as far from the external spot price as you want.

Also, voters don't get to vote what they think the price is, they can only vote yes/no on whether to accept the latest block from a miner with the external price embedded. There's not any advantage to voting no if nobody else does. Messing with the exchange rate requires massive collusion with 51% of bitcoin hashing power. That's for sure not the first thing I would do with all that hashing power!

[jtimon]

Imagine you're a user that wants a stable value.
You hold some of the bitcoin from your sales (or wage or whatever) and invest some of them in a "1971 dollar vs bitcoin" contract.
The more bitbulls the more you will be able to gain if bitcoin falls. If bitcoin rises, you lose from the contract but gain from the bitcoins you hold, so with the right proportion you stay the same.

Yes, I agree that kind of contract would accomplish what I want. It would not be seemless and easy for Grandma to use, but a sophisticated trader could make it work just fine. Maybe that is really all we need to attract those trillions of dollars, since most of them are controlled by sophisticated traders.

Maybe some later service or client bring it closer to grandma, but that can be outside the chain.

The result of the contract (who gains, who loses and how much) depends on the voting, on the real price of the commodities.
The price you mean may differ is the price specified in the contract as a "draw" where neither party gains or loses.

The voting affects the external price which affects the fees, but nobody forces you to buy or sell at that price within the bitcoin network. If you're willing to pay slightly higher fees, you can trade as far from the external spot price as you want.

But when you send the sell order you don't know which miner is going to solve the next block nor what spot price he's going to report.

Also, voters don't get to vote what they think the price is, they can only vote yes/no on whether to accept the latest block from a miner with the external price embedded. There's not any advantage to voting no if nobody else does. Messing with the exchange rate requires massive collusion with 51% of bitcoin hashing power. That's for sure not the first thing I would do with all that hashing power!

The problem could be the opposite, miners accepting the blocks even when they have wrong spot prices in the fear that everybody will accept it and he's still mining for the old block.

[dacoinminster]

But when you send the sell order you don't know which miner is going to solve the next block nor what spot price he's going to report.

It doesn't matter what the next block reports for the spot price. The price executed would be decided by the buyer and the seller of the contract. The fee paid would be decided by the spot price immediately before their trade.

[dacoinminster]

[POLL] Add ideas from second bitcoin whitepaper proposal to bitcoin?
http://forum.bitcoin.org/index.php?topic=32417.0

[jtimon]

But when you send the sell order you don't know which miner is going to solve the next block nor what spot price he's going to report.

It doesn't matter what the next block reports for the spot price. The price executed would be decided by the buyer and the seller of the contract. The fee paid would be decided by the spot price immediately before their trade.

I mean the spot price at the moment of redemption.

[dacoinminster]

I mean the spot price at the moment of redemption.

Yes, that would be the external spot price which I keep insisting matters very little. The price of a sale is decided by the buyer and the seller of the contract. They have an incentive to meet at the external spot price, but the incentive is small.

[jtimon]

I mean the spot price at the moment of redemption.

Yes, that would be the external spot price which I keep insisting matters very little. The price of a sale is decided by the buyer and the seller of the contract. They have an incentive to meet at the external spot price, but the incentive is small.

But when the contracts are redeemed automatically (before becoming "insolvent") and when is decided who was right in his bet and how much has to get from the other's party escrow is when the external spot price matters. If it didn't matter, we didn't had to input information from the markets.

[dacoinminster]

But when the contracts are redeemed automatically (before becoming "insolvent") and when is decided who was right in his bet and how much has to get from the other's party escrow is when the external spot price matters. If it didn't matter, we didn't had to input information from the markets.

Ah, got it. You're talking about your auto-dissolving contracts. Yes, that would be a problem in that case.

[jtimon]

But when the contracts are redeemed automatically (before becoming "insolvent") and when is decided who was right in his bet and how much has to get from the other's party escrow is when the external spot price matters. If it didn't matter, we didn't had to input information from the markets.

Ah, got it. You're talking about your auto-dissolving contracts. Yes, that would be a problem in that case.

But what is the other case?