Prop: A Bitcoin-Qt/Bitcoind protocol release that's guaranteed to stay the same.

[Atlas]

In order to introduce great certainty in the Bitcoin economy at-large, whether it be in the mind of a regular user, merchant or an investor, we need to make sure Bitcoin as a currency remains stable in form. People need not be able to question that Bitcoin can change its rules --whether the rule be minor or significant-- in the face of major social influence of the current "official" dev team or otherwise.

I think we can all agree that if the Bitcoin protocol was vulnerable at its core, it would of been compromised by now. No major change is needed in that respect, whether it be novelty or a new idea of an experiment in cryptocurrency.

In face of this, I propose the Bitcoin.org dev team makes decree that the Bitcoin protocol set in the compatible Bitcoin-Qt/Bitcoind releases of 0.7.1 and below as well as beyond, not be changed for a period of at least 5 years -- in Bitcoin.org's respective releases. They should agree that their efforts and ambitions are not greater than the survival and integrity of the Bitcoin currency as a whole, and that with their great social influence comes great responsibility.

So, again, for the good of Bitcoin, please promise us that you will not be attempting to change the Bitcoin protocol for at least 5 years, Bitcoin.org.

Thank you.

P.S. Why five years? So new competing releases have time to develop and challenge any dangerous changes that come our way.

[Atlas]

I will also add that recently a bug was found in Bitcoin-Qt's latest build (Ultraprune) that changed the Bitcoin protocol, inadvertently. If this were released, people running older Bitcoin software would be forced to fork into a separate Bitcoin currency that might of had little to no acceptance. This scenario would be traject if the actual protocol changes were not fully announced.

I will say over and over again, the Bitcoin.org dev team has a lot of power that must be watched with extreme caution.

Imagine if a release was made that didn't change the protocol fundamentally until a later time and the software had already been accepted by mostly everybody? This may not be feasible but it's one question of many others when it comes to the power of a single core software developer in the community.

There are many men who would like to see Bitcoin as a competing currency gone and they will be willing to penetrate our sphere of influence to do it. Stay awake.

Addendum: The Bitcoin.org dev team may makes claim of democracy, transparency and good faith but so do governments and other organizations, which will always inevitably fail. People fail and if Bitcoin is not to fail it must not depend on a lone group of people.

[Stapleddiet]

You do realise that Bitcoin is an experimental currency as the warning states on bitcoin.org 'Bitcoin is an experimental new digital currency that enables instant payments to anyone, anywhere in the world.'

The word experimental to me brings up things like expect change until its been gotten right. As is there has been a lot of faith in the terms of money from punters such as myself and time from the devs etc. that it will succeed eventually but it is still a risk, one that I willingly take. I have not found any guarantees for Bitcoin yet.

I put faith in the devs that they are doing the right thing, if they had nefarious intentions it would of been far more easily to implement in the past than now as each day passes. I dont have a coding background so I also have to have faith in those that do and keep an eye on the code.

Educate yourself on how to actually fix your perceived problems, learn coding, make your own fork etc.

Get some life experience as well.

[Atlas]

You do realise that Bitcoin is an experimental currency as the warning states on bitcoin.org 'Bitcoin is an experimental new digital currency that enables instant payments to anyone, anywhere in the world.'

The word experimental to me brings up things like expect change until its been gotten right. As is there has been a lot of faith in the terms of money from punters such as myself and time from the devs etc. that it will succeed eventually but it is still a risk, one that I willingly take. I have not found any guarantees for Bitcoin yet.

I put faith in the devs that they are doing the right thing, if they had nefarious intentions it would of been far more easily to implement in the past than now as each day passes. I dont have a coding background so I also have to have faith in those that do and keep an eye on the code.

Educate yourself on how to actually fix your perceived problems, learn coding, make your own fork etc.

Get some life experience as well.

No, Bitcoin.org and Bitcoin.it claims its an experimental currency. That is not the consensus. That is not the 110 million dollar consensus in the exchange market.

Faith doesn't cut it when it comes to money. The more real certainty, the better and we must not a look at the dev team now but in the future. A power structure over a very successful Bitcoin is prone to corruption: The incentive would grow exponentially.

I don't need code experience to know its risky to change up Bitcoin. Again, there are bugs generated everyday and they could easily be found in a protocol change that could be a major vulnerability. I value Bitcoin as-it-is and so do many others. We are not throwing that love away just because of sensibilities and our purported lack of license.  

And we have forks. Plenty of them. Litecoin is not likely to have the same momentum. We are sticking with Bitcoin and making sure it retains its security and value which can only be ruined through reckless change. I have enough life experience and knowledge of history to know how things go to shit and how things become corrupt.

The United States came with a clear limitation of powers that were gradually changed by a centralized federal government. The US government now gains further control of the lives of its citizens and the people all around the world. Let's not let that happen here with our Bitcoins.

Again, the Bitcoin.org development team acting as the single outlet for Bitcoin maintenance and change is dangerous.

[theymos]

Bitcoin (or maybe just bitcoind) would be quickly out-competed if that rule was adopted. Many protocol changes have been made (Satoshi probably made dozens of them after 0.1) and many more will be necessary to keep Bitcoin secure and scalable.

Satoshi seemingly had a policy that clients should work (maybe with less security) for at least two years after they were released. I think this is a good goal.

Ultraprune is not a protocol change, so this proposed rule would have no effect on that.

[Atlas]

(or maybe just bitcoind) would be quickly out-competed if that rule was adopted.

That is the point. Development would not stop. Bitcoin would not be stopped. Only a certain (and currently central) sect of it will and it would only apply to protocol changes, not client development. This prop should not be feared. The success of Bitcoin does not depend on the Bitcoin.org development team.

The goal is true decentralization.

[kaerf]

In order to introduce great certainty in the Bitcoin economy at-large, whether it be in the mind of a regular user, merchant or an investor, we need to make sure Bitcoin as a currency remains stable in form. People need not be able to question that Bitcoin can change its rules --whether the rule be minor or significant-- in the face of major social influence of the current "official" dev team or otherwise.

I think we can all agree that if the Bitcoin protocol was vulnerable at its core, it would of been compromised by now. No major change is needed in that respect, whether it be novelty or a new idea of an experiment in cryptocurrency.

In face of this, I propose the Bitcoin.org dev team makes decree that the Bitcoin protocol set in the compatible Bitcoin-Qt/Bitcoind releases of 0.7.1 and below as well as beyond, not be changed for a period of at least 5 years -- in Bitcoin.org's respective releases. They should agree that their efforts and ambitions are not greater than the survival and integrity of the Bitcoin currency as a whole, and that with their great social influence comes great responsibility.

So, again, for the good of Bitcoin, please promise us that you will not be attempting to change the Bitcoin protocol for at least 5 years, Bitcoin.org.

Thank you.

P.S. Why five years? So new competing releases have time to develop and challenge any dangerous changes that come our way.

I think that's a whopper of an assumption. It can take years/decades to find weaknesses in crypto systems....meaning someone might find a vulnerability tomorrow or someone might find a vulnerability in several years. Given the narrow adoption of bitcoin, I'd say there hasn't been enough significant research to dismiss bitcoin's protocol as fundamentally sound. In fact, there never will be. We're always questioning and finding vulnerabilities in (existing) crypto systems.

Furthermore, the ability to change the protocol in the face of a vulnerability is a strength of bitcoin not a weakness.

[theymos]

That is the point. Development would not stop. Bitcoin would not be stopped. It should not be feared. The success of Bitcoin does not depend on the Bitcoin.org development team.

The goal is true decentralization.

Might as well just explicitly declare the end of the bitcoind development project.

bitcoind is currently the only stable implementation of a full Bitcoin node AFAIK, so if the bitcoin.org project was closed everyone would move to some fork of bitcoind. Probably a fork maintained by the current developers of the bitcoin.org client. There wouldn't be much increase in "decentralization".

[Atlas]

In order to introduce great certainty in the Bitcoin economy at-large, whether it be in the mind of a regular user, merchant or an investor, we need to make sure Bitcoin as a currency remains stable in form. People need not be able to question that Bitcoin can change its rules --whether the rule be minor or significant-- in the face of major social influence of the current "official" dev team or otherwise.

I think we can all agree that if the Bitcoin protocol was vulnerable at its core, it would of been compromised by now. No major change is needed in that respect, whether it be novelty or a new idea of an experiment in cryptocurrency.

In face of this, I propose the Bitcoin.org dev team makes decree that the Bitcoin protocol set in the compatible Bitcoin-Qt/Bitcoind releases of 0.7.1 and below as well as beyond, not be changed for a period of at least 5 years -- in Bitcoin.org's respective releases. They should agree that their efforts and ambitions are not greater than the survival and integrity of the Bitcoin currency as a whole, and that with their great social influence comes great responsibility.

So, again, for the good of Bitcoin, please promise us that you will not be attempting to change the Bitcoin protocol for at least 5 years, Bitcoin.org.

Thank you.

P.S. Why five years? So new competing releases have time to develop and challenge any dangerous changes that come our way.

Furthermore, the ability to change the protocol in the face of a vulnerability is a strength of bitcoin not a weakness.

Who says I want to stop that? I just want to decentralize it. I don't want to end development. I just want to end the authority surrounding it.

[Atlas]

That is the point. Development would not stop. Bitcoin would not be stopped. It should not be feared. The success of Bitcoin does not depend on the Bitcoin.org development team.

The goal is true decentralization.

Might as well just explicitly declare the end of the bitcoind development project.

bitcoind is currently the only stable implementation of a full Bitcoin node AFAIK, so if the bitcoin.org project was closed everyone would move to some fork of bitcoind. Probably a fork maintained by the current developers of the bitcoin.org client. There wouldn't be much increase in "decentralization".

Here's the question: Would a unofficial, newly created forked have as great of a cloud of influence? Would it have the same authority Bitcoin.org has now?

[theymos]

Here's the question: Would a unofficial, newly created forked have as great of a cloud of influence? Would it have the same authority Bitcoin.org has now?

It'd have nearly the same amount of influence if all of the main developers transferred to it.

[Atlas]

Here's the question: Would a unofficial, newly created forked have as great of a cloud of influence? Would it have the same authority Bitcoin.org has now?

It'd have nearly the same amount of influence if all of the main developers transferred to it.

Assuming there is no competition.

[Stapleddiet]

That is the point. Development would not stop. Bitcoin would not be stopped. Only a certain (and currently central) sect of it will and it would only apply to protocol changes, not client development. This prop should not be feared. The success of Bitcoin does not depend on the Bitcoin.org development team.

The goal is true decentralization.

You are free to join the team now if you have the skills as far as I am aware. What is you want is a chaotic mob of developers with no central goal or theme?

True decentralisation, I thought that was the goal of the working p2p network side and had nothing to do with development.

To make something complex there needs to be organisation and some hierarchy. I wish through my working life I could of turned up when I wanted and done whatever I wanted.

How do you propose development happens without a controlling team or is it just the one thats in place you have a problem with? Who will replace the team thats in now or who would oversee it so it doesnt end up a mess of oodles of useless code?

Dont forget that if it wasnt for the current team Bitcoin would not have this 100+mill cap now.

Seriously who do you work for? You spend far to much time trying to undermine what is happening with Bitcoin growth, development and the team than a school kid with an obsession. You state you worry for peoples money but what have you done for, built or backed with cash in Bitcoin?

[Stapleddiet]

No, Bitcoin.org and Bitcoin.it claims its an experimental currency. That is not the consensus. That is not the 110 million dollar consensus in the exchange market.
It does not matter what the consensus says, the fact is it is an experiment albeit with real world consequences for those of us who are hoping on it working

Faith doesn't cut it when it comes to money. 
Sure it does, what backs money gold etc. If not faith.
The more real certainty, the better and we must not a look at the dev team now but in the future. A power structure over a very successful Bitcoin is prone to corruption: The incentive would grow exponentially.
How would that happen with the development, the best thing the team can do is make it work if its wealth they want

I don't need code experience to know its risky to change up Bitcoin.
as one of the devs has said changing things is like trying to rebuild a car while its racing(or along those line)
Spreading FUD though helps to know what your on about

Again, there are bugs generated everyday and they could easily be found in a protocol change that could be a major vulnerability. I value Bitcoin as-it-is and so do many others. We are not throwing that love away just because of sensibilities and our purported lack of license.
You are not mentioning the bugs already found and fixed 

And we have forks. Plenty of them. Litecoin is not likely to have the same momentum. We are sticking with Bitcoin and making sure it retains its security and value which can only be ruined through reckless change. I have enough life experience and knowledge of history to know how things go to shit and how things become corrupt.
More FUD from you going by the history of whats been done and fixed by the team

The United States came with a clear limitation of powers that were gradually changed by a centralized federal government. The US government now gains further control of the lives of its citizens and the people all around the world. Let's not let that happen here with our Bitcoins.
The US govt has SFA to do with me

Again, the Bitcoin.org development team acting as the single outlet for Bitcoin maintenance and change is dangerous.
Life is dangerous, get a warm blanket and watch Foxtel much safer overall.

[FreeMoney]

Download some version, it will stay the same, done.

[gmaxwell]

I think that's a whopper of an assumption. It can take years/decades to find weaknesses in crypto systems....meaning someone might find a vulnerability tomorrow or someone might find a vulnerability in several years. Given the narrow adoption of bitcoin, I'd say there hasn't been enough significant research to dismiss bitcoin's protocol as fundamentally sound. In fact, there never will be. We're always questioning and finding vulnerabilities in (existing) crypto systems.
Furthermore, the ability to change the protocol in the face of a vulnerability is a strength of bitcoin not a weakness.

We have fixed serious currency-ending flaws in the protocol design in the last year (and in every year before, for that matter), e.g. in this one from March a tricky interaction between the surprising possibility of creating _valid_ duplicated transactions and the way the protocol undoes blocks during reorganization made it possible for someone to mine a pair of blocks which when shown to a node cause it to forever separate from the main network.  Another example is this one from May, where bitcoin's transaction hash tree is calculated in a flawed manner where a different set of transactions can be created for a block that have the same hash (a second-preimage attack on the function). An attacker could use this to create a bizarro version of a valid block that was invalid— carrying duplicated transactions— but had the same hash/ID, and after giving it to a node that node would never reorganize onto the chain containing it or its valid clone, leaving that node on a fork or preventing particular miners from successfully mining. (This attack doesn't even require the attacker to mine, he only has to relay maliciously). It turned out that the attack blocks had to a special form which can be rejected very early on before saving the block then the node can blacklist the peer and not allow that to prevent it from fetching the same block ID from another peer and, eventually, get a non-corrupted copy.  These were both day-one protocol design flaws that could be used for either massive scale denial of service attacks, or targeting single nodes to rob them (by mining some blocks slowly on the fork they're on).

Protocol level flaws are not unique to any particular implementation but implementation specific bugs are dangerous for all Bitcoin users, not just for people who are on the broken implementation: Because Bitcoin is a distributed consensus algorithm consistency is more important than correctness— a serious implementation specific flaw in _any_ widely deployed implementation, especially one widely deployed in merchants and miners— may result in a complete failure of the system (e.g. allowing half of all transactions for a day or two to be reversed and respent to new destinations, bankrupting a significant chunk of users and rightfully scaring everyone sane away from the system), because regardless of which implementation is right if nodes don't agree they will split into two currencies where all the coins can be spent in each. Once healed one side must lose, so it's more important to be consistent than correct. The attacks I listed above are so dangerous in  particular because an attacker could use them to create inconsistency in the network.

By taking extra care and doing extra design work we've kept the protocol fully compatible while fixing these things— as far back as 0.2.10 (compatibility prior to that was broken by _Satoshi_ on a several year time delay, and absent that protocol version change I believe we're compatible to the first version). Although old nodes could be subjected to targeted attacks absent an attack they continue to work like normal. If you don't want software that changes you can just continue to run old software… and get robbed when someone finally gets around to attacking you. (Although I strongly encourage you to not keep substantial funds in known vulnerable nodes, or even online, if there is anything I've learned from Bitcoin is that there is no amount of potential loss which is great enough to make many people become careful and informed about security— no amount of explanation of risk that will prevent someone from saying "well I haven't been robbed yet!"— witness the popularity of untrustworthy centralized services, scams, etc.)

Of course, many non-protocol changes are constantly being worked on by the small crew of active developers and by smaller contributions from the broader community— fixing bugs that crash the software, adding infrastructural features that make it possible for people to run fancy services like web wallets, explorers, escrows, and distributed bond markets (e.g. raw transactions), closing day one denial of service vulnerabilities that malicious parties could use to shut down all copies of the software, and improving performance so that Bitcoin doesn't become centralized to a few big websites that could afford to keep running inefficient node software (or write their own private non-released high performance software)— itself an essential aspect of security. If Bitcoin was just a couple major exchanges and webwallets— well, we'd be better off with paypal.  

There remain serious performance and DOS issues which are not yet resolved, many kinds of Bitcoin service that can't be provided without modifying the software,  etc— lots of work remains before we even start talking about all the squishy-feely user-centric improvements which are also urgently needed.   These sorts of challenging and unsexy infrastructural tasks are the things the core developers are working on and I find it depressing that this work is not only not highly appreciated by some in the community but the that community tolerates persistent misplaced attacks which violate even the broadest definitions of acceptable conduct.

[Atlas]

I think that's a whopper of an assumption. It can take years/decades to find weaknesses in crypto systems....meaning someone might find a vulnerability tomorrow or someone might find a vulnerability in several years. Given the narrow adoption of bitcoin, I'd say there hasn't been enough significant research to dismiss bitcoin's protocol as fundamentally sound. In fact, there never will be. We're always questioning and finding vulnerabilities in (existing) crypto systems.
Furthermore, the ability to change the protocol in the face of a vulnerability is a strength of bitcoin not a weakness.

We have fixed serious currency-ending flaws in the protocol design in the last year (and in every year before, for that matter), e.g. in this one from March a tricky interaction between the surprising possibility of creating _valid_ duplicated transactions and the way the protocol undoes blocks during reorganization made it possible for someone to mine a pair of blocks which when shown to a node cause it to forever separate from the main network.  Another example is this one from May, where bitcoin's transaction hash tree is calculated in a flawed manner where a different set of transactions can be created for a block that have the same hash (a second-preimage attack on the function). An attacker could use this to create a bizarro version of a valid block that was invalid— carrying duplicated transactions— but had the same hash/ID, and after giving it to a node that node would never reorganize onto the chain containing it or its valid clone, leaving that node on a fork or preventing particular miners from successfully mining. (This attack doesn't even require the attacker to mine, he only has to relay maliciously). It turned out that the attack blocks had to a special form which can be rejected very early on before saving the block then the node can blacklist the peer and not allow that to prevent it from fetching the same block ID from another peer and, eventually, get a non-corrupted copy.  These were both day-one protocol design flaws that could be used for either massive scale denial of service attacks, or targeting single nodes to rob them (by mining some blocks slowly on the fork they're on).

Protocol level flaws are not unique to any particular implementation but implementation specific bugs are dangerous for all Bitcoin users, not just for people who are on the broken implementation: Because Bitcoin is a distributed consensus algorithm consistency is more important than correctness— a serious implementation specific flaw in _any_ widely deployed implementation, especially one widely deployed in merchants and miners— may result in a complete failure of the system (e.g. allowing half of all transactions for a day or two to be reversed and respent to new destinations, bankrupting a significant chunk of users and rightfully scaring everyone sane away from the system), because regardless of which implementation is right if nodes don't agree they will split into two currencies where all the coins can be spent in each. Once healed one side must lose, so it's more important to be consistent than correct. The attacks I listed above are so dangerous in  particular because an attacker could use them to create inconsistency in the network.

By taking extra care and doing extra design work we've kept the protocol fully compatible while fixing these things— as far back as 0.2.10 (compatibility prior to that was broken by _Satoshi_ on a several year time delay, and absent that protocol version change I believe we're compatible to the first version). Although old nodes could be subjected to targeted attacks absent an attack they continue to work like normal. If you don't want software that changes you can just continue to run old software… and get robbed when someone finally gets around to attacking you. (Although I strongly encourage you to not keep substantial funds in known vulnerable nodes, or even online, if there is anything I've learned from Bitcoin is that there is no amount of potential loss which is great enough to make many people become careful and informed about security— no amount of explanation of risk that will prevent someone from saying "well I haven't been robbed yet!"— witness the popularity of untrustworthy centralized services, scams, etc.)

Of course, many non-protocol changes are constantly being worked on by the small crew of active developers and by smaller contributions from the broader community— fixing bugs that crash the software, adding infrastructural features that make it possible for people to run fancy services like web wallets, explorers, escrows, and distributed bond markets (e.g. raw transactions), closing day one denial of service vulnerabilities that malicious parties could use to shut down all copies of the software, and improving performance so that Bitcoin doesn't become centralized to a few big websites that could afford to keep running inefficient node software (or write their own private non-released high performance software)— itself an essential aspect of security. If Bitcoin was just a couple major exchanges and webwallets— well, we'd be better off with paypal.  

There remain serious performance and DOS issues which are not yet resolved, many kinds of Bitcoin service that can't be provided without modifying the software,  etc— lots of work remains before we even start talking about all the squishy-feely user-centric improvements which are also urgently needed.   These sorts of challenging and unsexy infrastructural tasks are the things the core developers are working on and I find it depressing that this work is not only not highly appreciated by some in the community but the that community tolerates persistent misplaced attacks which violate even the broadest definitions of acceptable conduct.

I will not questions things any further. I submit. I am gone.

[Luke-Jr]

(or maybe just bitcoind) would be quickly out-competed if that rule was adopted.

That is the point. Development would not stop. Bitcoin would not be stopped. Only a certain (and currently central) sect of it will and it would only apply to protocol changes, not client development.

You're contradicting yourself!

I will also add that recently a bug was found in Bitcoin-Qt's latest build (Ultraprune) that changed the Bitcoin protocol, inadvertently.

Ultraprune did not intend to change the protocol. To avoid bugs like this entirely, all core client development would have to stop. That means at the very least, blockchain download could never be made to scale.
I'd suggest helping find and fix these bugs, but you've made it clear you don't even have skills enough to be a competent tester.

P.S. Why five years? So new competing releases have time to develop and challenge any dangerous changes that come our way.

Furthermore, competing clients are inherently vulnerable to the same kind of potential bugs. To achieve a guaranteed protocol freeze immune to any bugs, you would have to forbid new clients!

[MysteryMiner]

Atlas, we are following Satoshi whitepaper rules without changes! There is some work done on technical side of things like version messages, database engine or fucking up user interface to make it noob appealing and harder to use, but the rules are still the same and will remain the same!

Satoshi seemingly had a policy that clients should work (maybe with less security) for at least two years after they were released. I think this is a good goal.

Any new clients being work for at least 2 years since release of newer version would be nice rule to follow! This will not allow damaging changes to be forced by single new version release upon majority of "noob" users. And I would be able to synchronize my computer when I come out of jail if something bad happens.

bitcoind is currently the only stable implementation of a full Bitcoin node AFAIK

I think Ufasoft Coin is a full Bitcoin client and node. And CPU miner also!

[freequant]

In face of this, I propose the Bitcoin.org dev team makes decree that the Bitcoin protocol set in the compatible Bitcoin-Qt/Bitcoind releases of 0.7.1 and below as well as beyond, not be changed for a period of at least 5 years -- in Bitcoin.org's respective releases.

Atlas, instead of ranting against all and every initiative taken by Bitcoin dev team, how about you get in touch with ISO / ANSI / IEEE / W3C, and promote the creation of a workgroup to standardize Bitcoin?