{"id":25427,"date":"2016-02-18T17:44:18","date_gmt":"2016-02-18T17:44:18","guid":{"rendered":"http:\/\/ci027cfe77a00126c3"},"modified":"2025-01-28T19:23:08","modified_gmt":"2025-01-28T19:23:08","slug":"bitcoin-core-developer-eric-lombrozo-on-misunderstandings-in-block-size-debate-1455817458","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/bitcoin-core-developer-eric-lombrozo-on-misunderstandings-in-block-size-debate-1455817458","title":{"rendered":"Bitcoin Core Developer Eric Lombrozo on Misunderstandings in Block Size Debate"},"content":{"rendered":"
<\/div>
<\/figure>\n

Bitcoin Core<\/a> contributor and Ciphrex<\/a> CEO Eric Lombrozo<\/a> was recently interviewed on Epicenter Bitcoin<\/em><\/a>, and he used a portion of his time to explain some misconceptions and misunderstandings related to the block size limit debate<\/a>. <\/p>\n

While the focus of this development controversy has mainly centered on the actual block size metric in the Bitcoin protocol, Lombrozo says this misses the main point of disagreement. In his view, a hard fork<\/a> is what the Bitcoin Core development community would like to avoid over the short term.<\/p>\n

The Hard Fork Is the Issue<\/strong><\/p>\n

When explaining the full picture of the block size debate, Lombrozo made the point that the non-technical Bitcoin community (likely a reference to Bitcoin subreddits) may not have had the full picture of what was going on in the development community back in May of 2015. Lombrozo described the debate that took place among developers during this period of time:<\/p>\n

\n

\u201cI think that a lot of the non-technical community and the public were not really witnessing exactly the whole development as far as what the developers were doing. Way back in May, we were already talking about considering these ideas when it was first proposed to the mailing list<\/a>, and people were actually really trying to pick this apart and figure out all the things that could possibly go wrong. It quickly became apparent that hard forks have very significant stability issues, they can potentially open up attack vectors, and it could be very dangerous for the network.\u201d <\/p>\n<\/blockquote>\n

Although progress has been made on the simplicity of soft fork<\/a> deployments, hard forks are still hard. At the recent Blockchain Agenda Conference in San Diego, Lombrozo detailed<\/a>BIP 9<\/a>, which allows for several new features to be applied to Bitcoin via simultaneous soft forks.<\/p>\n

Contentious Hard Forks Should Be Avoided<\/strong><\/p>\n

Getting deeper into the problems with hard forks, Lombrozo made it clear that such changes to Bitcoin\u2019s consensus rules<\/a> are not impossible. Instead, he said contentious hard forks are the ones that should be avoided. Lombrozo noted:<\/p>\n

\n

\u201cI am very concerned about hard forks. That\u2019s not to say it\u2019s impossible to do a hard fork more safely, [but] I think the only way that\u2019s viable is if there isn\u2019t this kind of contentiousness \u2013 if you don\u2019t have a lot of polarization and people kind of fighting over different things. If most of the network agrees on something \u2013 if something is pretty much uncontroversial \u2013 that\u2019s fine.\u201d <\/p>\n<\/blockquote>\n

Bitcoin Classic<\/a> is a new implementation of the Bitcoin protocol with an increased block size limit of 2 megabytes. This change in the block size limit would require a hard fork, and it is enabled 28 days after 750 of the last 1,000 blocks have been found by miners who support the increase. <\/p>\n

Many Bitcoin Core contributors find this hard fork to be contentious and would like to see something in the 90 to 95 percent social consensus<\/a> range. Although an intentional hard fork has never been attempted on the Bitcoin network (Note: One change<\/a> implemented in 2010 and activated in 2012 had implications somewhat similar to a hard fork), 95 percent approval from miners has been the standard for past soft forks.<\/p>\n

We All Want Bigger Blocks<\/strong><\/p>\n

Lombrozo said everyone would like to see the Bitcoin network scale via an increased block size limit. He explained:<\/p>\n

\n

\u201cAs far as the block size itself, I don\u2019t think there was much issue with bigger blocks. I don\u2019t think many of the Core developers actually said, \u2018No, we should never have bigger blocks.\u2019 I think, for the most part, the idea of having bigger blocks is something that is appealing. We should find a way to have bigger blocks; we all want bigger blocks. But just increasing the blocks by changing a constant in the code presents a lot of very, very serious problems.\u201d <\/p>\n<\/blockquote>\n

In other words, Bitcoin Core contributors would like to see a solution to the block size limit issue that does not involve a contentious hard fork.<\/p>\n

Segregated Witness Is the Best of Both Worlds<\/strong><\/p>\n

Until recently, the concept of increasing the block size limit while also avoiding a hard fork was theoretical. Bitcoin Core Developer Pieter Wuille<\/a> presented Segregated Witness<\/a> (SegWit) at the Scaling Bitcoin<\/a> Hong Kong Workshop to near-universal acclaim. Lombrozo described how this solution provides developers with the best path forward:<\/p>\n

\n

\u201cIt turns out, if we want to do this and do it safely, we probably have to retrofit some stuff and do a lot more risk mitigation, which is what we\u2019re trying to do with this. With SegWit, we kind of get the best of both worlds. I mean yes, it\u2019s not a single, constant change in the code \u2013 it does require a bit of modification to applications \u2013 but it\u2019s not a very significant modification. And it\u2019s much safer from all of the other aspects of it. It really does not cause all of the stability issues that just changing this constant does.\u201d <\/p>\n<\/blockquote>\n

Some detractors of the SegWit soft fork have noted the changes to Bitcoin wallets required by this proposal are too cumbersome, but Lombrozo said that the wallet developers he\u2019s worked with have been able to implement the required changes in a few days<\/a>. The Bitcoin Core website also lists<\/a> the wallet providers who plan to support SegWit.<\/p>\n

The Soft Fork Is Almost Like a No-Brainer<\/strong><\/p>\n

In Lombrozo\u2019s view (and Bitcoin Core\u2019s view according to their roadmap<\/a>), the Segregated Witness soft fork is nearly a no-brainer. The Ciphrex CEO explained:<\/p>\n

\n

\u201cBlock size was never really the issue; that was never really what people were arguing about. It was much more about this hard fork thing \u2013 whether we should do a hard fork or not. Now that we have a soft fork way to do it, it\u2019s almost like a no-brainer.\u201d <\/p>\n<\/blockquote>\n

Lombrozo went on to say that there is general consensus among the Bitcoin Core development community that the network cannot handle blocks much bigger than 2 megabytes right now. This means a hard fork to anything over 2 megabytes would likely not gain social consensus among Bitcoin Core contributors. Segregated Witness also comes with a variety of benefits unrelated to the block size limit, which Lombrozo has discussed<\/a> in the past.<\/p>\n

Kyle Torpey is a freelance journalist who has been following Bitcoin since 2011. His work has been featured on VICE Motherboard, Business Insider, RT\u2019s Keiser Report and many other media outlets. You can follow <\/em>@kyletorpey<\/em><\/a> on Twitter.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

Bitcoin Core contributor and Ciphrex CEO Eric Lombrozo was recently interviewed on Epicenter Bitcoin, and he used a portion of his time to explain some misconceptions and misunderstandings related to the block size limit debate.  While the focus of this development controversy has mainly centered on the actual block size metric in the Bitcoin protocol, […]<\/p>\n","protected":false},"author":3445,"featured_media":2454,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[1694,1038,245,3493,3297,2306,1739,705,1079],"class_list":{"0":"post-25427","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-technical","8":"tag-blocks","9":"tag-core","10":"tag-developers","11":"tag-epicenter","12":"tag-eric-lombrozo","13":"tag-forks","14":"tag-podcasts","15":"tag-scaling","16":"tag-segwit"},"author_data":{"id":3445,"name":"Kyle Torpey","nicename":"kyle-torpey","avatar_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/12\/kyle-torpey-promo-image-96x96.jpg"},"featured_image_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/11\/bitcoin-core-developer-eric-lombrozo-on-misunderstandings-in-block-size-debate.jpg","_links":{"self":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/25427","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/users\/3445"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/comments?post=25427"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/25427\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media\/2454"}],"wp:attachment":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media?parent=25427"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=25427"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=25427"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}