Pages:
Author

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

legendary
Activity: 1232
Merit: 1094
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.
legendary
Activity: 2128
Merit: 1073
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
sr. member
Activity: 451
Merit: 250
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.
legendary
Activity: 1400
Merit: 1013
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".
sr. member
Activity: 451
Merit: 250

There is already plenty of work here:

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

and here:

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



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.
legendary
Activity: 2128
Merit: 1073
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.
legendary
Activity: 1596
Merit: 1100
sr. member
Activity: 451
Merit: 250
For this reason, I think it would make sense to begin work (and it will be a lot of work!) on developing a working document, or some kind of mutually agreed upon standard that goes into greater depth than satoshi's paper on defining the nuts and bolts of what exactly Bitcoin is.
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:
Code:
#define HASH(x) sha256(x)
#define P2PPORT 8333
#define RPCPORT 8332
Nothing wrong with the above. But because it is open source somebody will soon transfer it to
Code:
#if defined(BITCOIN)
#define HASH(x) sha256(x)
#define P2PPORT 8333
#define RPCPORT 8332
#elif defined(LITECOIN)
#define HASH(x) scrypt(x)
#define P2PPORT 9333
#define RPCPORT 9332
#elif defined(IXCOIN)
/* ... */
#elif defined(I0COIN)
/* ... */
#endif
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?

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)
legendary
Activity: 2128
Merit: 1073
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.
For more detailed elaboration of this idea please see the first link in my signature.
legendary
Activity: 2128
Merit: 1073
For this reason, I think it would make sense to begin work (and it will be a lot of work!) on developing a working document, or some kind of mutually agreed upon standard that goes into greater depth than satoshi's paper on defining the nuts and bolts of what exactly Bitcoin is.
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:
Code:
#define HASH(x) sha256(x)
#define P2PPORT 8333
#define RPCPORT 8332
Nothing wrong with the above. But because it is open source somebody will soon transfer it to
Code:
#if defined(BITCOIN)
#define HASH(x) sha256(x)
#define P2PPORT 8333
#define RPCPORT 8332
#elif defined(LITECOIN)
#define HASH(x) scrypt(x)
#define P2PPORT 9333
#define RPCPORT 9332
#elif defined(IXCOIN)
/* ... */
#elif defined(I0COIN)
/* ... */
#endif
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?
sr. member
Activity: 451
Merit: 250
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.
Blocks have version numbers.

That isn't really the same thing, since the client version doesn't fully describe the protocol that defines a valid block.
legendary
Activity: 1400
Merit: 1013
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.
Blocks have version numbers.
sr. member
Activity: 451
Merit: 250
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.
hero member
Activity: 492
Merit: 503
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.

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?)
hero member
Activity: 728
Merit: 500
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.

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.
jr. member
Activity: 42
Merit: 11
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.
legendary
Activity: 1232
Merit: 1094
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.

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.
full member
Activity: 135
Merit: 107
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.
hero member
Activity: 728
Merit: 500
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...
legendary
Activity: 2856
Merit: 1520
Bitcoin Legal Tender Countries: 2 of 206
Let me give you one odd example.  The coinbase from the genesis block is unspendable.  At first, it was a bug that kept the txid out of the index, but now, we have to explicitly flag that transaction as unspendable.  If we don't, then Satoshi has the power to fork the network at will by redeeming it.  Basically, that bug has to be part of the specification, when one is written.  And there are more and stranger things that any node has to faithfully reproduce to keep the network sane, and we have no way of knowing that we've found them all.

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.
Pages:
Jump to: