Post
Topic
Board Development & Technical Discussion
Re: The Second Bitcoin Whitepaper
by
dacoinminster
on 26/07/2011, 21:12:53 UTC
"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 Smiley

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:


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.