Comment by pash | Hacker News Reader

Comment by pash | Hacker News Reader

The Bitcoin community is rapidly coalescing around an effort to increase the maximum allowed blocksize to 2MB as soon as possible. This increase is being implemented in a new client, Bitcoin Classic [0], which is a fork of Bitcoin Core that changes only the single line of code that sets the blocksize limit.

Bitcoin Classic was created by Jonathan Toomim, an American miner and developer who went to China to talk directly with Chinese miners and to test the effect of bigger blocks on mining operations behind the Great Firewall. Gavin Andresen, Bitcoin Core's former lead developer, and Jeff Garzik, another prominent Core developer, as well as many others, are collaborating with Toomim on further changes that Bitcoin Classic may implement later.

The big difference between Bitcoin Classic and Mike Hearn's failed Bitcoin XT is the concerted effort by the people behind Classic to garner the explicit support of miners (and other important members of the Bitcoin ecosystem) for a blocksize increase. At my last check yesterday, mining-pool operators representing 72% of global hashing power had explicitly expressed their support for Bitcoin Classic's blocksize increase, as had the operators of many popular exchanges, web wallets, and payment providers. (There is a growing compendium of prominent supporters on Bitcoin Classic's website; the complete list is on the project's Github page [1].)

That means that Bitcoin Classic is very likely to break Core's monopoly on the protocol soon. The blocksize increase, and the fork of the blockchain that it will create, is tentatively scheduled to take place after March 1. Get ready.

(By the way, the best sources for information and discussion about the Bitcoin world are now the /r/btc sub-Reddit and the discussion forums at bitcoin.com and bitco.in; the community's former hubs, /r/Bitcoin and bitcointalk.org, are both controlled by the same operator/moderator, and he has strongly censored and perverted all discussion of changes to the protocol that are not supported by Core's intransigent cabal of developers.)

0. https://www.bitcoinclassic.com

1. https://github.com/bitcoinclassic/website/issues/3

The way XT seems to have failed yet Classic seems to be suceeding seems odd to me.

Is all it took really just to have a developer fly out to China and talk to a hanful of people? Seems like there's a lot more politics going on behind the scenes.

In any case, fixing the blocksize limit will be good, but I think the real value in Classic is breaking the perceived monopoly Core has and moving to a healthier political setup. Many people were absolutely unwilling to even talk about XT (or as you mention, allow others to talk about XT) because "OMG it's not Core!". That argument will be a lot less viable if everyone's moved to Classic.

>The way XT seems to have failed yet Classic seems to be suceeding seems odd to me.

XT was much more aggressive. Not only would it have initially increased the blocksize to 8MB, but then it fixed a schedule of doubling the blocksize every 2 years[0].

[0]: https://en.wikipedia.org/wiki/Bitcoin_XT#Determining_the_new...

> In any case, fixing the blocksize limit will be good

This presumes the blocksize limit is being fixed, which is an incorrect assumption. Originally, the proponents of Classic wanted to boost block size limits to 20MB effective January 2016 [1], and used bombastic and divisive language, inventing their own crisis even, to get people to take them seriously.

Interestingly, those same people are now contending for just 2MB, which is only 0.4MB higher than that proposed by Core.

Performance test data shows 32MB is the absolute maximum block size you can handle on a modern desktop PC today [2]. And by this I mean you could validate no more than one block per 10 minutes, hence realistically you actually couldn't run a full node on a desktop at 32MB. You'd need a clustered full node just to keep up, which is unprecedented in Bitcoin.

To make matters worse, 32MB blocks gets Bitcoin to 300 tps which is less than 1% of VISA's current capacity.

[1]: http://gavinandresen.ninja/does-more-transactions-necessaril...

[2]: https://blog.conformal.com/btcsim-simulating-the-rise-of-bit...

Well, any improvement to blocksize will be good, and will hopefully break the logjam preventing changes.

If we wait for a perfect fix to all problems, current and projected, we'll be waiting forever.

> Interestingly, those same people are now contending for just 2MB...

Hearn mentions the backstory behind this in a comment here [0], posted a little while after you posted your comment. After reading his comment, does the shift from 20MB max blocks to something smaller become less "interesting" and more understandable? If not, why not?

Edit: Additionally, do you have anything to say about this comment? [1]

[0] https://news.ycombinator.com/item?id=10921219

[1] https://news.ycombinator.com/item?id=10921209

This... does not sound good at all. Frankly, I wasn't expecting that scaling the block size would be so taxing on normal nodes.

>Performance test data shows 32MB is the absolute maximum block size you can handle on a modern desktop PC today [2].

No, it's maximum size you can handle using a single-threaded poorly-optimized cpu software.

>Additionally, a profile of the CPU usage of this node, using golang’s great profile capabilities, shows that the CPU usage is dominated by the ECDSA signature verifications

OpenCL on gpu can easily process 50 MILLION bitcoin addresses per second (ecdsa + sha). [0] Note that OpenCL is available even on smartphones. For a very rough estimate, Adreno 530 on Snapdragon 820 has 500GFlops, 10% of 780 ti which can do 50M/s, so it should do about 5M/s. So a $400 smartphone should be more than enough to process 32MB blocks - provided the gpu is used.

[0] https://en.bitcoin.it/wiki/Vanitygen

No. It took a sharp fall in the BTC price.

This narrative that Gavin and I were unwilling to compromise is deeply unfortunate. BIP 101 originally started with a 20mb limit+growth. That was based on some calculations Gavin did. At that point the Chinese miners started saying they couldn't accept 20 because of the firewall, but eight would be OK. They put announcements of their support for eight megabyte blocks in their coinbases, etc.

Why eight? Because it's a Chinese homonym for "prosper" or "wealth":

https://en.wikipedia.org/wiki/Numbers_in_Chinese_culture#Eig...

It crops up in the Chinese Bitcoin community all the time. So this choice obviously wasn't based on any kind of scientific analysis. Having Bitcoin protocol constants be decided by rhymes would obviously have been an embarrassment, but nonetheless, we compromised and did it.

After Core rejected the now-modified BIP 101, Gavin and I released XT together. At this point the miners changed their tune. They announced they would never run anything except Core, period, end of story. This "requirement" had not been specified before. From both speaking to them personally (I have had various phone calls with miners around the world, including miners in China) and their public statments, they made it clear that their loyalty to Core was absolute and no matter what changes we made to XT, they would never run it. Thus compromising further was pointless.

Why is Classic different? It wasn't, just one or two days ago. After I released my article, I was CCd on a private thread where KnC Miner published an "open letter" and suggested switching to Classic. The other miners shot him down immediately saying they wanted the change to come from Core. Then the price started sliding, and they started reversing their positions. Suddenly, Classic was acceptable whereas just hours before it had not been.

I find your writings very clear and refreshing to read. Regardless of what happens with BTC, thanks for your efforts!

Ah, now that makes sense. ...well, as much as anything in the Bitcoin world makes sense, which isn't much. :)

>No. It took a sharp fall in the BTC price

And the trigger for that was your medium article the other day. :-)

And since, block size/scalability was the key point in your post. Would you be willing to re-join Bitcoin, since what you wanted would be achieved? Even if its Classic and not via XT.

Perhaps, my question may come across as naive. But looking at it from outside (reading /Bitcoin & /btc & etc), it would definitely clear a lot of air, and be good for Bitcoin.

How is this your concern any more? You promised to leave bitcoin scene because it has failed, why don't you focus on R3Coin instead.

XT angered people because it was seen as an attempted coup. That was back when the Core devs were viewed as untouchable gods by most of the Bitcoin community. People are now willing to accept Classic because the core devs have been acting like babies. They've destroyed their reputation with the community by refusing any compromise, attacking Classic with Trojan pull requests and making a lot of outlandish statements in public forums. This hasn't sat well with the people who are heavily invested in Bitcoin. If XT were introduced now it might have gained more traction.

At this point the community seems to be mostly decided that they want to break the Core dev's monopoly and Classic provides a lowest common denominator way to do this. I just hope the Classic devs make better choices.

So you believe that whoever was upset with the blocksize/management changes that would have been introduced in XT has been placated by this more inclusive effort? And that this actor will not attempt to sabotage the rollout of Classic as they did with XT?

They absolutely will. At this point though the first alternative implementations helped people calibrate to the dishonesty of the group of people who has worked so hard to censor and alienate everyone who might compromise the need for their company, blockstream.

Most people really gave them way too much credit and took them at their word, but it's been dug into the ground at this point that they are going to try to lie, censor, and outright sabotage any attempt to adapt bitcoin since they think creating problems gives them an opportunity to solve them.

It seems misleading to call something "bitcoin classic" that would implement a hard fork.

The bitcoin implementation by the "real" bitcoin foundation (ie, asciilifeform's group) at least can claim that it is an implementation of the actual bitcoin protocol:

http://thebitcoin.foundation/

The original Bitcoin didn't include any block limit and Bitcoin's inventor wasn't worried about block size being too large[0]. The current 1MB limit was itself a hard fork of the original as a temporary spam protection measure while the network was in it's infancy. So the name really isn't misleading. A lot of people are ignorant of the history of the block size limit though.

[0] http://www.mail-archive.com/cryptography@metzdowd.com/msg099...

It was a soft fork.

> That means that Bitcoin Classic is very likely to break Core's monopoly on the protocol soon.

As far as I'm concerned, neither side 'has a monopoly' on the protocol because they haven't documented the protocol with a proper specification.

Forking Bitcoin today to 'solve' contingent future problems seems like the height of folly.

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

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.

The different versions of Bitcoin programs, I am confused, will it be possible to send Bitcoins to each address using the different programs or will each program have different Bitcoin addresses and blockchains so they are incompatible?

If I had Electum which uses the Bitcoin Core could I send Bitcoin to someone using Bitcoin Classic or Bitcoin XT?

If not then this causes a lot of problems and confusion.

Reply on news.ycombinator.com