{"id":24387,"date":"2017-01-25T15:39:15","date_gmt":"2017-01-25T15:39:15","guid":{"rendered":"http:\/\/ci027cfe7c000726c3"},"modified":"2017-01-25T15:39:15","modified_gmt":"2017-01-25T15:39:15","slug":"closer-look-bitcoin-unlimiteds-configurable-block-size-proposal","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/closer-look-bitcoin-unlimiteds-configurable-block-size-proposal","title":{"rendered":"A Closer Look at Bitcoin Unlimited\u2019s Configurable Block Size Proposal"},"content":{"rendered":"<div id=\"bsf_rt_marker\"><\/div><figure><img decoding=\"async\" src=\"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/11\/a-closer-look-at-bitcoin-unlimiteds-configurable-block-size-proposal.jpg\" title=\"\"><\/figure>\n<p><a href=\"https:\/\/www.bitcoinunlimited.info\/\" target=\"_blank\" rel=\"noopener\">Bitcoin Unlimited<\/a>, one of the <a href=\"https:\/\/bitcoincore.org\/\" target=\"_blank\" rel=\"noopener\">Bitcoin Core<\/a> software forks <a href=\"https:\/\/bitcoinmagazine.com\/articles\/unlimited-classic-and-bitpay-core-bitcoin-s-new-kids-on-the-blockchain-1452705977\">introduced<\/a> in late 2015, garnered much attention in recent months. The project gained hash power support from several new Bitcoin <a href=\"https:\/\/bitcoinmagazine.com\/bitcoin-mining\/what-are-bitcoin-mining-pools\">mining pools<\/a>, including <a href=\"https:\/\/www.viabtc.com\/\" target=\"_blank\" rel=\"noopener\">ViaBTC<\/a>, <a href=\"https:\/\/gbminers.com\/\" target=\"_blank\" rel=\"noopener\">GBMiners<\/a> and <a href=\"https:\/\/btc.top\/\" target=\"_blank\" rel=\"noopener\">BTC.TOP<\/a>, while <a href=\"http:\/\/xtnodes.com\/#bitcoin_unlimited\" target=\"_blank\" rel=\"noopener\">node adoption<\/a> appears to be on the rise as well.<\/p>\n<p>The central idea behind Bitcoin Unlimited \u2014 specified in \u201c<a href=\"https:\/\/bitco.in\/forum\/threads\/closed-passed-buip001-unlimited-inspired-extensions-to-the-bitcoin-client.222\/\" target=\"_blank\" rel=\"noopener\">Bitcoin Unlimited Improvement Proposal 001<\/a>\u201d (BUIP001) \u2014 is to hand control of Bitcoin\u2019s block size limit to users and miners. Or perhaps more accurately: to make this control more explicit and easier to handle.<\/p>\n<h2><strong>The Proposal<\/strong><\/h2>\n<p>The Bitcoin protocol, as enforced by economically relevant nodes, currently includes a one-megabyte block size limit. If a miner were to create a block larger than one megabyte, that block would be considered invalid. It would not become part of Bitcoin\u2019s blockchain, and the miner that mined it would have wasted its resources producing it.<\/p>\n<p>BUIP001 \u2014 drafted by Bitcoin Unlimited lead developer Andrew Stone \u2014 disposes of the one-megabyte block size limit protocol rule entirely, and replaces it with three configurable options. Two of these are configurable by all node operators, which include regular users as well as miners. And a third option is only for miners.<\/p>\n<p>These configurations are signaled to the Bitcoin network. Regular users broadcast their preferences to other nodes, and miners embed their preferences in the blocks they mine.<\/p>\n<h2><strong>Option 1: Maximum Generation Size, or \u201cMG\u201d<\/strong><\/h2>\n<p>First, there is the Maximum Generation Size, also referred to as \u201cMG.\u201d This option is for miners only and is fairly straightforward: it lets miners set the size of blocks they produce. The default setting is one megabyte: It doesn\u2019t automatically diverge from the current Bitcoin protocol. But if a miner wants to create a two-megabyte block, it\u2019s as simple as \u201cflipping a switch\u201d in Bitcoin Unlimited\u2019s user interface. If a miner wants to produce an eight-megabyte block, it\u2019s the same switch.<\/p>\n<p>(The only limits left are limits on message length, which Bitcoin Unlimited set at 160 megabytes. And eventually data type limits or machine resource limits.)<\/p>\n<p>MG gives miners full control over the size of blocks they produce. But of course, as explained above, a two-megabyte block would be rejected by the network right now.<\/p>\n<p>That\u2019s where the second configurable option comes in.<\/p>\n<h2><strong>Option 2: Excessive Block Size, or \u201cEB\u201d<\/strong><\/h2>\n<p>The Excessive Block Size, typically referred to as \u201cEB,\u201d determines the size of blocks that nodes and miners accept. If a miner produces a two-megabyte block, that block will be accepted by all nodes and miners that set EB to at least two megabytes.<\/p>\n<p>EB is set at sixteen megabytes by default and is configurable by both normal users and miners. But it is an especially important configuration for miners: miners only mine on top of blocks they accept. A miner that maintains Bitcoin\u2019s current one-megabyte block size limit will reject a two-megabyte block, to instead keep mining on the last one-megabyte block. A miner that sets EB to two megabytes, however, will immediately mine on top of that same two-megabyte block, regardless of what the rest of the network does.<\/p>\n<p>Of course, this also presents a problem.<\/p>\n<p>If a minority of miners sets EB to one megabyte, and a majority of miners sets EB to, say, two megabytes, the network could split in two. As soon as anyone mines a two-megabyte block, a minority of miners will ignore it, and instead continue to extend the one-megabyte chain. The majority of miners, however, will accept the chain with the two-megabyte block, and extend that chain.<\/p>\n<p>Different groups of miners would consider different chains valid, and mine on top of their \u201cown\u201d chain while ignoring the other chain. This split could technically last forever without the two chains ever converging, in effect splitting Bitcoin into two different networks and currencies.<\/p>\n<p>In an attempt to resolve this, Bitcoin Unlimited introduces the third configurable option.<\/p>\n<h2><strong>Option 3: Excessive Acceptance Depth, or \u201cAD\u201d<\/strong><\/h2>\n<p>Excessive Acceptance Depth, or \u201cAD,\u201d essentially overrules EB. More specifically, AD determines the number of added confirmations a block requires, before nodes and miners accept it regardless of that block\u2019s size. The default is four.<\/p>\n<p>So, let\u2019s say a node sets EB to two megabytes, and AD to four added confirmations. If that node receives a three-megabyte block, it will initially ignore that block since it exceeds its two-megabyte EB. But if a majority of miners does not ignore that block, and mines four new blocks on top of it, the node\u2019s two-megabyte EB is overruled by its four AD confirmations. The three-megabyte block is retroactively accepted as valid.<\/p>\n<p>As such, different miners (and nodes) should \u2014 eventually \u2014 converge on a single valid chain, even if they have different MG and EB settings.<\/p>\n<p>Last, it\u2019s worth briefly mentioning the \u201csticky gate.\u201d If a node\u2019s AD is hit, that node will accept subsequent blocks of any size for about 24 hours (144 blocks). This sticky gate ensures that miners immediately build on the chain with the newly accepted bigger blocks, and not continuously lag behind on the rest of the network, while waiting for each block to reach sufficient AD.<\/p>\n<p>The <a href=\"https:\/\/bitcoinmagazine.com\/articles\/how-bitcoin-unlimited-users-may-end-different-blockchains\">next article<\/a> will take a closer look at some of the weaknesses of BUIP001.<\/p>\n<p><em>\u201cJonny1000\u201d contributed to this article.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>BUIP001 \u2014 drafted by Bitcoin Unlimited lead developer Andrew Stone \u2014 disposes of the one-megabyte block size limit protocol rule entirely, and replaces it with three configurable options. Two of these are configurable by all node operators, which include regular users as well as miners. And a third option is only for miners.<\/p>\n","protected":false},"author":2509,"featured_media":24388,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[3568,1662,556],"class_list":{"0":"post-24387","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-technical","8":"tag-bitcoin-unlimited","9":"tag-block-size","10":"tag-blockchain"},"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\/a-closer-look-at-bitcoin-unlimiteds-configurable-block-size-proposal.jpg","_links":{"self":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/24387","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=24387"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/24387\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media\/24388"}],"wp:attachment":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media?parent=24387"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=24387"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=24387"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}