[PROPOSAL] The Second Bitcoin Whitepaper

[dacoinminster]

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://bitcointalk.org/index.php?topic=29135.0

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


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

[1714974387]

1714974387

[1714974387]

1714974387

[1714974387]

1714974387

[dacoinminster]

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.

[notme]

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.

[hashcoin]

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.

[dacoinminster]

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.

[dacoinminster]

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.

[hashcoin]

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.

[dacoinminster]

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.

[hashcoin]

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.

[Fizzgig]

The commoners of the world have discovered a way to wrench economic control from the current power structure. They now discuss how the new economy should be engineered in a way that is consistent with mathematical laws. This insolence is unacceptable!!!

[bji]

First of all, I really think it's lame to use such a bait-and-switch forum topic.  You purposefully chose "The Second Bitcoin Whitepaper" because you want to attract readers to your topic, which, by the title, would seem to suggest that there is a second whitepaper and that the post reveals it.  It's annoying when people choose inflated topic titles to drive eyes to their topic, so don't do it.  You should realize, if you haven't yet, that lots of people have lots of ideas for ways to modify or extend bitcoin and yours is no more worthwile than many others, so stop touting it as if it is more than that.

Second of all, so many people come in here with ideas for adding rules to the bitcoin protocol to effect some pre-existing financial instrument that they desire bitcoin to reproduce.  There are a couple of problems with this:

1) Bitcoin is already established and you have almost no chance of making such fundamental changes even if your idea is wonderful.

2) Most people's ideas are not wonderful, they are well-intentioned but completely miss a very important issue: they are completely unimplementable.  There have been so many proposals for 'pegging' bitcoin value to some other real-world commodity value, but this is completely antithetical to the original purpose of, the original implementation of, and the spirit of, bitcoin.  Also, it's absolutely impossible without an external authority declaring the 'current' exchange rate, and external authorities is exactly what bitcoin does away with.

3) Most of these ideas completely miss the genius idea of bitcoin which is to produce a system of fully disclosed information that anyone can use to validate any transaction.  People propose all kinds of ways to 'peg' bitcoins value relative to something else, or to modify the number of bitcoins generated, or to introduce esoteric new transaction types that have some secondary effect ("contingent claims"), but without any idea how such things could ever be validated realistically and identically by all bitcoin peers.  Any source of external data, such as a "current value of oil" or "current value of gold", cannot implicity be agreed upon by all bitcoin peers, so immediately the ability for all peers to validate transations goes away.

Before you go too far out on any branch of ideas about additions to bitcoin to mimic some pre-existing financial instrument, please take a minute to very, very thoroughly think through exactly what new information will be contained in bitcoin transactions (don't understand bitcoin transactions, how they are represented in the protocol, and what the rules are for validating them?  Stop right here and don't go further until you do), and what new rules will be required for peers to follow to track and validate data necessary to validate transactions, and then whether or not this makes transactions impossible or impractical to validate.

The bitcoin protocol was very cleverly defined to require a minimum amount of data storage and network bandwidth to transmit, validate, and re-transmit validated transactions.  Does your proposal blow up the CPU, memory, and disk requirements for bitcoin peers to an unsustainable level?  If 100 transactions per second including your new protocol rules were transmitted, would any peer have any chance of validating them all?

You should have good evidence that your idea is even remotely workable before stating that there is or should be a "second bitcoin whitepaper" about it.

[dacoinminster]

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.

. . . .

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".

Hyperbitcoin vs bitcoin trading and exchange rates would be handled without an external exchange, so determining the exchange rate would be easy. All the other commodities and currencies would have their external exchange rates decided by voting, which would drive fees for the internal exchange rates, which would be driven by supply/demand (not voting). There would be very little motivation that I can see for anyone to mess with the external exchange rate voting. You might be able to annoy people by increasing fees a bit at the external spot price, but the vast majority of traders are going to vote for the correct external rate.

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.  

 . . .

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.

You are correct that a big drop in bitcoin prices would be the biggest test of this system. I imagine that the bitcoin protocol would have a target margin of safety for handling this. For instance, the target might be to maintain bitcoins in escrow worth 200% of the value of outstanding commodity/currency tokens if they were all redeemed at once for bitcoins. If the value of bitcoins in escrow fell, hyperbitcoins would be sold to speculators until the target was reached again. If the value of bitcoins in escrow rose, hyperbitcoins would be bought from speculators until the target was reached again. I THINK this would be plenty conservative, since an escrow system like this could easily hold LESS than the value of the tokens it owes if people trusted it (similar to a bank loaning more money than it has).

[dacoinminster]

First of all, I really think it's lame to use such a bait-and-switch forum topic.  You purposefully chose "The Second Bitcoin Whitepaper" because you want to attract readers to your topic, which, by the title, would seem to suggest that there is a second whitepaper and that the post reveals it.  It's annoying when people choose inflated topic titles to drive eyes to their topic, so don't do it.  You should realize, if you haven't yet, that lots of people have lots of ideas for ways to modify or extend bitcoin and yours is no more worthwile than many others, so stop touting it as if it is more than that.

I did not intend to pull a bait and switch. My intention is to discuss my proposal for what the second bitcoin whitepaper should cover. Would "My proposal for the second bitcoin whitepaper" be a better title?

Second of all, so many people come in here with ideas for adding rules to the bitcoin protocol to effect some pre-existing financial instrument that they desire bitcoin to reproduce.  There are a couple of problems with this:

1) Bitcoin is already established and you have almost no chance of making such fundamental changes even if your idea is wonderful.

Changing the protocol is quite possible. If more than 51% of users believe it is in their best interest to use the new protocol because it will increase the utility and value of bitcoins, then it will happen.

Trying to replace bitcoin with some wonderful new idea would be very difficult, but a proposal which extends the bitcoin protocol and adds value to existing bitcoins would go over quite well if people were convinced that it actually worked.

A change would probably take effect "after block #X" to give people time to switch to the new software before the change happens, similar to how Namecoin recently changed their protocol.

I believe my proposal would possibly even be backwards-compatible with the current bitcoin protocol.

What is not clear to me is what simulations or tests could be run on the protocol changes to ensure that they work as expected.

2) Most people's ideas are not wonderful, they are well-intentioned but completely miss a very important issue: they are completely unimplementable.  There have been so many proposals for 'pegging' bitcoin value to some other real-world commodity value, but this is completely antithetical to the original purpose of, the original implementation of, and the spirit of, bitcoin.  Also, it's absolutely impossible without an external authority declaring the 'current' exchange rate, and external authorities is exactly what bitcoin does away with.

Most "let's change bitcoin" ideas DO suck. Maybe mine does to, but I'm digging as hard as I can to find valid counter-arguments.

Bitcoin currently relies on nodes to maintain a distributed timestamp, which is actually based on . . . an external authority! I don't think we can claim that bitcoin relies on no external authority at all. It relies on nodes to cooperate to make sure the data from the external authority is accurately imported into the block chain.

I see no reason why data from other external authorities (like the current price of oil) couldn't be tracked in the block chain as well.

3) Most of these ideas completely miss the genius idea of bitcoin which is to produce a system of fully disclosed information that anyone can use to validate any transaction.  People propose all kinds of ways to 'peg' bitcoins value relative to something else, or to modify the number of bitcoins generated, or to introduce esoteric new transaction types that have some secondary effect ("contingent claims"), but without any idea how such things could ever be validated realistically and identically by all bitcoin peers.  Any source of external data, such as a "current value of oil" or "current value of gold", cannot implicity be agreed upon by all bitcoin peers, so immediately the ability for all peers to validate transations goes away.

My proposal does not require people to trade at the external exchange rate, it just nudges them in that direction by fee incentives to trade closer to that price. The actual price of oil-denominated bitcoins would be determined by good old-fashioned supply and demand.

Before you go too far out on any branch of ideas about additions to bitcoin to mimic some pre-existing financial instrument, please take a minute to very, very thoroughly think through exactly what new information will be contained in bitcoin transactions (don't understand bitcoin transactions, how they are represented in the protocol, and what the rules are for validating them?  Stop right here and don't go further until you do), and what new rules will be required for peers to follow to track and validate data necessary to validate transactions, and then whether or not this makes transactions impossible or impractical to validate.

The bitcoin protocol was very cleverly defined to require a minimum amount of data storage and network bandwidth to transmit, validate, and re-transmit validated transactions.  Does your proposal blow up the CPU, memory, and disk requirements for bitcoin peers to an unsustainable level?  If 100 transactions per second including your new protocol rules were transmitted, would any peer have any chance of validating them all?

You should have good evidence that your idea is even remotely workable before stating that there is or should be a "second bitcoin whitepaper" about it.

It is possible to store oil transaction data only on nodes that care about oil, gold transaction data only on nodes that care about gold, etc. The only thing that must be added to the bitcoin block chain is one additional hash of all the transactions being tracked in these other data stores. Clients that care only about bitcoin would just see this one additional hash. If they later decided to mess around with gold, they could download the gold transactions, hash them, then add that hash to the published hashes for oil transactions, euro transactions, etc, then hash that, then verify that hash matches the latest master hash in the bitcoin block chain. I may not have described this perfectly, but you can read more in the official write up (not by me) of how this would work here: https://en.bitcoin.it/wiki/Alternative_Chains

Of course it is possible that all the data could just be put into the block chain, especially once the official client starts downloading only the headers of old blocks for new users.

My proposal may indeed have a fatal flaw (I am searching for it), but if it doesn't, I don't think anyone can deny the massive increase in bitcoin utility and value this would bring.

[notme]

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.

Damn it, you added a dimension.  Now I have to think much harder to prove you wrong.

[dacoinminster]

Damn it, you added a dimension.  Now I have to think much harder to prove you wrong.

I need you, and I need people like you, to do exactly what you are doing.

You point out possible problems, vulnerabilities, and things which just aren't quite clear. In response, I have to modify, clarify, and elaborate.

Maybe the final product will be a useful set of changes that allow bitcoin to change the world (again), or maybe it will just be a fun exercise.

[bji]

I did not intend to pull a bait and switch. My intention is to discuss my proposal for what the second bitcoin whitepaper should cover. Would "My proposal for the second bitcoin whitepaper" be a better title?

"My proposal for the second bitcoin whitepaper" is more accurate and more descriptive, and yes, it would have been a better title.

Second of all, so many people come in here with ideas for adding rules to the bitcoin protocol to effect some pre-existing financial instrument that they desire bitcoin to reproduce.  There are a couple of problems with this:

1) Bitcoin is already established and you have almost no chance of making such fundamental changes even if your idea is wonderful.

Changing the protocol is quite possible. If more than 51% of users believe it is in their best interest to use the new protocol because it will increase the utility and value of bitcoins, then it will happen.

You have almost no chance of getting more than 51% of users to agree to anything anymore, which is my point.  There is a central cabal of people who may have more influence over bitcoin because they control the 'standard' client, or some large bitcoin-related website, or a bitcoin trading exchange, and maybe if you could get all of them to agree you could by fiat force the changes on everyone; but you're not going to get 51% of the actual bitcoin users to agree to anything, and it's highly unlikely that even the influential cabal I mentioned could all be swayed.

That being said, I don't mean to imply that no one should think big ideas about bitcoin or write proposals.  I just think that people should also be very realistic and be committed to a very long haul (years of stumping for the cause and making incremental changes) if they are serious about trying to make any fundamental changes to bitcoin.

Bitcoin currently relies on nodes to maintain a distributed timestamp, which is actually based on . . . an external authority! I don't think we can claim that bitcoin relies on no external authority at all. It relies on nodes to cooperate to make sure the data from the external authority is accurately imported into the block chain.

I see no reason why data from other external authorities (like the current price of oil) couldn't be tracked in the block chain as well.

The 'current time' as it is known to every person on the planet is not really an 'external authority'; it is more of a fact.  It has a precisely, scientifically, perfectly predictable value.  This is nothing even remotely like the "price of a commodity", which has no definite value and which, if a definitive value is required, implicitly needs an authority to resolve a diversity of differences of local opinion on the correct value.  Time is not artificial; the "exchange rate" for commodities is.  There is a major difference and it is precisely this difference that makes the latter impractical for use in the bitcoin protocol.

My proposal does not require people to trade at the external exchange rate, it just nudges them in that direction by fee incentives to trade closer to that price. The actual price of oil-denominated bitcoins would be determined by good old-fashioned supply and demand.

Well I like the idea of rules built into the system that effect a desired outcome through the natural action of market forces; but once again who is to define exactly what the 'external exchange rate' is such that everyone can be 'nudged' towards it?  Or is it OK for there to be uncertainty about the exact value as long as the differences between any two disagreeing opinions about the value don't differ by a large amount?

In lots of your discussion on this topic you talk about the protocol making payments based on excessive value in escrow etc; who is to decide exactly how and when this is to be done?  Obviously it has to be built into the rules of the protocol, so that everyone can, after the fact, all come to the exact same conclusion about what the current state of the global balance sheet is.  So how can that level of certitude be achieved without an external authority to be consulted on those parts of the equation ("current cost of gold at the moment in time that a transaction was validated") that cannot be known implicitly from data publicly stored in the block chain?

It is possible to store oil transaction data only on nodes that care about oil, gold transaction data only on nodes that care about gold, etc. The only thing that must be added to the bitcoin block chain is one additional hash of all the transactions being tracked in these other data stores. Clients that care only about bitcoin would just see this one additional hash. If they later decided to mess around with gold, they could download the gold transactions, hash them, then add that hash to the published hashes for oil transactions, euro transactions, etc, then hash that, then verify that hash matches the latest master hash in the bitcoin block chain. I may not have described this perfectly, but you can read more in the official write up (not by me) of how this would work here: https://en.bitcoin.it/wiki/Alternative_Chains

But miners would have to also validate the external data store before believing that the block that they are generating that includes that hash will be accepted by other miners, otherwise other miners will reject the block because it includes an invalid hash of this external data store.  Otherwise, anyone can generate a bitcoin block with any 'external data store' hash they wanted to and the bitcoin block miners, since they don't validate that hash in any way, would just keep on building the block chain based on that.  So the hash would essentially become worthless as it could be faked by anyone to represent any set of invalid transactions in the external data store that they wanted to.

Therefore, the problem I have expressed remains: even if individual clients don't bother to validate this extra hash if they don't care about the contents of the external data store that it represents, miners will have to.

My proposal may indeed have a fatal flaw (I am searching for it), but if it doesn't, I don't think anyone can deny the massive increase in bitcoin utility and value this would bring.

The fatal flaw is the reliance on an external authority to set a fixed, knowable, and perfectly-agreed-upon value for the exchange rate of bitcoins to the commodities you are interested in, and the ensuing impossibility of validating transactions (identically for all peers) that results.  Also I suspect, although I don't know because I still am not entirely clear on the way that the exchange of bitcoins into 'escrow' and back again is supposed to work, that all peers, including clients, will have to perform excessive and impractical work to determine if a transaction is valid when its history can include bitcoins that were put into escrow and taken back out again.

[dacoinminster]

"My proposal for the second bitcoin whitepaper" is more accurate and more descriptive, and yes, it would have been a better title.

I have added "[PROPOSAL]" to my thread title. Hopefully nobody else will be disappointed

You have almost no chance of getting more than 51% of users to agree to anything anymore, which is my point.  There is a central cabal of people who may have more influence over bitcoin because they control the 'standard' client, or some large bitcoin-related website, or a bitcoin trading exchange, and maybe if you could get all of them to agree you could by fiat force the changes on everyone; but you're not going to get 51% of the actual bitcoin users to agree to anything, and it's highly unlikely that even the influential cabal I mentioned could all be swayed.

That being said, I don't mean to imply that no one should think big ideas about bitcoin or write proposals.  I just think that people should also be very realistic and be committed to a very long haul (years of stumping for the cause and making incremental changes) if they are serious about trying to make any fundamental changes to bitcoin.

I agree that an argument that got the existing diverse user base to make a protocol change en-masse would have to be very compelling. If I can convince the community of my argument that this change would increase bitcoin values by about a million-fold, I think that would do the trick for most people.

Another possibility would be to split the block chain with people accepting the changes on one branch, and the old bitcoin protocol continuing on the other branch. That outcome would be much less desirable.

The 'current time' as it is known to every person on the planet is not really an 'external authority'; it is more of a fact.  It has a precisely, scientifically, perfectly predictable value.  This is nothing even remotely like the "price of a commodity", which has no definite value and which, if a definitive value is required, implicitly needs an authority to resolve a diversity of differences of local opinion on the correct value.  Time is not artificial; the "exchange rate" for commodities is.  There is a major difference and it is precisely this difference that makes the latter impractical for use in the bitcoin protocol.

. . .

Well I like the idea of rules built into the system that effect a desired outcome through the natural action of market forces; but once again who is to define exactly what the 'external exchange rate' is such that everyone can be 'nudged' towards it?  Or is it OK for there to be uncertainty about the exact value as long as the differences between any two disagreeing opinions about the value don't differ by a large amount?

In lots of your discussion on this topic you talk about the protocol making payments based on excessive value in escrow etc; who is to decide exactly how and when this is to be done?  Obviously it has to be built into the rules of the protocol, so that everyone can, after the fact, all come to the exact same conclusion about what the current state of the global balance sheet is.  So how can that level of certitude be achieved without an external authority to be consulted on those parts of the equation ("current cost of gold at the moment in time that a transaction was validated") that cannot be known implicitly from data publicly stored in the block chain?

I think you make a very good point that the external exchange rate does not have to be perfectly exact. I would guess that the official description for oil-based coins (for instance) would say something like:

Oil-backed bitcoins are nominally pegged to the average movements of the following reference prices:

• Bloomberg's "WTI Cushing Spot" (http://www.bloomberg.com/energy/)
• CNN's current futures contract for Light Crude (http://money.cnn.com/data/commodities/)
• The United States Oil ETF as reported by Google (http://www.google.com/finance?q=NYSE:USO)
• The iPath Crude Oil Futures ETF as reported by Yahoo (http://finance.yahoo.com/q?s=OIL)
• . . . more sources . . .

If one source diverges significantly from the others, it will be ignored. Nodes will determine the appropriate price change by executing the following algorithm on the data sources above:

. . . .

Nodes will reject blocks reporting an oil exchange rate more than 0.5% different from their implementation of the above algorithm.

Something like that seems like it would work well enough, IMHO.

But miners would have to also validate the external data store before believing that the block that they are generating that includes that hash will be accepted by other miners, otherwise other miners will reject the block because it includes an invalid hash of this external data store.  Otherwise, anyone can generate a bitcoin block with any 'external data store' hash they wanted to and the bitcoin block miners, since they don't validate that hash in any way, would just keep on building the block chain based on that.  So the hash would essentially become worthless as it could be faked by anyone to represent any set of invalid transactions in the external data store that they wanted to.

Therefore, the problem I have expressed remains: even if individual clients don't bother to validate this extra hash if they don't care about the contents of the external data store that it represents, miners will have to.

Miners already get to decide which transactions they include and which ones they don't include. I imagine that some or all of the small trading fees included in this plan would be paid to miners to give them a reason to implement the price tracking algorithms and include the extra transactions.

If they decide it isn't worth the work (or they are running an older version), they would just leave that hash out of their block entirely, and the fees would build up for the miner who was participating.

The fatal flaw is the reliance on an external authority to set a fixed, knowable, and perfectly-agreed-upon value for the exchange rate of bitcoins to the commodities you are interested in, and the ensuing impossibility of validating transactions (identically for all peers) that results.  Also I suspect, although I don't know because I still am not entirely clear on the way that the exchange of bitcoins into 'escrow' and back again is supposed to work, that all peers, including clients, will have to perform excessive and impractical work to determine if a transaction is valid when its history can include bitcoins that were put into escrow and taken back out again.

I imagine that "escrow" will be very much like any other bitcoin address, except only the protocol itself can control the coins there according to set rules which everyone agrees on. If somebody generated a block that said "the escrow fund paid all escrow coins to my address", the rest of the network would ignore that block because it didn't follow the rules.

[dacoinminster]

I sent this to Satoshi. Probably, he's just annoyed by this, but who knows?

From: **************
Date: Tue, Jul 26, 2011 at 3:29 PM
Subject: [PROPOSAL] The Second Bitcoin Whitepaper
To: satoshin@g**.com


Hi Satoshi,
 
I know you've been intentionally distant from your bitcoin project for some time now, but I thought you might be interested in my proposal for what could be included in "the second bitcoin whitepaper", extending your bitcoin protocol: http://forum.bitcoin.org/index.php?topic=31645.0

I don't expect a response, although obviously any response you chose to make would carry a lot of weight. If my proposal somehow becomes reality, I believe you could end up a trillionaire (by USD valuation).

Hope you are doing well and enjoying your bitcoin wealth to the fullest!

-********* (dacoinminster)

[notme]

We don't need bitcoin other than to allow us to include a block hash to secure our block chain, smaller than a transaction.  Maybe we even kick in a small transaction fee.  Our blocks can be built with cpu miners throttled to 10% of one core, or whatever keeps the CPU in the lowest power state.

[bji]

We don't need bitcoin other than to allow us to include a block hash to secure our block chain, smaller than a transaction.  Maybe we even kick in a small transaction fee.  Our blocks can be built with cpu miners throttled to 10% of one core, or whatever keeps the CPU in the lowest power state.

And how will you disallow someone from putting whatever they want to into the block hash value that you are piggybacking into the bitcoin block chain?  What's to stop someone from violating all of the rules, whatever those are, in the secondary block chain and getting the hash for that into the bitcoin block chain, thus completely fubar'ing your secondary chain?

The only thing that would stop this is if miners refused to include invalid secondary block hashes in the main bitcoin block chain; and to determine what secondary chain hashes are invalid would require that those miners validate everything in that block chain before including the hash of it into the bitcoin block chain.

Therefore, you cannot simply pickyback on the bitcoin block chain in a meaningful way without adding significant workload to the bitcoin miners, and that is not going to happen without significant recompense to them.  How are you going to manage that?

[notme]

In order for the above to work though, our blocks can't have a reward, otherwise people will have incentive to overpower it.  In fact, the block finder should pay the transaction fee to lock the chain to bitcoin.  Then, only those who value the security of the block chain have incentive to mine.

[notme]

We don't need bitcoin other than to allow us to include a block hash to secure our block chain, smaller than a transaction.  Maybe we even kick in a small transaction fee.  Our blocks can be built with cpu miners throttled to 10% of one core, or whatever keeps the CPU in the lowest power state.

And how will you disallow someone from putting whatever they want to into the block hash value that you are piggybacking into the bitcoin block chain?  What's to stop someone from violating all of the rules, whatever those are, in the secondary block chain and getting the hash for that into the bitcoin block chain, thus completely fubar'ing your secondary chain?

The only thing that would stop this is if miners refused to include invalid secondary block hashes in the main bitcoin block chain; and to determine what secondary chain hashes are invalid would require that those miners validate everything in that block chain before including the hash of it into the bitcoin block chain.

Therefore, you cannot simply pickyback on the bitcoin block chain in a meaningful way without adding significant workload to the bitcoin miners, and that is not going to happen without significant recompense to them.  How are you going to manage that?

Our client would still ignore invalid blocks even if they are bitcoin-stamped.

[dacoinminster]

In order for the above to work though, our blocks can't have a reward, otherwise people will have incentive to overpower it.  In fact, the block finder should pay the transaction fee to lock the chain to bitcoin.  Then, only those who value the security of the block chain have incentive to mine.

I think we could give the miner a transaction fee that is only valid if the rest of the nodes running the new protocol accept the hash in the block. That would give the miner a good incentive to get the exchange rates right.

[notme]

In order for the above to work though, our blocks can't have a reward, otherwise people will have incentive to overpower it.  In fact, the block finder should pay the transaction fee to lock the chain to bitcoin.  Then, only those who value the security of the block chain have incentive to mine.

I think we could give the miner a transaction fee that is only valid if the rest of the nodes running the new protocol accept the hash in the block. That would give the miner a good incentive to get the exchange rates right.

But do we need another hash race?  Why compete with bitcoiners for hardware?  You're just driving up costs for everyone.

[bji]

Our client would still ignore invalid blocks even if they are bitcoin-stamped.

So now every client needs to validate every single block just to be able to ensure that transaction that occurred sometime after that block does not rely on something that is invalidated?

Now you're back into the 'validating transactions is so impractical as to be impossible' scenario.

[bji]

In order for the above to work though, our blocks can't have a reward, otherwise people will have incentive to overpower it.  In fact, the block finder should pay the transaction fee to lock the chain to bitcoin.  Then, only those who value the security of the block chain have incentive to mine.

I think we could give the miner a transaction fee that is only valid if the rest of the nodes running the new protocol accept the hash in the block. That would give the miner a good incentive to get the exchange rates right.

Once again you're back to making transactions so hard to verify as to be impractical.  Now everyone who wants to detect whether or not a miner who claimed a transaction fee for a block that included one of your hashes, has to validate your entire secondary database, to determine whether the block is valid.  This is much more expensive than your earlier assertion that all you need "is a slot in the bitcoin block chain for a hash value".

[dacoinminster]

But do we need another hash race?  Why compete with bitcoiners for hardware?  You're just driving up costs for everyone.

I definitely don't want to compete with bitcoin hashing in any way. I just want to give miners an incentive to include an extra hash in the blocks they are already generating.

[notme]

Our client would still ignore invalid blocks even if they are bitcoin-stamped.

So now every client needs to validate every single block just to be able to ensure that transaction that occurred sometime after that block does not rely on something that is invalidated?

Now you're back into the 'validating transactions is so impractical as to be impossible' scenario.

Validation is orders of magnitude easier than discovering proof of work.  Only our client would do it, and it is something every bitcoin client does.  I don't see a problem.

[notme]

Our blockchain will in no way need to be verified by bitcoin, except when bitcoin enters or leaves.  That can happen much less frequently and carry a much larger transaction fee as incentive.

[dacoinminster]

Once again you're back to making transactions so hard to verify as to be impractical.  Now everyone who wants to detect whether or not a miner who claimed a transaction fee for a block that included one of your hashes, has to validate your entire secondary database, to determine whether the block is valid.  This is much more expensive than your earlier assertion that all you need "is a slot in the bitcoin block chain for a hash value"

Yes, fees paid to miners for including the new hash would NOT be backwards compatible with older versions of bitcoin. Only people running updated software would recognize that the miner collected the fee.

Anyone running the new software would have to verify that the hash matched the transactions and exchange rates they cared about. Anybody running a miner would have to check all transactions and exchange rates to decide if they need to reject any previous blocks.

I'm not sure to what extent the new protocol could be backwards-compatible with the old protocol. It seems like a lot of it could be backwards compatible, but you run into problems when you have a miner collect a fee that is only recognized by the new clients, then he tries to spend it. There might be no way to get around it except to get everyone switched to the new protocol.

[bji]

Our client would still ignore invalid blocks even if they are bitcoin-stamped.

So now every client needs to validate every single block just to be able to ensure that transaction that occurred sometime after that block does not rely on something that is invalidated?

Now you're back into the 'validating transactions is so impractical as to be impossible' scenario.

Validation is orders of magnitude easier than discovering proof of work.  Only our client would do it, and it is something every bitcoin client does.  I don't see a problem.

I am not sure about that.  Even validating simple bitcoin transactions requires knowing the entire history of the transaction chain that leads up to the transaction in question.  Except that because bitcoin only allows validated transactions into the block chain, and because each transaction completely spends the output of the prior transaction, you really only need to keep track of the most recent transaction in every chain of transactions.

In your proposal it seems that, since the bitcoin miners aren't doing any work at all to validate your data set before including the block, every client is going to have to evaluate every single data set completely in order to have an accurate picture of what transactions going forward from that point are valid and which ones aren't.  It just seems like an incredible multiplication of the amount of work for everyone.

With bitcoin, a client can keep just the block chain headers and from that, it can query to someone with more resources than itself to validate transactions in a light weight manner, and can verify their results based on the small block chain headers that it stores (~4 MB per year, easily sustainable for every bitcoin peer).  How will such a thing be done in your external block chain, which will have both valid and invalid blocks and for which the client will not know, just from bitcoin block headers, which ones were valid and which ones weren't?

[dacoinminster]

I am not sure about that.  Even validating simple bitcoin transactions requires knowing the entire history of the transaction chain that leads up to the transaction in question.  Except that because bitcoin only allows validated transactions into the block chain, and because each transaction completely spends the output of the prior transaction, you really only need to keep track of the most recent transaction in every chain of transactions.

In your proposal it seems that, since the bitcoin miners aren't doing any work at all to validate your data set before including the block, every client is going to have to evaluate every single data set completely in order to have an accurate picture of what transactions going forward from that point are valid and which ones aren't.  It just seems like an incredible multiplication of the amount of work for everyone.

With bitcoin, a client can keep just the block chain headers and from that, it can query to someone with more resources than itself to validate transactions in a light weight manner, and can verify their results based on the small block chain headers that it stores (~4 MB per year, easily sustainable for every bitcoin peer).  How will such a thing be done in your external block chain, which will have both valid and invalid blocks and for which the client will not know, just from bitcoin block headers, which ones were valid and which ones weren't?

I believe it is the same problem that bitcoin already solves. If somebody puts bad data into a block, the next miner running the new software would reject the previous block as if it had never been created. Normal users could wait for N confirmations on anything they care about, just like they do now.

[hashcoin]

I don't see how you think this can work.  Why would anyone vote for the correct exchange rate?  Any rational person would vote for the option that pays out the escrow funds to their side of the bet.

[cunicula]

3) Most of these ideas completely miss the genius idea of bitcoin which is to produce a system of fully disclosed information that anyone can use to validate any transaction.  People propose all kinds of ways to 'peg' bitcoins value relative to something else, or to modify the number of bitcoins generated, or to introduce esoteric new transaction types that have some secondary effect ("contingent claims"), but without any idea how such things could ever be validated realistically and identically by all bitcoin peers.  Any source of external data, such as a "current value of oil" or "current value of gold", cannot implicity be agreed upon by all bitcoin peers, so immediately the ability for all peers to validate transations goes away.

If you are referring to the specific "contingent claims" that I proposed, your criticism here is very far off the mark. My proposal suggests derivatives based upon mining difficulty precisely because difficulty can "be validated realistically and identically by all bitcoin peers." Difficulty derivatives do not require external data for validation.

If you are referring to "contingent claims" as a general concept, you might choose your language more carefully to avoid confusion.

[bji]

3) Most of these ideas completely miss the genius idea of bitcoin which is to produce a system of fully disclosed information that anyone can use to validate any transaction.  People propose all kinds of ways to 'peg' bitcoins value relative to something else, or to modify the number of bitcoins generated, or to introduce esoteric new transaction types that have some secondary effect ("contingent claims"), but without any idea how such things could ever be validated realistically and identically by all bitcoin peers.  Any source of external data, such as a "current value of oil" or "current value of gold", cannot implicity be agreed upon by all bitcoin peers, so immediately the ability for all peers to validate transations goes away.

If you are referring to the specific "contingent claims" that I proposed, your criticism here is very far off the mark. My proposal suggests derivatives based upon mining difficulty precisely because difficulty can "be validated realistically and identically by all bitcoin peers." Difficulty derivatives do not require external data for validation.

If you are referring to "contingent claims" as a general concept, you might choose your language more carefully to avoid confusion.

I was referring to it in the limited capacity in which I understood it, and in my understanding it introduced transaction chains that require extra work to validate.  But the comments I made in the specific topic never were addressed so I don't know if I was off the mark.

[cunicula]

3) Most of these ideas completely miss the genius idea of bitcoin which is to produce a system of fully disclosed information that anyone can use to validate any transaction.  People propose all kinds of ways to 'peg' bitcoins value relative to something else, or to modify the number of bitcoins generated, or to introduce esoteric new transaction types that have some secondary effect ("contingent claims"), but without any idea how such things could ever be validated realistically and identically by all bitcoin peers.  Any source of external data, such as a "current value of oil" or "current value of gold", cannot implicity be agreed upon by all bitcoin peers, so immediately the ability for all peers to validate transations goes away.

If you are referring to the specific "contingent claims" that I proposed, your criticism here is very far off the mark. My proposal suggests derivatives based upon mining difficulty precisely because difficulty can "be validated realistically and identically by all bitcoin peers." Difficulty derivatives do not require external data for validation.

If you are referring to "contingent claims" as a general concept, you might choose your language more carefully to avoid confusion.

I was referring to it in the limited capacity in which I understood it, and in my understanding it introduced transaction chains that require extra work to validate.  But the comments I made in the specific topic never were addressed so I don't know if I was off the mark.

Oh, you are right. I did fail to respond to you. Your post was unusually thoughtful, so I wanted to take my time in responding. Then I got distracted. Sorry. I will bump the thread with a response soon.

[dacoinminster]

I don't see how you think this can work.  Why would anyone vote for the correct exchange rate?  Any rational person would vote for the option that pays out the escrow funds to their side of the bet.

Again, the external exchange rate voting does not affect what the escrow funds pay out to whom (that is decided by supply and demand). The external exchange rate ONLY affects the fees on transactions, nudging them towards the external exchange rate.

Also, keep in mind that the only real mechanism for "voting" is to reject a block because it doesn't match the exchange rate you calculated. The vast, vast majority of clients have a strong incentive to get it right. It would take massive collusion to get more than 50% of the computing power to accept a different external exchange rate, and that would only accomplish an annoying change in the fee structure. There are a lot more lucrative things you could do with 51% of bitcoin hashing power.

I am totally confident that the distributed exchange rate would work just fine if implemented correctly. The main disruptive idea here is the transfer of volatility risk from the token holders to the hyperbitcoin holders. That is the scary new thing to me, and while it seems like it would work to me, it is not clear what the exact rules should be, or how it could be tested.

[cunicula]

I don't agree with your optimistic assessment of honest exchange rate reporting. You might want to look at my thread on " securing contingent claims" which discusses an alternative mechanism.

[dacoinminster]

I don't agree with your optimistic assessment of honest exchange rate reporting. You might want to look at my thread on " securing contingent claims" which discusses an alternative mechanism.

What, no link?!

Sigh. OK, I'll search for it. Here it is: http://forum.bitcoin.org/index.php?topic=19130.0

[dacoinminster]

Here's a thought experiment for you:

1) Starting condition: escrow fund contains $4T worth of bitcoins, $2T of that is from hyperbitcoin speculators
2) Satoshi sells 10K bitcoins because he wants to buy Australia, instantly driving down bitcoin prices by 10%
3) Protocol: "Escrow fund is 10% below target. Time to steal some hyperbitcoins from the speculators. YOINK!"
4) Speculators: *Jump out the window*
5) Protocol: "Now I'll sell these hyperbitcoins to new speculators. KA-CHING!"
6) New Speculators: Yay!
7) Ending condition: hyperbitcoin prices down some, escrow fund is back to target value, somebody cleans dead speculators off the pavement, new speculators can get rich when bitcoin prices come back

Now here's the important bit, which I just realized: What happens to bitcoin prices when the protocol sells a bunch of hyperbitcoins which it stole from existing speculators? Let's see, we removed a bunch of bitcoins from circulation and put them in the escrow fund. Less bitcoin supply = higher bitcoin prices.

Did the new bitcoin protocol just self-stabilize the price of bitcoins? Did we just create a bitcoin variant that resists price changes??

I'm not saying that bitcoin prices would be immobile, but that they would be inherently less volatile, because hyperbitcoin holders would be absorbing that volatility.

[dacoinminster]

Here's the alternate scenario:

1) Starting condition: $4M in the escrow fund, $2M from hyperbitcoin holders
2) Whole world: "What?! We can own/trade commodities/currencies with no fees or paperwork??" *Tries to fit trillions of dollars of value into a 21M coin hole*
3) Bitcoin prices: +100000000% (million-fold increase)
4) Protocol: "Hmmm. Escrow fund is a million times larger than the target. Time to distribute some wealth to hyperbitcoin holders."
5) Bitcoin holders: "We're rich!"
6) Hyperbitcoin holders: "We're double-rich"
7) That one guy who didn't have any bitcoin: *Jumps out window*

And finally, the doomsday scenario

1) Starting condition: $4T in the escrow fund, $2T from hyperbitcoin holders
2) Jon Stewart: "Bitcoins suck! The escrow fund will go insolvent!"
3) Whole world: *Tries to sell their bitcoins all at once, and any bitcoin-backed commodities/currencies they own*
4) Protocol: "Um, the escrow fund is 50% low . . . no 60% . . . no 70% . . . oh crap!"
5) Protocol: "Time to steal ALL the hyperbitcoins from the speculators: UBERYOINK!!"
6) Speculators: *Jump out window*
7) Protocol: "Anybody want to buy these hyperbitcoins?"
8 ) New Speculators: "No thanks, we're too skeered!"
9) Protocol: "Fine then. LET THERE BE BITCOINS!" *50M bitcoins appear in the escrow fund*
10) Satoshi: "That's inflation! You've ruined my baby!" *Jumps out window*
11) Bitcoin holders: "We're poor!" *Jump out window*
12) Protocol: "Sorry. I'll destroy some bitcoins if prices go up again. Hopefully we'll get down to the 21M number again.
13) Whole World: "We don't want bitcoins anymore"
14) Bitcoin prices -> $0
15) Protocol: "Let's see, to save the token-holders, I need to create infinity+1 bitcoins in the escrow fund. That does not compu..." *bitcoin implodes*
16) Oilcoin/GoldCoin/USDCoin holders *Jump out window*

Obviously the protocol cannot continue to stabilize prices if nobody wants bitcoins anymore. After reading my own doomsday scenario, I think that creating bitcoins out of thin air would be a very bad idea. I think at step 9 above, the protocol would just have to say: "Sorry token holders, you're screwed. The bitcoin show must go on!"

New doomsday scenario ending:
9) Protocol: "Sorry token-holders, while there are no speculators willing to absorb volatility, you will have to eat the volatility. Your OilCoins/AntiOilcoins GoldCoins/AntiGoldCoins will fluctuate in value with bitcoin prices until enough new speculators enter the ring."
10) Token holders: "Sigh. OK. We knew this was in the cards when we signed up. Maybe if we hold these pegged coins long enough, speculators will buy hyperbitcoins and replenish the escrow fund and we won't have to take a loss."

[bji]

3) Protocol: "Escrow fund is 10% below target. Time to steal some hyperbitcoins from the speculators. YOINK!"

That is the part that I simply do not understand.  The "protocol" is not an entity that can take actions.  The protocol is a set of rules that all peers use to evaluate the bitcoin messages they receive and build up a shared, agreed-upon concept of what the "global balance sheet" of bitcoin is (in the form of transaction chains stored in the block chain).  The protocol dictates rules about transaction validity that individual peers are free to ignore but since other peers have no incentive to ignore the rules, and incentives to obey them, a disobeying peer will get nowhere fast.  At every point in the complex dance of bitcoin peers, the protocol rules are constructed to cause natural agreement between everyone with minimal effort.  It's a thing of beauty.

You talk about the protocol as if it's something running somewhere in real time making decisions and effecting outcomes.  It's not that at all.  The protocol is a set of rules, and those rules must be set out ahead of time to effect the actions you want from the bitcoin peer network.  Not only that, the rules don't specify what any peer has to do, only what is valid for any peer to have done.  The protocol rules do not compel any action on the part of any peer, they establish criteria for deciding when what a peer has done is illegal, and because following these rules is to everyone's benefit due to the clever construction of the protocol, everyone naturally obeys them and everyone agrees when someone has done something against the protocol rules and ignores them identically.

So you have to formulate rules that can be described ahead of time and which, for any peer who doesn't know anything about the history of transactions in your system, can be used to ingest all of the block chain blocks and then decide on its own, independently of any other peer, what the state of the "global balance sheet" is after every block; and each peer must be able to do this identically.  The identically part is what, in my opinion, rules out appealing to external entities for values to use in protocol equations for determining validity of transactions, because nobody ought to, or ought to be expected to, rely on an external authority whom they have to trust gives out accurate information to everybody and who is always available to every bitcoin peer and always presents a true, factual, and consistent set of values when queried.

Furthermore, the requirement that the protocol establish rules that peers can use to verify transactions themselves using only the data available in the block chain (or other data that is publicly shared via the peer network and is cryptographically secure using hashes and forced work functions) means that the data sets and rules involved in verifying a given transaction must be minimal; otherwise, the work required to verify a transaction chain becomes prohibitive and gets even worse as the network scales.

This last part is why I keep asking for a concrete description of the rules that peers will have to follow to validate transactions.  If a client has to a) keep an entire history of every transaction in order to be able to evaluate the validity of a transaction chain (bitcoin peers don't due to the merkle trees), and/or b) appeal to external authorities which may or may not be accessible or trustworthy, and/or c) require the evaluation of complex relationships between transactions or escrow accounts or whatever, and/or d) require every peer to retain huge amounts of data on disk in order to be able to validate any transaction, and/or e) any number of other ways to make the work of peers to establish faith in the validity of a transaction impractical that I haven't thought of yet, then it is an unworkable system.

It is my supposition that your proposal suffers from more than one of these problems; and I've been trying to fish out more detail (admittedly I don't understand every aspect of your proposal so I'm trying to get you to consider my concerns and apply them to your system rather than doing it myself).  I don't think you should write to Satoshi or publish a white paper or take any other premature step before addressing these concerns.

[dacoinminster]

3) Protocol: "Escrow fund is 10% below target. Time to steal some hyperbitcoins from the speculators. YOINK!"

That is the part that I simply do not understand.  The "protocol" is not an entity that can take actions.  The protocol is a set of rules that all peers use to evaluate the bitcoin messages they receive and build up a shared, agreed-upon concept of what the "global balance sheet" of bitcoin is (in the form of transaction chains stored in the block chain).  The protocol dictates rules about transaction validity that individual peers are free to ignore but since other peers have no incentive to ignore the rules, and incentives to obey them, a disobeying peer will get nowhere fast.  At every point in the complex dance of bitcoin peers, the protocol rules are constructed to cause natural agreement between everyone with minimal effort.  It's a thing of beauty.

You talk about the protocol as if it's something running somewhere in real time making decisions and effecting outcomes.  It's not that at all.  The protocol is a set of rules, and those rules must be set out ahead of time to effect the actions you want from the bitcoin peer network.  Not only that, the rules don't specify what any peer has to do, only what is valid for any peer to have done.  The protocol rules do not compel any action on the part of any peer, they establish criteria for deciding when what a peer has done is illegal, and because following these rules is to everyone's benefit due to the clever construction of the protocol, everyone naturally obeys them and everyone agrees when someone has done something against the protocol rules and ignores them identically.

So you have to formulate rules that can be described ahead of time and which, for any peer who doesn't know anything about the history of transactions in your system, can be used to ingest all of the block chain blocks and then decide on its own, independently of any other peer, what the state of the "global balance sheet" is after every block; and each peer must be able to do this identically.  The identically part is what, in my opinion, rules out appealing to external entities for values to use in protocol equations for determining validity of transactions, because nobody ought to, or ought to be expected to, rely on an external authority whom they have to trust gives out accurate information to everybody and who is always available to every bitcoin peer and always presents a true, factual, and consistent set of values when queried.

You are quite right in your comments about the protocol. What I wrote in my thought experiment is equivalent to describing the current protocol with words like:

Miner: I found a block!
Protocol: Here's 50 bitcoins! Enjoy!
Miner (later): I found another block
Protocol: I'm only giving out 25 bitcoins per block now. Sorry!

For the protocol to steal 5% of all outstanding hyperbitcoins, all clients have to be running the same rules which cause them to all agree that users holding hyperbitcoins all have 5% less of them because the escrow fund passed some threshold.

Furthermore, the requirement that the protocol establish rules that peers can use to verify transactions themselves using only the data available in the block chain (or other data that is publicly shared via the peer network and is cryptographically secure using hashes and forced work functions) means that the data sets and rules involved in verifying a given transaction must be minimal; otherwise, the work required to verify a transaction chain becomes prohibitive and gets even worse as the network scales.

This last part is why I keep asking for a concrete description of the rules that peers will have to follow to validate transactions.  If a client has to a) keep an entire history of every transaction in order to be able to evaluate the validity of a transaction chain (bitcoin peers don't due to the merkle trees), and/or b) appeal to external authorities which may or may not be accessible or trustworthy, and/or c) require the evaluation of complex relationships between transactions or escrow accounts or whatever, and/or d) require every peer to retain huge amounts of data on disk in order to be able to validate any transaction, and/or e) any number of other ways to make the work of peers to establish faith in the validity of a transaction that I haven't thought of yet, then it is an unworkable system.

It is my supposition that your proposal suffers from more than one of these problems; and I've been trying to fish out more detail (admittedly I don't understand every aspect of your proposal so I'm trying to get you to consider my concerns and apply them to your system rather than doing it myself).  I don't think you should write to Satoshi or publish a white papeer take any other premature step before addressing these concerns.

Responding to the enumerated concerns, in order:

a) Clients only have to track transactions and exchange rates they care about. If I'm not trading or holding goldcoins, I don't have to download goldcoin transactions.
b) I believe I have described how external data can be imported into the block chain, especially when that data has multiple trusted sources and nodes can reject blocks containing data they believe to be invalid.
c) Yes. If the complex relationship between escrow and hyperbitcoins doesn't work and can't be fixed, then this idea just won't work
d) Miners would have to retain all data for transactions they wish to collect fees for. Peers need headers for bitcoin transactions only (like they do now) until they start playing around with advanced features.
e) Yes, there could be additional problems that haven't been imagined yet. That's what this thread is for

Thanks for your thoughtful analysis.

[dacoinminster]

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

[jtimon]

I move from the other thread, although I don't like the tittle of this one. Even if your proposal is possible to implement, you can't apply all this in the bitcoin chain. You better find a new name for your coins.

I think maybe I can understand it better with examples.

Oil is at 10 btc, I  want an oilCoin and you want and anti-oilCoin.
What's next? How much each of us put in escrow?

Oil rises to 11 btc. Does anything happen to the escrow? Do I get 1 btc or something?
Although you gave the direction, here we still have to resolve the problem (define the solution in a more concrete manner) of how the system knows the spot price of oil.

You said somewhere that the spot price of oil is not the same as the price of an oilCoin. Then how are oilcoins related to oil in any meaningful way?

[dacoinminster]

I move from the other thread, although I don't like the tittle of this one. Even if your proposal is possible to implement, you can't apply all this in the bitcoin chain. You better find a new name for your coins.

Yeah, I took a poll, and that seems to be the consensus.

I think maybe I can understand it better with examples.

Oil is at 10 btc, I  want an oilCoin and you want and anti-oilCoin.
What's next? How much each of us put in escrow?

Oil rises to 11 btc. Does anything happen to the escrow? Do I get 1 btc or something?
Although you gave the direction, here we still have to resolve the problem (define the solution in a more concrete manner) of how the system knows the spot price of oil.

You said somewhere that the spot price of oil is not the same as the price of an oilCoin. Then how are oilcoins related to oil in any meaningful way?

In your example, you and I would both buy the tokens we want on the open market (run within the network). There is no way for us to know where the tokens came from - we may have bought them from other users, or one of us may be buying tokens which were generated from thin air by the protocol in order to keep the tokens balanced and the escrow fund solvent.

When oil rises by 10%, the protocol will buy oiltokens and/or sell antioiltokens until funds in escrow are balanced. The exact combination of buying and selling would be determined by what keeps the escrow fund the healthiest.

You and I can't realize profits/losses until we sell our tokens, at which point we may be selling to other users and/or the escrow fund.

The price we buy and sell at is determined by us and the market. We have an incentive to trade close to the external spot price of oil, because the protocol charges an increasing fee the further we trade from the external spot price. The external spot price is imported into the block chain by miners, and their blocks are accepted or rejected by the rest of the network in exactly the same way that the distributed timestamps work.

[jtimon]

I think maybe I can understand it better with examples.

Oil is at 10 btc, I  want an oilCoin and you want and anti-oilCoin.
What's next? How much each of us put in escrow?

Oil rises to 11 btc. Does anything happen to the escrow? Do I get 1 btc or something?
Although you gave the direction, here we still have to resolve the problem (define the solution in a more concrete manner) of how the system knows the spot price of oil.

You said somewhere that the spot price of oil is not the same as the price of an oilCoin. Then how are oilcoins related to oil in any meaningful way?

In your example, you and I would both buy the tokens we want on the open market (run within the network). There is no way for us to know where the tokens came from - we may have bought them from other users, or one of us may be buying tokens which were generated from thin air by the protocol in order to keep the tokens balanced and the escrow fund solvent.

Ok, we don't know who I buy the tokens from. I just wanted a detailed example of the tokens creation.
The number of oilcoins will always be equal to the number of anti-oilcoins, right?

When oil rises by 10%, the protocol will buy oiltokens and/or sell antioiltokens until funds in escrow are balanced. The exact combination of buying and selling would be determined by what keeps the escrow fund the healthiest.

Isn't the system losing money on the process? If oil rises 10%, then drops 10%, then rises again...
The system is buying high and selling low.

You and I can't realize profits/losses until we sell our tokens, at which point we may be selling to other users and/or the escrow fund.

The price we buy and sell at is determined by us and the market. We have an incentive to trade close to the external spot price of oil, because the protocol charges an increasing fee the further we trade from the external spot price. The external spot price is imported into the block chain by miners, and their blocks are accepted or rejected by the rest of the network in exactly the same way that the distributed timestamps work.

And what's the spot price of an anti-oilcoin?

[dacoinminster]

Ok, we don't know who I buy the tokens from. I just wanted a detailed example of the tokens creation.
The number of oilcoins will always be equal to the number of anti-oilcoins, right?

At first I had thought this would be the case, but I believe that is impossible. Instead, the system would try to keep the anti-oilcoin escrow fund equal to the oilcoin escrow fund.

Isn't the system losing money on the process? If oil rises 10%, then drops 10%, then rises again...
The system is buying high and selling low.

. . .

And what's the spot price of an anti-oilcoin?

You are right that the system I described would buy oilcoins when they went up in price, and sell them when they went down in price. This would have the annoying effect of amplifying any price swings, although I doubt it would consistently lose money since it can always choose the best option between manipulating oilcoins or antioilcoins. I can't prove that though.

I've been frustrated trying to think of what the spot price of an antioilcoin should be. The simplest answer is 1/oilcoin, and you just have a lot more anti-oilcoins. However, no matter what price scheme I choose, they get out of balance after any price movement and require active intervention.

I'm also warming up to morpheus' idea to control prices with mining rewards: https://bitcointalk.org/index.php?topic=29135.msg367322#msg367322

He does this rather than using an "anti" coin and escrow fund, but I'm pondering whether the ideas could be combined.

[dacoinminster]

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://bitcointalk.org/index.php?topic=29135.0