Bitcoin Forum

HI, guys, I am not a technology expert, I don't know programming,

so I need to ask this question: by asking this question, Is bitcoin protocol evolving, I want to know if there has been any hardfork in bitcoin history?

As far as I can understand, there are many software client for mining and wallet, mining pools etc. however,these softwares don't change any bitcoin protocol, because in order to change protocol, a consensus of more than 50% total network computing power need to be reached, so a hardfork can be proceeded.  Am I right about this?

I have talked about reaching an hardfork consensus with some other folks, and we end up thinking not possible to reach it.

Does that mean bitcoin cannot evolve?

eager for your answers.

Thanks a lot.

Lots of questions there. Lots of answers here.

http://bitcoin.org/en/alert/2013-03-11-chain-fork

As for Bitcoin evolution, this chapter in Bitcoinomics talks about the future:

https://www.goldsilverbitcoin.com/future-of-money-bitcoinomic/

Here is a good thread with some Hearn in it on BTC protocol buffering:

https://bitcointalk.org/index.php?topic=270055.msg2890147#msg2890147

Thanks a lot, I will read them,

but could you please also give me a simple yes or no to answer my question?

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

Not that this list is imminent. Maybe Gavin can give us some idea of when there might be a task force involved in ironing out what should be included in the next hardfork?

Computing power has nothing to do with hardforks.

Hardforks are not a great path to evolution. They're dangerous and potentially coercive. They must be undertaken with the consent of effectively _all_ users. They should be avoided unless there are no other reasonable alternatives.

Although many things have changed and advanced, it's arguable if we've ever had a hardfork or not: Very old nodes can still validate the chain, though they will non-deterministically fail because of semi-hard-forking database management bugs that have been fixed.

Fortunately, we don't have to have hardforks to evolve:  The P2P protocol is a matter between individual peers. They can negotiate whatever options they want. We have replaced the p2p protocol.  Most interesting and important changes to the blockchain validation rules can be accomplished via softforking changes. E.g. P2SH is effectively a radical change in how transaction spending rules are encoded and was accomplished without a hard fork.

In Bitcoin evolution is slow.  There are wallets which cannot be updated because they run on platforms controlled by corporations which are hostile to user-freedom (in particular, there is an i phone wallet app that produces signatures with an invalid encoding). There are multiple implementations of the Bitcoin protocol, but even with the BIP process their implementers have simply declined to implement some functionality, and its lack of universal availability makes it unusable to users. etc. But the system itself is a gigantic moving machine and failure is difficulty— even impossible— to fix, if something goes wrong so it's hard to say that slowness is a bad thing at all. Slowness helps ensures there is understanding and consent and reduces risk.

I heard that anything before 0.3 would not work (even before the latest BIP50 fork). Is that true and what's that about?

No, anything 0.2.9 or higher should work with no more effort than helping it find a peer (ignoring the fact that the BIP50 stuff means that there is a good chance it'll get stuck), prior to 0.2.9 and back to the original release will work so long as you provide a gateway node that will accept the old checksumless version messages.

So where would they stop? Block 252,451 or some random earlier block?

I find that we don't have a centralized page (preferably on the wiki) to describe all forks since 0.1. There is one at https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures but it doesn't provide much details.

As I can identify, we had the following forks in chronological order

Disable OP_LSHIFT etc
Limit the number of sig check commands
Fix output overflow
P2SH
v2 block
BIP50 (hard fork)

Do I miss any? (I consider the "Block hash collision via merkle tree" a bug fix, not a fork, because the malformed blocks are always rejected by all versions)

They may not stop at all.  The behavior fixed in BIP50 is non-deterministic. They'll likely stop if they see a reorg of a couple large blocks, but it depends on the minutia of how the database records aligned to page boundaries.

All of those (save BIP50) are reductions in what the network will accept, so they don't break compatibility.

Yes, they are softforks. Do I miss any?