This weekend the Bitcoin Blockchain experienced a forking incident due a discrepancy between what the expectations of a group developing a Bitcoin network client named "Bitcoin Core" and the actual behavior of Bitcoin miners. The developers of the Bitcoin Core client through a process they refer to as "Bitcoin Improvement Proposals" or BIPs introduced a "soft" forking change into their client which would be triggered through a voting mechanism. In this case miners had appeared to vote in favor of BIP 66, which would have enforced stricter encoding of signatures in an attempt to address the transaction malleability issue which is most notable for having been used as a scapegoat by Mt Gox while actually having little to do with their collapse.
Very soon after the voting mechanism triggered the "soft" fork a block that did not conform to the conditions of the "soft" fork was mined and a majority of the mining hashpower which had appeared to vote for the soft fork instead of orphaning the non-compliant block ended up mining what became the longest blockchain on top of it.
What followed in the social media echo chamber as well as the halls of the developers of this particular Bitcoin client implementation was an incredible amount of gnashing of the teeth and wailing that insisted the majority of the hashpower was somehow wrong though the hard mathematical reality of the situation was different. The voting mechanism had failed and users of the latest versions of Bitcoin Core along with the minority miners were stuck on the weak side of a Blockchain fork. This incident revealed a number of facts about the Bitcoin network are often under appreciated and infrequently discussed.
Of substantial primacy is the fact that there is far greater client heterogeneity on the Bitcoin network than the developers of the Bitcoin Core client would have people believe, and Bitcoin network client variety is the greatest among miners and other infrastructure operators. Running the latest version of "Bitcoin Core" is aberrant behavior among miners who largely use bespoke software, including software that does not fully validate blocks as typical full Bitcoin nodes do. Mining is competitive and pool operators compete for any degree of optimization they can because even 1 megabyte blocks are large enough to introduce substantial delays if they are fully verified before mining on top of them. This results in miners being described as zombies who adopt anything in the short term to cope with their low margins.
Further it is impossible to depend on any sort of voting system to implement forking changes to miner behavior in a smooth manner. There is no way to actually confirm that the real behavior of actual clients on the Bitcoin network conforms to expectations which may follow from the version strings the client broadcasts. The form of "soft consensus" which the developers of Bitcoin Core depend on to implement their "soft" forks is insufficient to prevent future network forks of the sort this voting mechanism apparently was intended to prevent.
This incident highlights the importance of the Bitcoin Foundation's work to maintain a stable reference implementation Bitcoin network client capable of operating as a full node. With the influence of Gavin Andresen and his fellow developers of the Bitcoin Core client waning to new lows as their attempts to force misguided efforts at "Bitcoin Improvement" fail through broken methods, assumptions, and implementations it is time for any last pretense of Bitcoin Core's development having any actual relationship to the actual living core of the Bitcoin Network to be discarded.
"02:44 gmaxwell thats lovely, they're climing v3 but not enforcing it."
http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/07/04#l1435977894.0
That voting mechanism is the same that is supposed to be the trigger for the blocksize hardfork.
> there is far greater client heterogeneity on the Bitcoin network than the developers of the Bitcoin Core client would have people believe
I'm not sure if that's true, but if it is, it's a good thing.
!gBangA!
> Running the latest version of "Bitcoin Core" aberrant behavior among miners who largely use bespoke software including software that does not fully validate blocks as typical full Bitcoin nodes do.
This sentence is grammatically ill-formed. Where is the primary clause?
journalistfail englishbad.
baGanga!
> baGanga!
I lolled.
> There is no way to actually confirm that the real behavior of actual clients on the Bitcoin network conforms to expectations which may follow from the version strings the client broadcasts.
Incorrect. The "voting" dependended in no way on the version string broadcasted by clients. The criterion was the distribution of block versions of the last 1000 blocks. A miner setting their block version to 3 signifies agreement. > 95% of the hash power was signifying that they had switched over to the new rules.
You can read the full text of BIP66 here: https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki
Obviously something went wrong, but blaming the process, or Bitcoin Core's implementation is disingenious. Neither was this caused by wide use of old software, because old software would simply keep producing v2 blocks, so the change would never have triggered.
> In this case miners had appeared to vote in favor of BIP 66, which would have enforced stricter encoding of signatures in an attempt to address the transaction malleability issue which is mo
Again, incorrect. The motivation for BIP66 was not malleability. The motivation is right there in the document:
"Bitcoin's reference implementation currently relies on OpenSSL for signature validation, which means it is implicitly defining Bitcoin's block validity rules. Unfortunately, OpenSSL is not designed for consensus-critical behaviour (it does not guarantee bug-for-bug compatibility between versions), and thus changes to it can – and have – affected Bitcoin software."
The goal is to get rid of OpenSSL's variability in the consensus code by defining a stricter spec on the protocol. There was risk of much worse and persistent forks due to differences between OpenSSL versions (all in the hands of developers of a third-party library). A relatively mild example was: http://sourceforge.net/p/bitcoin/mailman/message/33221963/
> Obviously something went wrong, but blaming the process, or Bitcoin Core's implementation is disingenious
It is not "disingenious" in the slightest. They came up with a process, the process blew up. It reflects poorly on their ability to use the noggins generally, and to organise this type of process particularly.
If they didn't think the process was going to work, they should not have either proposed it, or [tried to] use it. If they did think it will work (which they did, like you did, like all of redditardlandia did), it is because you can not think. And the same you can not think broken nonsense is at work when you come up with all the rest of the nonsense you come up with.
Just try and remember that "nobody could have foreseen they'd use the plane as a rocket" is not a valid defense. Especially not if you're some dumbass woman whose job was to foresee exactly that, and even more especially not when people who knew better than you told you as much.
Shut up and walk with the head down, you blew it, big time, and it's on your heads. Derping about "disingenuous" is not merely disingenuous, it is asking for a beating. A proper one, I mean.