Topic: Creating an "official" protocol specification for the Bitcoin internet currency - page 2. (Read 4701 times)

It is even lighter than the light client then.  It does a specific task and just focuses on that.

A light client means something else, so I wouldn't call armory a light client. Light client means it uses the bloom filter, or SPV part of the bitcoin protocol.

Uh, isn't it the opposite?  It is a light client that only handles your transactions. 

The combination of armour + the reference client is a full client, but the reference client is a full client on its own anyway.

so, i've been wondering something this thread brought up in my mind. armory is, or is not, a full client implementation? i don't run it, so i could be asking as dumb question.

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.

It's a fine check. I hope there is no quirks associated with this check?
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.

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

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, bitcoind, as I understand, uses checkpoints to speedup initial chain validation. I'm suggesting that this behavior will be documented in spec.

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

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.

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.

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.

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.

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.

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?

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

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

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.

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.