Creating an "official" protocol specification for the Bitcoin internet currency

[justusranvier]

Yes, people do use and invest in Bitcoin because of the brand name and the brand mystique that was built around it. Just look at their reactions to any alternate cryptocurrency that is nearly identical from the technical point of view.

What you call "brand name and the brand mystique" I would call "first mover advantage, network effect, and human capital".

[1714944269]

1714944269

[totaleclipseofthebank]

Yes, people do use and invest in Bitcoin because of the brand name and the brand mystique that was built around it. Just look at their reactions to any alternate cryptocurrency that is nearly identical from the technical point of view.

What you call "brand name and the brand mystique" I would call "first mover advantage, network effect, and human capital".

focusing on "brand names" you might as well just use US dollars since they are the king in that department. bitcoin is cool because its a superior technology. your business school paradigms just aren't going to be all that useful here, sorry.

[2112]

Oh well, I've tried. I've really tried to point that each coin has at least two sides, and that includes Bitcoin.

Time will show what had really mattered: exact standards, network effects, first mover advantage, human capital and other presumed highfalutin concepts.

Or just this:

Bitcoin Pizza Index = $801,896.65 .... 

http://www.ounce.me

[TierNolan]

I agree, but what I think TierNolan was getting at, was just that the spec should count all blocks prior to (say) 250,000 as valid, even if some of them would not actually be under the new spec, i.e. they should be 'grandfathered in' even if the new spec would otherwise reject them. But the spec shouldn't allow future blocks to have the same 'deformities'.

Right.  Most of the block chain is presumably pretty clean already.

Basically the spec would be a sub-set of what is already acceptable to the current reference clients and also a (small) list of exceptions so that the current block chain is spec compliant.  I don't think you need to specify a switch date exactly.  The number of "non-standard" elements in the block chain would be finite anyway.

Ideally, the spec writers would get the agreement from > 50% of the miners to reject transactions and blocks that violate the draft (at least while the draft is in progress).

The exceptions could be a list of scripts that are defined as valid, even though they wouldn't be according to the spec.

[r.willis]

No need to enumerate "exceptions" from spec. Apply spec only from certain block number, use checkpoint hash to set all old blocks as valid. New spec-compliant do not need to to verify this old blocks, but only correctly parse them.

[aantonop]

Exactly as r.willis said.

Ideally, we would also implement a very small and lightweight protocol validation engine in Lisp and use that as reference implementation the for the protocol, and for interoperability, quality and eventually security certification.

At some point, "Talks Bitcoin Protocol" needs to be a verifiable statement, as with other protocol implementations. That way, a developer can test and validate that their client implementation passes all interop tests and speaks official "bitcoin".

Just like you can do W3C validation, or test an SSL client for protocol completeness, we should be able to test a bitcoin protocol node against something.

[TierNolan]

I think there also needs to be a "core" spec, which describes how blocks are validated and then a separate network spec.

[doobadoo]

I"m sure no one wants to here this, but maybe we need to start again.  Accept bitcoin as a grand experiment.  We've learned a lot.  Think thru all these issues:  block size issues, pruning, bitdust, gpu mining/asics.  Build a new client, with a firm protocol.  Better, faster, smarter.  Then launch it all over again.  Of course all the people techinically capable and involved all have a substantial stake in THIS bitcoin blockchain. 

Part of me is hoping that satoshi is out there somewhere.  Maybe working on this new, better cryptocurrency.  And when he returns and publishes the signed code on the alt-currency board every one will dump btc and jump on the new better one. 

I think he is the only one with the technical prowess, and the passion to see the idea REALLY work to the point where he may be willing take all his founders coins, cash them the fuck out quietly and then hit us with the REAL solution.  Call it the final solution. (No Jews were harmed making this post.)

[doobadoo]

In other words, you've magnamiously forfeited the advantage you had over the competition and commoditized your core product.

Maybe for the moment think of BTC as KFC (Kentucky Fried Coin) and your intention to publish a detailed information about the formula for the Colonel Sanders' secret seasoning and the process of how he arrived at it. You will immediately spawn numerous competitors peddling their version of Fried Chicken Coin.

If you don't like the above analogy then maybe think of how you would like to differentiate your Coca-Cola Coin from Pepsi-Cola Coin and RC-Cola Coin and whole slew of other immitators.

As an engineer you were probably trained to think that your goal is to minimize the number of defects in your software. Try for the moment to think like a CEO and maximize the stock price of your enterprise.

Do you see the problem now?

Dude i'm really having trouble understanding what in tar-nation you mean by this.  Are you suggesting that the dev team runs the bitcoin network bc, even though the client is open source, they have written it in a way that makes the spec amorphous, thus forcing every one to keep relying on them?  Solidifying Gavin & co's benevolent dictatorship?

[kjj]

In other words, you've magnamiously forfeited the advantage you had over the competition and commoditized your core product.

Maybe for the moment think of BTC as KFC (Kentucky Fried Coin) and your intention to publish a detailed information about the formula for the Colonel Sanders' secret seasoning and the process of how he arrived at it. You will immediately spawn numerous competitors peddling their version of Fried Chicken Coin.

If you don't like the above analogy then maybe think of how you would like to differentiate your Coca-Cola Coin from Pepsi-Cola Coin and RC-Cola Coin and whole slew of other immitators.

As an engineer you were probably trained to think that your goal is to minimize the number of defects in your software. Try for the moment to think like a CEO and maximize the stock price of your enterprise.

Do you see the problem now?

Dude i'm really having trouble understanding what in tar-nation you mean by this.  Are you suggesting that the dev team runs the bitcoin network bc, even though the client is open source, they have written it in a way that makes the spec amorphous, thus forcing every one to keep relying on them?  Solidifying Gavin & co's benevolent dictatorship?

You are new here.*  Over time, you'll learn to discern 2112's pearls from his effluent.  In this case, KFC's secret recipe is widely available for everyone to see, and both Coca-Cola Coin and RC-Cola Coin already exist, putting this post solidly in the latter category.

* Yes, I know you registered around the same date as me.  Not important.

[2112]

Dude i'm really having trouble understanding what in tar-nation you mean by this.  Are you suggesting that the dev team runs the bitcoin network bc, even though the client is open source, they have written it in a way that makes the spec amorphous, thus forcing every one to keep relying on them?  Solidifying Gavin & co's benevolent dictatorship?

Try to forget for a moment everything that you know about software engineering and think about yourself as a brand manager of a consumer product.

From now on the discussion isn't going to be about technical facts, it is going to be about the perception of facts amongs the non-technical people.

Do you think it possible to reverse engineer the recipe to the Kentucky Fried Chicken to such an accuracy that nobody will be able to distinguish it in a blind tasting? I think yes, but people will insist on sighted tasting and will claim that they are capable of distinguishing the true KFC from your Clone Fried Chicken.

If you don't like popular American consumer products then how about French wines? Why for example Veuve Clicquot is considered more valuable than many other "Appellation d'Origine Contrôlée, Méthode Champenoise" beverages? How did they achieved that value and how they maintained it? Do you think that it is impossible to produce a Californian sparkling wine that 99.9% drinkers will not be able to distinguish in a blind tasting from the original? I think that this will be relatively easy, but the clone wine will have much lower market price because everyone buys wine while looking at the labels, not by the taste.

For a non-engineer it is very easy to distinguish between say Bitcoin and Litecoin. For now everyone knows that the first Appelation d'Satoshi Controlee and the second is sovetskoye shampanskoye.

What if the market gets flooded with Bitcoin clones, e.g. Bitcoin over port 8888 (marketed to Chinese, with some Confucius' proverb in its block 0), etc. And every one of those clones will be able to show that they are produced exactly according to the original Satoshi method. Or they will be able to easily show how they improved the original recipe.

Bitcoin currently has a lot of very valuable brand equity, simply because it was first in its niche. The situation may however easily change once experienced brand managers decide to enter this niche with their clone products. Currently all the clones are marketed in a completely amateurish way. Or even much worse than amateurish, like the self-destructive marketing of SolidCoin.

[wumpus]

So, who dares to start writing a specification and actually getting it reviewed by everyone involved?

This has been the zillionth meta-discussion about this subject, debating whether it is possible or not, or a good idea or not, with other people trying to derail the thread into their own agenda. People will never be unanimous on those things, certainly not on a forum like this. So it is best to just try and see how far it gets.

There are two separate things to be written down, don't confuse them

(1) what is the current behavior of the (a) network and (b) block chain. This includes any satoshi-client specific warts. This is important for people that want to implement a client right now, and is mostly uncontroversial as it just has to be correct, complete and mostly self-contained.
This specification should be in the English language, written as clearly as possible and divided into sections, so that it is possible to write test cases against specific rules to validate the spec as well as the client.
The spec needs to be the form of human or mathematical descriptions, not "here's code" because code is not well-defined nor self-contained, we've seen this with the upgrade from bdb to leveldb.

(2) what would be the ideal behavior of the (a) network and (b) block chain. This is the above, but simplified, with strange warts and exceptions marked and removed. Through a process of staged upgrades it will eventually be possible to get here. This is very controversial, there will be a lot of disagreement, so it's better to start with (1).

You can start from the wiki document, but I would prefer something in git so that changes can be reviewed before they are pushed. Wikis are great for 'living documents', but not so much for specs.

Note that BlueMatt has already written a package of block chain and network handling tests (used by the pull tester on github, but not specific to the satoshi client), so it is best to synchronize with him.

I post a bounty of 10BTC (offer valid for 6 months) for the first person to take serious effort in the direction of (1). It is a huge, complex, messy job but it needs to be done. We really need a spec that documents what we have now.

[gmaxwell]

No need to enumerate "exceptions" from spec. Apply spec only from certain block number, use checkpoint hash to set all old blocks as valid. New spec-compliant do not need to to verify this old blocks, but only correctly parse them.

Even the minimal sane behavior is surprisingly complex. But beyond that, "lock old _invalid_ blocks in with checkpoints" is really pretty hideous. You'd still have to distribute code to validate them because part of the point of the system is that none of it depends on some magic values being trustworthy. Though perhaps its preferable to relegate the legacy support to a validation tool.

At the same time, there is really not that much legacy stuff that is really worth fixing.  Making some of the byte order more consistent— or what have you— is not worth the risk of a hardfork to get it.  A lot of the other complexity in the system rules is simply necessary...  a lot of things which are easy to specify when you don't need absolutely identical bit exact behavior become difficult when you do... and the nature of what we're doing implies bit exact behavior for almost everything that reads from the blockchain.

[TiagoTiago]

this is about defining a standard not a brand name (do people use the internet because of its brand name? what a load of bs)

If "bs" stands for "bullshit" then you have a gc above your head, where "gc" stands for "glass ceiling". There isn't anything wrong with being focused on technological aspects of development.

But completely ignoring the finacial and game-theoretic aspects of development is a serious disadvantage in career advancement.

Yes, people do use and invest in Bitcoin because of the brand name and the brand mystique that was built around it. Just look at their reactions to any alternate cryptocurrency that is nearly identical from the technical point of view.

The eggs are already scrambled, Bitcoin is open source. It is not the lack of proper specification that is gonna stop people from launching altcoins. If anything, not having a proper specification actually makes it easier for incompatible competitors to rise than for more development to be done on Bitcoin compliant software.



Btw, i hope the people working on this won't be stupid enough to just blindly accept any old block as valid; if you're gonna grandfather old blocks make sure they are the blocks you're looking for, don't accept just any old-looking block, otherwise an attacker could easily rewrite history.

[TiagoTiago]

...

At the same time, there is really not that much legacy stuff that is really worth fixing.  Making some of the byte order more consistent— or what have you— is not worth the risk of a hardfork to get it. 

If life-like tests are run on testnet, would there really still be a risk of unintentional hard-forking?

[r.willis]

gmaxwell, bitcoind, as I understand, uses checkpoints to speedup initial chain validation. I'm suggesting that this behavior will be documented in spec.

[gmaxwell]

gmaxwell, bitcoind, as I understand, uses checkpoints to speedup initial chain validation. I'm suggesting that this behavior will be documented in spec.

It does not, however, use it to skip the validation entirely. A chain cannot inflate the supply of coin regardless of what the checkpoints are set as. Checkpoints have absolutely no place in a Bitcoin specification, and as of right now they way they are used do not simplify the enforcement of the protocol rules.

Once we have header first syncing we will possibly eliminate checkpoints for any speed purpose.  (though may maintain a single one for a rewrite-doomsday security blanket).

[gmaxwell]

If life-like tests are run on testnet, would there really still be a risk of unintentional hard-forking?

uh. Testnet didn't prevent the hardforking we created in Bitcoin 0.8 even though we believe that the relevant cases were tested already. (there were already super large blocks there).

[r.willis]

It does not, however, use it to skip the validation entirely. A chain cannot inflate the supply of coin regardless of what the checkpoints are set as.

It's a fine check. I hope there is no quirks associated with this check?

Checkpoints have absolutely no place in a Bitcoin specification

Why not? It's just another way of limiting scope of some ruleset. It can be "no check", "relaxed check", "check this, do not check that", "check this way" etc. The other alternative is to limit scope with height. But checkpoint has additional benefit of making impossible creation of other spec-compliant chain going all the way to the root.

[justusranvier]

What I expect to happen is that somebody is eventually just going to start deploying an alternate implementation that will get significant usage. At some point there will be another chain-splitting bug and people running the alternate implementation, or the reference client, or both, will scramble to upgrade their nodes to fix the bug. We will probably have several more March 11th-style events until all the bugs are shaken out.

The goal of preventing unexpected forks at all cost is demonstrably futile. Better to just accept them as inevitable growing pains and prepare to deal with them as efficiently as possible when they happen.