Topic: Prop: A Bitcoin-Qt/Bitcoind protocol release that's guaranteed to stay the same. (Read 3068 times)

Atlas,

I'm usually not a big fan of yours, but in this thread, you put out your idea in a clear, reasonable way, so much so that I was surprised to find myself agreeing with the questions in your OP.   We ended up getting a great response from gmaxwell that assuaged the concerns you raised.  This thread has been interesting and enlightening. 

Great thread.  Hope to see future posts from you at this high level of quality.

Cheers,
Chris

 


“Uncertainty is the only certainty there is, and knowing how to live with insecurity is the only security.”
  - John Allen Paulos


 


“Uncertainty and mystery are energies of life. Don't let them scare you unduly, for they keep boredom at bay and spark creativity.”
  - R. I. Fitzhenry


 

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?

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!

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.I think Ufasoft Coin is a full Bitcoin client and node. And CPU miner also!

You're contradicting yourself!

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.

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!

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

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.

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

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?

Assuming there is no competition.

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

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?

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.

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

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.

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.

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.

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.

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.