Quote from: Klestin on March 17, 2016, 10:16:18 PM

Quote from: marky89 on March 17, 2016, 09:24:33 PM

And Classic is presenting that hard fork as "a one-feature patch to bitcoin-core that increases the blocksize limit to 2 MB." Is that really the case?

Hmm... why would the chosen quote begin mid-sentence. You conveniently cut the "It starts with" from that sentence. Could it be that the entire paragraph goes a bit differently?

Quote

We call our code repository Bitcoin Classic. It starts as a one-feature patch to bitcoin-core that increases the blocksize limit to 2 MB. We have ports for 0.11.2 and 0.12.0, so that miners and businesses can upgrade to 2 MB blocks from any recent bitcoin software version they run.

In the future we will continue to release updates that are in line with Satoshis whitepaper & vision, and are agreed upon by the community.

Gee. It sounds to me like they're doing exactly what they said they were going to do.

I left it out because Classic hasn't increased the blocksize limit to 2 MB. If they had, it would have forked already.

So yes, it is dishonest to say "it starts with" when that isn't true. It actually "starts with" other "features" (like hard-coded SPV mining) that have absolutely nothing to do with increasing the block size.

More importantly, there is really no question that Classic has been marketed by everyone involved as increasing the block size -- there has been virtually no discussion of anything else at all. Just as Bitcoin XT was. Do you recall how XT similarly had "features" coded into it that the community did not support?

Quote from: franky1 on March 17, 2016, 10:21:37 PM

lol read more. he wants the code available in april. to be activated at the turn of the block 420,000 (when the reward halves) so that miners do not lose out instantly.

have a nice day

Um, source?

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012492.html

Quote

Depends on the hashrate drop, and tolerance for higher fees, both of which are largely unknown at this time. At least having code prepared for the negative scenarios in case of an emergency seems reasonable, even if we don't end up needing to deploy it.

He also clarified the very same day regarding the link you posted:

Quote

This probably isn't a practical timeframe for deployment, unless/until there's an emergency situation. So if the code were bundled with SegWit, it would need some way to avoid its early activation outside of such an emergency (which could possibly be detected in code, in this case).

So either you need to "read more" or you're just being dishonest here.

On that note, Paul Sztorc has some enlightening thoughts on why having such code ready is very important:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012501.html

An emergency hard fork (as in 2013) is just that. There is no plan to activate this rule at halving, and Luke is not suggesting that. So stop spreading misinformation, please. And that fail of a quip you just made doesn't change the fact that your own thread shows that all of your assumptions about why the proposal is bad, were wrong.

Have a nice day