Topic: Chinese Miners Revolt, Announces Plan to Hard Fork to Classic - page 2. (Read 6911 times)

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.)

I'm trying hard to follow the thread here vs 8btc and I see this one here:

http://8btc.com/thread-35934-1-1.html

which translates to:

According to https://btc.com/block?date=2016-07-05 
blocks mined in the last 24 hours were in BIP-9 (old version without SW)
whereas typically half of the blocks mined were BIP 68 112 113 (new versions including SW)

coincident?

If you could give more information on this statement and provide some evidence as to how the hard fork is about to begin, that'd be great. The most information I've found about this is a single post on reddit.com/r/btc which says that the Chinese miners are talking, not necessarily following through with anything. There is no information out there saying anyone is close to implementing it at any point.

gmaxwell fails.
1. "hardforkers demand 8gb blocks now".
.. um no 2MEGABYTES.. stop exaggerating

2. "classic hasnts implemented locktimes"
.. so what.. locktimes are only important for LN.. maybe some people see that LN is not an ultimate solution and not everyone wants to lock funds in multisigs and not everyone wants to only be 50% owners of their funds with someone they may only transact with once a month or year. after all LN is only useful to spammers, who themselves wont use LN because they want to spam the blockchain not offchain. so why would they go offchain.
anyway other implementations just want traditional transactions ONCHAIN with bigger blocks. it does not require thousands of lines of code to implement nor does it require constant changing.. thats why it doesnt require much playing around with.

the real funny thing is that BU, XT, classic and other implementations that have hard fork code are actually publicly released and actually validating real bitcoin data, archiving real bitcoin blocks right now.... where as segwit is still playing with altcoin(segnet/testnet) data, where that data is systematically chosen rather than being real use random data of 7 years..

but i still await for gmaxwells answer.. will he support LukeJRs MAX_BLOCK_BASE_SIZE = 2000000; or will he try to push luke JR off the bus like he has done with hearn and gavin...

8GB, here we go again. What about providing some scientific verifiable tests what minimum computer specifications you need to run full node on full 1 MB blocks versus full 2 MB blocks. If your right then you dont need to worry about the results and convince more bigger block supporters its not time for slightly bigger blocks because current average home computers could not even handle 2 MB blocks.

Or 1 MB is some kind of perfect magic number, or just fear of a hard fork ? I doubt you worry too much about the need others have to update full node clients for non problematic hard fork to occur, because to continue using Bitcoin we had to update wallets as well with better fees estimation algos (and much quickier than any grace period planned for hard forks).

He’s also cunning enough to wait several months before vociferously denouncing it, calling the participants, including the president of his company, well-meaning dipshits.

Does nothing hm? The only risk is the risk of Core throwing their toys out of the pram and starting a 1MB4EVA keccak altcoin. Please explain the danger of header first mining, for the network, not for the miners that could potentially mine a block that nodes consider invalid. Concerns about SPV security can be assuaged, as Gregory once described.

Some of us recall, at the time of the second Stalling Bitcoin conference, your email to the mailing list literally became the Core roadmap. Some of us see the leadership dynamics at work in the core-dev irc chan. Bring down regulatory hellfire on you? Please. We just want to see you, your company, and your fellow Core devs make a good faith effort at a reasonable compromise… like the HK agreement.

The main concern about regulatory hellfire won’t be because it is directed at you, personally, that’s silly. It will probably relate to lightning hubs being designated MSBs depending on jurisdiction.


It would be a huge mistake to underestimate your competence in this field. Your influence on the Core project isn’t magical, most of it is well deserved. To deny that your influence is elevated above most, if not all participants though, is wishful thinking.

Your ideas are composed into an email to the mailing list… that email becomes the official Core roadmap… the initiatives outlined in your email are implemented…

The careful observer can see that you haven’t chosen to support things that just coincidentally happen to be what is meritoriously implemented… they are implemented because you chose to support them, while ignoring input from outside sources (notably from miners and [non-Blockstream] Bitcoin businesses).

If you wonder about the acrimony… consider that people, especially Bitcoiners, don’t like the idea of the table being tilted by those in positions of power. The “online community management” employed by Theymos on r/bitcoin, for example. The censorship and steering feels and looks like an attack, so... surprise surprise, perceived (and criminally real in the form of DDoS against classic nodes) aggression is met with retaliatory aggression.


Slippery slope, defined.

To be clear, when I said supporting, I meant providing development support, not actively peddling.  For instance, in the already discussed incredibly hypothetical scenario, 75% of new blocks would already be on a chain where some blocks are >1MB and a group of core developers refuses to adapt core to accept that chain as valid.  So, at that point the options for a developer who does want to continue supporting that chain and doesn't see a problem with 2MB blocks (since that is what this thread is predicated on, regardless of what any wallet may support) are to try to improve the most popular client on the larger chain (I would predict this to be your decision based on the post I quoted in my previous post), stick with core (presumably this requires the belief that the longer 75% chain can and will fail without turning off most users), or walk away completely (this seems like an unlikely choice, but it is still certainly an option).  That having been said, I failed to acknowledge the possibility of developing for multiple clients at once (sticking with core, but contributing to other projects as well).  Moreover, I can understand why you might not want to answer the question in its hypothetical state with so many people potentially ready to misquote such an answer (or otherwise use it against you), so I will pretend you are undecided for now unless you actually feel so strongly about this that you want to post that you would stick with contributing to core and core alone in said scenario.

Many of the people pushing for hardfork size increases are pushing a vision of Bitcoin that will almost certainly become highly centralized-- See for example the comments on Reddit today with people arguing that it's possible to handle 8GB blocks using computing systems at quasi-youtube scale-- some don't consider this a problem; from my perspective such a system would be completely uninteresting (and a detriment to mankind, if it survived at all).

No one _has_ to support anything here they don't want to; and I'm surely not going to support something that puts us on that route and I doubt practically any of the active development community would.  Presumably anyone okay with that path would already be supporting Bitcoin "Classic", but clearly none are.

I don't agree with everything you post, but refuting FUD that "supports" "core" certainly helps convince me that you do believe what you are posting (vs just being a shill).

I think a far more important question for gmaxwell is this:

So if this rumored hard fork actually occurred, where would you put your effort if the majority of core developers wanted to call it an altcoin and block support for it from being added to core?

This question is important because my belief has always been that if something else wins out, core will adjust and may again become the best client, however, what the best developers do is far more important than what core does.  So as a developer with "nearly a lifetime of relevant experience" that helps to "identify initiatives which are likely to be successful" I'm interested in whether he would jump ship if he had to (supporting classic or unlimited, for instance) and also in whether or not he would believe he had to (vs expecting the ~75%/+ longer fork to die off without confidence in the ~25%/- fork concurrently being so shaken that there is no longer a "successful initiative" on either "side").

I agree. Bitcoin should not have any 'very important people' such as the case with ETH.

What are you basing these lies on? There is really no information about the current status of that ridiculous plan (r/btc would probably have a min. of 10 posts about it by now). Keep in mind that deliberately posting false information falls under trolling and is not allowed by the forum.

hard fork is about to begin

Am I the only one thinking this?

https://s-media-cache-ak0.pinimg.com/236x/5f/c6/01/5fc601ab048559b8709052f4c929cbe5.jpg

so when Luke JR makes a revision where he changes segwits
MAX_BLOCK_BASE_SIZE = 1000000;
to
MAX_BLOCK_BASE_SIZE = 2000000;
will you support it. or will to decline it

Just so.

But beyond that, this weird fantasy that I am some uniquely important person in Bitcoin is just completely without basis.  It's a narative spun by Mike Hearn in an effort to bring down regulatory hellfire on me to drive me out-- since for years I (and most other people actually doing the work of supporting the system) was very careful to keep a low profile, it didn't work.

Having my support on something doesn't magically make it a success. The fact that efforts I support are often a success is much more because I have nearly a lifetime of relevant experience that lets me identify initiatives which are likely to be successful and I prefer to spend my time working on those... than it is because I or anyone else has some kind of magical influence. ... regardless of what stories some people find advantageous to tell.

I disagree. He's smart enough not to participate in closed-door meetings which are counter-intuitive to Bitcoin.

It does nothing and comes with a risk. Wake me up again when the Classic developers coded up something useful, just don't come to me with trash like header-first-mining.

How many times does it need to be told to you? Are you not listening or are you not able to comprehend what you're reading? 2 MB block size limit is unsafe on its own (without artificial limits) due to quadratic validation time and now you come with this nonsense story of how 10 MB is safe currently? I don't even want to talk about the ever decreasing node count because of resource usage.

But I gave that to you.

Well, I'll leave your opener alone... but, the difference would be 100%/1100%/2100% greater potential throughput vs the ~3.7 something global tps we have now.

Just because your personal automobile can't hold 100 passengers, doesn't mean you shouldn't never try fitting a couple more in there with you. 


I agree that the miners made a mistake. Basically, if Gregory Maxwell wasn't at the agreement, you don't have an agreement. 


If doubling the throughput of the network does almost nothing for scalability... then segwit does less than almost nothing for scalability with its 3MB per block max increase to data requirements and its 0.8MB gain in effective throughput.


Check your premises, the chinese miners are really the only ones left to put a check on the real cartel, the information/software cartel that is using artificial production quotas to centrally plan the economy. 

Right now a maximum block size is nowhere near enough to accommodate all of the transactions trying to get confirmed (legitimate transactions or otherwise), you can look at the size of recent blocks to see that recently found blocks are all 950kb+, and you can look at the mempool of any reputable block explorer to see that there are several MB worth of unconfirmed transactions and several BTC worth of transaction fees within these unconfirmed transactions.

If for example, we were to increase the maximum block size to say 10MB, (which I believe to be safe currently), then blocks on average would probably be about 10-11% full or so. If transaction growth were to grow at say 30% per year (which would be huge, and probably higher then what is realistic), then after about 8 years then the maximum block size would need to be increased again when the demand for transactions would create the need for blocks to be about 90% full.

In ~8 years, we could raise the maximum block size to say 50MB to accommodate for future growth of transaction volume. Now with today's network technology, with today's cost of storage, and with today's cost of processing power, 50MB is probably be too large, however over the next 8 years, we will almost certainly see increases in all of the above, and the cost of all of the above is almost certain to decline. Since transaction volume has already grown to be very large, after 8 years, you might want to assume that transaction growth slows to 20% per year (still very large). After ~9 years of growth, the maximum block size will again need to be increased, and again the technology regarding networks, storage and processing will almost certainly have improved and the cost of the above will almost certainly have declined, allowing for an increase of the maximum block size without increasing the cost of running a full node from the time the maximum block size was last increased.

Stolfi's right about one thing: this Chinese mining cartel is a problem.