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

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.

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:

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.

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

Those are both excellent documents and places to start, but what I had in mind was something more set-in-stone than a wiki page, that would have formalized procedures and barriers to prevent any one person from altering the protocol in the future.

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.

There is already plenty of work here:

     https://en.bitcoin.it/wiki/Protocol_specification

and here:

     https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals

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)

For more detailed elaboration of this idea please see the first link in my signature.

There isn't anything wrong with what you are proposing, aside from one thing: your proposal is completely skewed into the technical realm and into the total ignorance of marketing and game theoretic issues.

I'm an engineer by training, but I understand the language of business managers and marketing people. Unfortunately they rarely read this section of the forum, therefore you will normally not get the broad feedback that you desire.

What you are proposing is producing something akin to:
Nothing wrong with the above. But because it is open source somebody will soon transfer it to
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?

That isn't really the same thing, since the client version doesn't fully describe the protocol that defines a valid block.

Blocks have version numbers.

An interesting idea occurred to me... what if you could embed a hash of the protocol spec itself along in each block to be accepted by the network? This would mean that the definitions themselves could be set in stone.

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'. Assuming of course  there turn out to be any in the first ~250,000. So iron out the bugs going forward, but keep the blockchain, imperfect though it may be, up to a certain point. (Actually, not that I have much of a clue about these things, but isn't that kind of what the current system of checkpoints is for?)

Probably only good solution. Define the spec. Test it with bounties after general testing and do hard-fork at certain point. Preferably at this point there is multiple implementations and pools use different implementations.

I think inclusion bugs and quirks of satoshi client in spec will be counter-productive.
Spec should be "clean" and will take effect at some point in the future. By that date, everyone should upgrade their clients.

For a bounty, there needs to be a definition of exactly what is required.

Ideally, there would be a testing phase.  For example, blocks produced in accordance with the spec must be acceptable to all clients starting with version .  From here. it looks like version 4+ represents more than 90% of the client base.

Maybe, to claim the price the author would have to post 5-10% of the bounty as a reward for anyone who can create a spec compliant transaction or block that wouldn't be accepted by a version 4 or later client (or who finds a flaw with the spec).  If nobody manages to find such a block/transaction within 60 days, the author gets the bounty.  The author could slowly increase their bounty up to the required amount, since initially, there would likely be many flaws.

Also, the spec should be as compact as possible.  Ideally, it should cover what is needed to verify the block chain, as it currently is.  Exceptions should be used if a small number of blocks are only acceptable due to bugs.

Has anyone posted a bounty for this yet?  I don't know enough about SW development to properly define the bounty but I am certainly interested in contributing to one.

So what could happen is that big institutions will write a new spec for alt coin and start it fresh. Or someone else might do this.

That is one option. The idea works, but current implementation seems to be lacking... For wide scale...

I understand this. if we have such "strange" things everybody should know about it because it is not wise to let the price go up to 1000$/BTC and then release such important facts and risk that the price will go down again. you understand what I'm trying to say?

EDIT: the testnet should be become an important part of the change process of new releases. also within testnet we have the ability to use different codebase (https://code.google.com/p/bitcoinj/wiki/FullVerification) for mining without risk the healthy of the mainnet.