Hacker News new | ask | show | jobs
by kanzure 3802 days ago
> rapidly coalescing around an effort to increase the maximum allowed blocksize to 2MB as soon as possible

I have a small nitpick to offer. Any hard-forking change is one for a new network and a new chain, by the very definition of hard-fork. The original Bitcoin blockchain and network will still exist, no matter how many times some of its users employ a hard-fork. A hard-fork cannot "turn off" Bitcoin for everyone else. This is no different than the way that an altcoin, like Litecoin, cannot "turn off" Bitcoin merely by the deployment and launch of Litecoin.

Since their proposal is a backwards-incompatible change (hard-fork), it should be obvious that it does not increase the capacity of the current system, but rather a new system. I find myself wondering how anyone can think it is increasing the capacity of the previous network, given the definition of an (intentional!) hard-fork?

Maybe if we all just wish hard enough, IPv4 will spontaneously transform into IPv6..... Bitcoin will continue to function even in the presence of yet-another hard-fork.

Anyone is welcome to do as they please, including whatever hard-forks they might want to participate in, just as anyone is welcome to use Bitcoin or how they are welcome to abandon Bitcoin if they find that they don't like its offering. However, anyone who wants to participate in a hard-fork should do so in a safe and responsible way, such as by using a new name for the new system, using a new address identifier to avoid cross-chain contamination accidents, etc.

What is Bitcoin Core's role in all of this? https://bitcoin.org/en/bitcoin-core/2016-01-07-statement

Soft-forks and hard-forks? https://petertodd.org/2016/soft-forks-are-safer-than-hard-fo...

bip99 has some more details: https://github.com/bitcoin/bips/blob/master/bip-0099.mediawi...

Bitcoin Core published a capacity increases roadmap: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-...

... and a FAQ about their capacity increases roadmap: https://bitcoincore.org/en/2015/12/23/capacity-increases-faq...

> and [theymos] has strongly censored and perverted all discussion of changes

That's not really true, just search "site:reddit.com/r/bitcoin" for XT or classic or whatever. His lynch mob is waving the banner of censorship but meanwhile actual content shows up on the subreddit. Theymos even acknowledges this, but for some reason refuses to use moderation to eliminate the false allegations of censorship in his subreddit.

1 comments

You act as if the current version is some how pure w/o any hard forks having occurred. The fact is there have been a number of hard forks in Bitcoin's history. The current 1MB block size was itself a hard fork early on and there have been other releases that required a hard fork as well; the world didn't end.
> You act as if the current version is some how pure w/o any hard forks having occurred

Every "version" is pure w.r.t its current rules. Hard-forking is something that impacts a new chain. The old chain still exists even after a hard-fork.

_Anyone_ can run old Bitcoin versions and participate on the old chains using the pre-hard-forked-changed rules.

There is no way to "turn off" the previous chain, at least not in the protocol.

The old version could become unmaintained, have no remaining miners, no remaining validating nodes, etc. That's true. But for this to be the case, there would have to be universal disinterest in maintaining the previous tech, or mining with the previous rules, operating and running fully-validating nodes, etc. Universal disinterest cannot be measured.

I cannot offer you any justification I agree with for the previous hard-forks. At the time that those hard-forks were deployed, various justifications were given, and as of 2016 I am not sure that I can agree with those reasons now. Perhaps at the time I would have found merit in the idea that the Bitcoin ecosystem was small enough to tolerate a hard-fork or something. Another possible rationalization is that, at the time, the Bitcoin software was horribly inefficient in hundreds of ways, this is why verification took >10 hours of a blockchain that was less than 30% the size of the current 2016 blockchain.... and 32MB was probably a security hole that everyone at the time was able to universally agree must be plugged. This sort of reasoning resonates with me even as of 2016; if there was a hole that bad in modern Bitcoin, heck yeah we would all have to do a hard-fork, it's unfortunate but security is important and I like avoiding holes.

FWIW, I don't care about purity.

Here is some text on validation costs:

http://diyhpl.us/wiki/transcripts/scalingbitcoin/validation-...

http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/v...

> other releases that required a hard fork as well the world didn't end

Bitcoin isn't going to destroy the world, nsh is. Anyone saying otherwise is just trolling you.