Topic: Risks of big changes to Bitcoin Core (Read 1777 times)

I will not argue with you gmaxwell since you know the code much better than me.
My fear is about implicit consensus in the code that is prone to bugs. If this code is implemented differently on different clients there can be a fork where we would think there should be consensus.

I hope the libconsensus can help with this.

Peter Wuille explains it well, I think. http://youtu.be/asC_kVJ6sig?t=12m45s

What "scary code" are you referring to?
(since you appear to be asking about intentional changes:)

When changes are adopted to the blockchain rules they're made in a way which is intentionally backwards compatible with old versions, called a "soft fork". This is accomplished by constructing the change so that it strictly narrows the set of permissible blocks. Because nothing invalid became valid, old nodes also accept these blocks.  To avoid issues where old nodes would create blocks that get forked off, an effort is made to only narrow the validity of blocks in ways that an old node wouldn't have constructed an invalid block, and the new rules are only activated when a strong super-majority of miners has signaled an intent to enforce them.

Keep in mind that the vast majority of all conceivable changes are actually bad and open up new attacks: Most things people post about (myself included) turn out to be bad ideas on further reflection.  The 'mitigate 51% attacks' link you provided is, I think, one such example: that approach fails to prevent any interesting attacks (attacker can easily meet the criteria by including many of the prior transactions) and also opens up new attacks where none existed before (by intentionally preparing two forks and broadcasting to half the network simultaneously the network can be cheaply split and work against itself; this is a general flaw pattern in approaches that make block preference depend on multiple strong tie-breakers).

I have thought about this and I see big risks.

There are some scary code in the reference implementation and it has already happened that a new version has hard forked the blockchain because of a bug.

Let's say ~50% of the mining capacity uses the reference implementation and ~50% uses another implementation. What if a bug again causes a hard fork. How can you in a reasonable time get a consensus on which one of the miners needs to change version/implementation? And if you can not get consensus and let's say a day passes, how can you ever convince any miners to abandon their fork and be the ones to pass up on their earned rewards?

I see a scenario as this as quite possible, given that it has happened before. With more pools spread out over the world and less consensus on what is the correct implementation a scenario like this could break bitcoin.

What can go wrong when users/miners on the network use outdated versions of the protocol?

As Bitcoin grows in popularity, more developers want to find ways to contribute to the source. Wallets, online markets, etc. have lots of room for improvement and the risks of making changes there seem manageable.

But what about non-trivial changes to the Bitcoin core protocol? There’s always lots of discussion about ways to mitigate risks of 51% attacks and other vulnerabilities. Like adding conditions to accepting longer blockchains, just as an example.

Suppose a big change was actually made, there’s nothing forcing miners to take the update. What are some of the risks of having miners on the network using different versions of the protocol? Not necessarily malicious clients, just outdated ones?

If a big change were introduced, what would things look like as adoption ramped up to >50% of users?