Many Pools Rejecting XT in Favor of Other Undefined Fork

A handful of large mining pools including those operated by BTCChina and Bitfury have rejected Mike Hearn and Gavin Andressen's XTCoin proposal in favor of a different forking change which would leave them still more influence on their forked blockchain. The pools currently authoring blocks which support the proposal known as BIP 100 currently compromise a bit more than 50% of the hashrate, an amount which if BIP 100 actually had any working implementations would be insufficient to trigger a switch without an attack orphaning all blocks without a "triggering" vote.

At the moment BIP 100 exists as a proposal requesting comments, so it is not possible at the time of this writing to describe any of its points with certainty beyond votes for it being a clear repudiation of the XT effort. As BIP 100 exists now it preserves the 32 MB maximum message size as a hard explicit limit which the blocksize limit must stay under on a BIP 100 forked chain. With so many particulars of BIP 100 not being set in stone yet, it is not unlikely that support for it may wane though at the moment support is likely to persist as a repudiation of the XT effort to hijack Bitcoin.

14 thoughts on “Many Pools Rejecting XT in Favor of Other Undefined Fork

  1. This is actually incredibly reasonable.

    BIP100 doesn't really change the blocksize limit. In fact it isn't even really a hardfork. It's a mechanism for being able to do a FAST emergency hardfork so long as the hardfork changes nothing other than increasing the blocksize, and increases it to no more than 32MB.

    As always, the miners determine if the hardfork happens or not. BIP100 just makes it possible for them to do this on very very short notice.

    This cleverly nullifies all of the fearmongering around the blocksize debate. If the unlikely-but-remotely-possible catastrophe occurs where the transaction load goes up 100x overnight, the people (i.e. miners) making lots of money off of keeping bitcoin working smoothly will have an algorithmic way to agree on an increase, and should agreement occur the increase will then take effect automatically.

    Very very slick.

    It really isn't a hardfork at all. It's a way to accelerate emergency hardforks, should they become necessary.

    gbanGENIUS!

      • Absolutely not. If it leads to the most-difficult chain containing a block for which

        Block::IsValid()

        returns false, then it is a hardfork.

        BIP100 will not necessarily lead to this outcome. It avoids it if the pessimists are in fact wrong.

        gwrongo

      • Also, by your reasoning, rewriting the bitcoin client in another language would be considered a hardfork. That can't possibly be correct.

          • Wait, so now it's not about changing a line, it's about some not-yet-defined "functional equivalence"?

            Gee, looks like things aren't as simple as you wish they were.

  2. > As always, the miners determine if the hardfork happens or not.

    No, they do not. The miners decide jack shit. And that's miners not pools, which compare to actual miners like coats of paint compare to actual cars. Just the easy "miners oh you mean pools" bit of mental confusion is generally speaking enough to disqualify someone from discussing Bitcoin.

    • Mircea, welcome to 2015. More than 50% of the network hashpower comes from entities running hardware they designed and manufactured themselves. You seem to have slept through the whole 28nm thing.

      gnanometers

      • Of course it's miners. Even if they don't run their own pools, they can switch at will.

        This is incidentally why the scaremonging around some pools having a big chunk of the generated blocks is bollocks: the second a pool misbehaves, miners will switch.

      • And you know this because hey, something you intuited on the basis of spending 100 hours on social media certainly trumps what the actual experts in the field say. Why wouldn't it, what experts, we're all equal blabla right ?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>