{"id":20531,"date":"2019-02-15T22:18:38","date_gmt":"2019-02-15T22:18:38","guid":{"rendered":"http:\/\/ci027cfe6610072697"},"modified":"2025-01-28T16:02:18","modified_gmt":"2025-01-28T16:02:18","slug":"is-it-time-to-take-an-initiative-to-decrease-bitcoins-block-size-seriously","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/is-it-time-to-take-an-initiative-to-decrease-bitcoins-block-size-seriously","title":{"rendered":"Is It Time to Take an Initiative to Decrease Bitcoin\u2019s Block Size Seriously?"},"content":{"rendered":"
<\/div>
<\/figure>\n

Whilst debate raged throughout the Bitcoin community over whether the block size limit should be increased and how, Luke-jr for years stood out for arguing the exact opposite position. One megabyte blocks weren\u2019t too small, he maintained even as SegWit\u2019s block size increase gained broad support, they were too big. No increase, but a decrease was needed.<\/p>\n

Now, the Bitcoin Knots and Bitcoin Core developer is spearheading an attempt to make such a decrease happen, as a temporary measure. And if social media is any indication, the initiative is attracting more interest than many might have expected it would.<\/p>\n

\u201cI don’t know if the proposal will be adopted or not, but support has been growing due to the block size becoming more and more apparently a problem,\u201d Luke-jr told Bitcoin Magazine<\/em>.<\/p>\n

Block Size Decrease<\/h3>\n

Of course, the arguments for<\/em> decreasing the block size limit are similar to the by now oft-repeated arguments against<\/em> increasing the block size limit. In short, bigger blocks add to the cost of running a node (making it more expensive for users to enforce the protocol rules), could increase mining centralization (risking censorship resistance), and reduces fee pressure (translating into less hash power security).<\/p>\n

The most pressing problem of these, for Luke-jr, is the cost of running a full node. This is perhaps best exemplified by the time it takes to initially sync such a node. Getting up to speed with the rest of the network can take days even on modern laptops with a good internet connection.<\/p>\n

\u201cUsers acting on that cost by simply choosing not to run a full node is a problem,\u201d Luke-jr said. \u201cWhen someone does finally attack Bitcoin, it will split the network \u2014 full node users on one chain, and light wallet users on the other.\u201d<\/p>\n

In case of such a broad scale attack on light wallet users, \u201ca New York Agreement<\/a>-in-secret,\u201d Luke-jr envisions a worst-case scenario where these users would rather continue to use the invalid chain they\u2019d been defaulting to since the attack, instead of switching back to the original chain.<\/p>\n

\u201cWhich side prevails inevitably depends on the economic pressure of users of each chain. If most people are using light wallets, then full node users will lose out, and the invalid chain effectively becomes simply a hard fork to Bitcoin,\u201d he argued, leaving little room for nuance. \u201cThat means all protocol rules are open to change, including the ones that forbid inflation, theft, etcetera.\u201d<\/p>\n

Following Luke-jr\u2019s reasoning, Bitcoin is well into the danger zone already, as relatively few users rely on full nodes to accept payments. And it may be getting worse. Bitcoin\u2019s blockchain grows each day, and while Moore\u2019s Law<\/a> and similar trends of computational improvements negate the associated problems with this growth to an extent, the Bitcoin Knots lead maintainer thinks technological progress is not yet keeping up. (It\u2019s no exact science, but the drop in reachable node count<\/a> over the past year could suggest that the blockchain size is indeed becoming a problem for more users \u2014 then again this node count is up<\/a> over the past two<\/em> years.)<\/p>\n

On the flip side, the main argument against smaller blocks is that it would limit the number of transactions the Bitcoin network would be able process, which increases fee pressure, and could out-price certain use cases. (Instead of running full nodes, users may opt to rely on custodial services to save on fees, arguably making matters worse \u2014 not better.)<\/p>\n

But with the development of the Lightning Network making noticeable progress, proponents of a block size limit decrease believe this downside is largely mitigated. Users would be incentivized to migrate to the overlay network for fast and cheap transactions, furthering its growth and taking the load off Bitcoin\u2019s blockchain at the same time.<\/p>\n

The Plan<\/h3>\n

As the initiative is still in its early stages, it\u2019s not yet set in stone what the potential block size decrease would look like, exactly. Even the desired limit isn\u2019t settled on, though it would most likely be brought down from the current theoretical maximum of almost four megabytes to a theoretical maximum of two or less. (This would, in reality, result in even smaller blocks; closer to one megabyte.) However, if this were to be achieved, the measure would be designed not to be permanent, so that an increase back to the current limit wouldn\u2019t be too difficult later on.<\/p>\n

There are at least three rough ideas of how a block size decrease could be achieved.<\/p>\n

The most notable proposal<\/a> is a user-activated soft fork (UASF), similar to BIP148, the initiative to trigger SegWit activation in 2017. On the same date as two years ago, August 1, users would enforce the stricter rules for five months, incentivizing miners to comply. If a majority of miners (by hash power) go along, even non-upgraded users would remain compatible with the new rules; they\u2019d just see smaller blocks than previously allowed. A UASF is a risky strategy, however. If less than half of all miners go along, the blockchain could \u201csplit\u201d between upgraded and non-upgraded users.<\/p>\n

Alternatively, miners could impose a smaller block size limit themselves as a soft cap. Soft caps are non-binding limits that miners put on the blocks they mine and were used particularly throughout the first years of Bitcoin\u2019s existence. (Past soft caps were consecutively 250, 500 and 750 kilobytes, as recommended by Bitcoin developers.) This would be a much safer solution but would require that miners reject transactions and, thus, leave transaction fees on the table for each block they mine.<\/p>\n

As a third option, proposed<\/a> by Luke-jr, Bitcoin users could limit the size of blocks by making their transactions artificially \u201cheavy.\u201d Under Bitcoin\u2019s protocol rules, these transactions would be counted as if they were larger than they actually are, which means blocks would fill up faster with less actual transaction data. This change wouldn\u2019t require any protocol changes; wallets could offer it today. These transactions do, however, require individual users to choose to \u201coverpay\u201d on fees relative to regular transactions. (That\u2019s assuming miners act economically rationally and charge extra to include the heavy transactions.)<\/p>\n

Block Size Debate Fatigue<\/h3>\n

Some notable proponents of Luke-jr\u2019s initiative include Bitrefill CCO John Carvalho<\/a>, Block Digest cohost Shinobi<\/a> and JoinMarket developer Chris Belcher<\/a>. Yet all of them would only want to go through with the effort if it gains broad backing. That also goes for Luke-jr himself: \u201cSoft forks like this need a lot of community support,\u201d he said.<\/p>\n

But so far, support within the Bitcoin community appears to range from lukewarm (no pun intended) to skeptical to outright dismissive. Other than Luke-jr, no regular Bitcoin Core contributors have thrown their weight behind the proposal and no Bitcoin company of note has stated support; and while the proposal is generating a bit of buzz on social media and in chat rooms, a majority of commenters still seems to reject the idea.<\/p>\n

Even many of those who agree that a decrease would be a technical improvement in and of itself don\u2019t believe it would make too much of a difference. If blocks are smaller for several months or even several years, Bitcoin\u2019s blockchain size will still be large. Whether tomorrow\u2019s new users need to sync two days or three days may not be the deciding factor in whether to use a full node or not. Besides, there are other solutions<\/a> that could make running a full node more attractive, some of which may well have much more effect. (Though, as Luke-jr points out, none of these solutions exclude also<\/em> decreasing the block size limit.)<\/p>\n

What\u2019s more, years of in-fighting has made the Bitcoin community wary of commencing another block size battle and dealing with all the controversy that comes with it. After a long-fought \u201ccivil war,\u201d there appears to be little appetite to invest more time and energy in reviving the struggle on the same parameter \u2014 thereby, quite possibly, draining any momentum from the initiative even before it gets well underway.<\/p>\n

Indeed, even Luke-jr himself doubts he\u2019ll be the one carrying the initiative to the finish line this time.<\/p>\n

\u201cAlthough I may be the only one popularly pushing it \u2014 I don’t have time to champion another BIP148, I fear,\u201d he said, noting how exhausting the previous UASF attempt was. \u201cI think the only way it will happen is if the community takes the lead on it.\u201d<\/p>\n","protected":false},"excerpt":{"rendered":"

For years, Bitcoin developer Luke-jr stood out for arguing that the block size limit should not be increased, but decreased. Is it time to start taking him seriously?<\/p>\n","protected":false},"author":2509,"featured_media":15846,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[1662,3442,124,705,330,2341],"class_list":{"0":"post-20531","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-technical","8":"tag-block-size","9":"tag-lukedashjr","10":"tag-nodes","11":"tag-scaling","12":"tag-security","13":"tag-uasf"},"author_data":{"id":2509,"name":"Aaron van Wirdum","nicename":"aaron-van-wirdum","avatar_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/12\/aaron-van-wirdum-96x96.jpg"},"featured_image_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/11\/is-it-time-to-take-an-initiative-to-decrease-bitcoins-block-size-seriously.jpg","_links":{"self":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/20531","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\/2509"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/comments?post=20531"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/20531\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media\/15846"}],"wp:attachment":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media?parent=20531"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=20531"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=20531"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}