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://bitcointalksearch.org/topic/goldcoin-and-stablecoin-proposals-29135
Topic: [PROPOSAL] The Second Bitcoin Whitepaper (Read 6343 times)
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?
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?
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://bitcointalksearch.org/topic/m.367322
He does this rather than using an "anti" coin and escrow fund, but I'm pondering whether the ideas could be combined.
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?
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.
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?
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?
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.
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?
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?
[POLL] Add ideas from second bitcoin whitepaper proposal to bitcoin?
http://forum.bitcoin.org/index.php?topic=32417.0
http://forum.bitcoin.org/index.php?topic=32417.0
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.
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.
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.
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."
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."
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.
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.
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
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.
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.
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.
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.
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 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.
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?
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.
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?
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.
Jump to: