Chinese Miners Revolt, Announces Plan to Hard Fork to Classic

[Cuidler]

Anyone can visit Coin.Dance and see Classic is holding steady at about 11% of total nodes. No worries unless that number starts to increase (by a lot.)

Number of nodes means very little as you cant distinguish between real and fake ones. What only matters is increased number of blocks mined with BIP 109, if miners choose its time for this Bitcoin improvement. But I would preffer if miners come up with their own hard fork change instead so it is not political anymore and not wait for luke-jr proposal as this is pointless and just waste of time as many predicted this stalling tactic right after HK meeting, plus I have feeling its going to be another luke-jr trolling attempt instead like the one for sha3 algo change from him.

[1714832319]

1714832319

[1714832319]

1714832319

[1714832319]

1714832319

[Lauda]

I'm still trying to unpack all this^ Were you both right?

That's not how a HF supported by consensus works. What happens if the miners use hashpower as coercion as the network is that their blocks get invalidated and the coins that are being mined are worthless. The miners do not hold any 'superior' power over the network, else Bitcoin could relatively easily be manipulated (which we know is not the case). Anyone who thinks that people and businesses can upgrade their infrastructure within a very short time period clearly have no idea what they're talking about.

Will this affect the halving in anyway   I imagine it will.

No. Firstly, nothing is happening. Secondly, it won't affect the halving either way unless you're concerned about the price (which is trivial).

Number of nodes means very little as you cant distinguish between real and fake ones.

The metric is very useless and especially in short time periods. We've observed this with exponential rises in both XT and Classic nodes, which disappeared very quickly afterwards.

[jbreher]

What happens if the miners use hashpower as coercion as the network is that their blocks get invalidated and the coins that are being mined are worthless.

Unless, of course, the economic majority accepts the new rules. In which case the stubborn few stragglers find themselves on a fork unsupported by the security of massive hashpower.

[Lauda]

Unless, of course, the economic majority accepts the new rules. In which case the stubborn few stragglers find themselves on a fork unsupported by the security of massive hashpower.

That's not how a HF supported by consensus works.

I'm talking about a scenario in which the miners suddenly decide to 'change the rules' which would be the case with this ridiculous plan that was proposed. There's no way that businesses that are running on less-than-optimally maintained versions and some unusual ones (e.g. Bitcoin ruby) could upgrade very quickly (testing and deploying takes time IMO). Besides, once you give in to such coercion the chances that someone will attempt to do this with even less preferable "changes" become higher. If the HF was 'driven by' consensus, then the economic majority would most likely accept the new rules.

[Quickseller]

Unless, of course, the economic majority accepts the new rules. In which case the stubborn few stragglers find themselves on a fork unsupported by the security of massive hashpower.

That's not how a HF supported by consensus works.

I'm talking about a scenario in which the miners suddenly decide to 'change the rules' which would be the case with this ridiculous plan that was proposed. There's no way that businesses that are running on less-than-optimally maintained versions and some unusual ones (e.g. Bitcoin ruby) could upgrade very quickly (testing and deploying takes time IMO). Besides, once you give in to such coercion the chances that someone will attempt to do this with even less preferable "changes" become higher. If the HF was 'driven by' consensus, then the economic majority would most likely accept the new rules.

The "ridiculous plan" (or some derivative thereof) is supported by ~the entire Bitcoin economy (note that the Chinese exchanges also support larger blocks based on the stances of the Chinese pools that are owned by the same entities).

It is only the blockstream core devs, who work for a company who can only possibly turn a profit if transaction fees skyrocket, as well as the one person who can effectively control the public conversation about the block size, preventing many "normal" people from being well informed (although this really does not matter because most normal people's opinions are not going to matter in terms if the economy accepts a fork or not).

[franky1]

LOL

lauda... HF live working BITCOIN implementations have been publicly available for MONTHS!!!
segwit is not publicly available for any BITCOIN implementations

emphasis: hard fork implementations have been running and validating bitcoin blocks, transactions and relaying data for months.

stop pretending that segwit is better when it has not even touched the 7 years of bitcoin data or even live relayed tx data today. and has only handled altcoin(segnet/testnet) data.
please give your bias and exaggerating mindset a break.

as for thinking miners are going to hard fork before they see a large user uptake, your wrong.. think hard and long about orphans and loss of income before pretending that miners are going to do it.

the more worrying thing is that your "friends" one minute say HF's are bad.. then suddenly invent a different hard for that ruins security totally change many things just out of spite.. (research sha3)

it is funny they try one minute saying they wont 2mb because they dont like hard forks, and then suggest doing a hardfork just to punish anyone that wants 2mb by rendering asics useless.. rendering difficulty weak and rendering the blockchain primed to be 51% attacked or worse.

no go do some research or put your mind to bed

[BillyBobZorton]

Classic developers are trash, so are all the rest of hard forking attempts compared to Core developer team. It's suicide to switch to any other team so when it's all said and done they will not do it.

[helloeverybody]

Why dont core just implement the hard fork themselves instead of messing about with segwit, Sometimes its better just to accept defeat and admit your wrong. There seems to be a lot of support from older members of the community who openly support a blocksize increase. If core where to implement this then surely it would be the best scenario?

[adamvp]

I am not quite sure if block limit increasing to 2mb is good..
Look:
http://www.coindesk.com/1mb-block-size-today-bitcoin/

[BillyBobZorton]

Why dont core just implement the hard fork themselves instead of messing about with segwit, Sometimes its better just to accept defeat and admit your wrong. There seems to be a lot of support from older members of the community who openly support a blocksize increase. If core where to implement this then surely it would be the best scenario?

Because they aren't wrong. The correct thing to do is deploy segwit first then study the scenario after a while. The problem is a bunch of people that don't know anything about all of this work get involved in the discussion. Bitcoin will not become a centralized node mess no matter how much some idiots cry about wanting bigger blocks.

I am not quite sure if block limit increasing to 2mb is good..
Look:
http://www.coindesk.com/1mb-block-size-today-bitcoin/

It's a stupid idea. Only idiots and people with agendas to get rid of Core devs support a block size increase in the near future.

[The00Dustin]

I am not quite sure if block limit increasing to 2mb is good..
Look:
http://www.coindesk.com/1mb-block-size-today-bitcoin/

Definitely a biased article.  Writer starts out with "decentralization is sooo important" but then uses that as his argument for supporting segwit and lightning being better solutions than big blocks.  However, segwit encourages pretend decentralization (if you don't have the witness data, you aren't protecting the network's data) and things like lightning require gatekeepers that are even more centralized still.  I'm not saying centralizing microtransactions off-chain is a problem, but the argument that decentralization is so important that we should centralize stuff is not a very good one.  If the concern was really with centralization, the answer would be pruning, but attackers could easily fight against pruning with spam, and even if that wasn't a possibility, years of misuse of the blockchain as permanent data storage has lead to the opinion that pruning isn't an option.

[Lauda]

The "ridiculous plan" (or some derivative thereof) is supported by ~the entire Bitcoin economy (note that the Chinese exchanges also support larger blocks based on the stances of the Chinese pools that are owned by the same entities).

That statement is ignorant and those companies surely don't represent "~ the entire Bitcoin economy". BIP101 is one of the worst proposals that I've seen so far. Should I mention that the creator of this BIP either was not aware or forgot to address the problem of quadratic validation time (I don't recall added limitations) which just shows how 'competent' they are (in addition to 'how much testing they've done'). Additionally, the grace period on that BIP is horrible. Ask any experienced engineer who has worked on large scale systems about the time required for infrastructural upgrades.

It is only the blockstream core devs, who work for a company who can only possibly turn a profit if transaction fees skyrocket, as well as the one person who can effectively control the public conversation about the block size, preventing many "normal" people from being well informed (although this really does not matter because most normal people's opinions are not going to matter in terms if the economy accepts a fork or not).

Propaganda bullshit as always.

Classic developers are trash, so are all the rest of hard forking attempts compared to Core developer team. It's suicide to switch to any other team so when it's all said and done they will not do it.

Maxwell has made a comment about those 'experienced developers' in a post found here.

However, segwit encourages pretend decentralization (if you don't have the witness data, you aren't protecting the network's data) and things like lightning require gatekeepers that are even more centralized still. 

Lightning does not require (definitely not the right word) gatekeepers, it is just more optimal to use them (i.e. hubs). Think of it as a system that provides 'path-finding' for payment channels.

I'm not saying centralizing microtransactions off-chain is a problem, but the argument that decentralization is so important that we should centralize stuff is not a very good one. 

The Bitcoin blockchain remains decentralized and Lightning can not have an negative affect on that. The possible centralization of Lightning is another topic.

[franky1]

I am not quite sure if block limit increasing to 2mb is good..
Look:
http://www.coindesk.com/1mb-block-size-today-bitcoin/

Definitely a biased article.  

agreed especially when the article tries to say segwit is better but never actually goes to say how segwit works out.
so here is my rebuttal

lol "2mb is bad" for ~5000tx right??
lets look at segwit to compare
but 2.8mb for 350tx good?
but 2.8mb for 350tx good?
but 2.7mb for 655tx good?
but 2.7mb for 798tx good?
but 2.8mb for 350tx good?
um.. no

you have got to laugh at that articles lack of understanding
"which streamlines the way blocks process transactions and increases efficiency without increasing block size."
they have no clue

[AliceGored]

Hey, a Core dev, and altcoin founder, Mark Friedenbach, has confirmed:

The HK Agreement was a Farce: "Haha"

Segwit was merged into Core already. There will be a point release after 0.13 which enables it. You can read about the plan for segwit deployment here:
https://bitcoincore.org/en/2016/06/24/segwit-next-steps/
The HK "consensus" was a farce signed by only a few developers. Nobody that wasn't there has any intention of following through on it.

I know of no hard fork proposal that could achieve consensus on that timeframe, no.
Maybe a magical fix-everything solution will be invented tomorrow (it's possible), but even that would require 6+ months of effort to get it in Core, and another full year or more to deploy, since we're talking about a hard fork. So the timeline doesn't make sense even if one assumed there was an acceptable solution (there isn't).
EDIT: The devs that signed the HK document aren't liers. They promised code availability 3 months after, which is when I would start the timeline I described above.

[beastmodeBiscuitGravy]

[dwdoc]

http://www.coindesk.com/bitcoin-industry-seeking-bridge-scaling-divide-july-meeting/