{"id":2880,"date":"2019-07-13T18:22:58","date_gmt":"2019-07-13T18:22:58","guid":{"rendered":"https:\/\/bitcoinsv.io\/?p=2880"},"modified":"2020-09-28T06:16:56","modified_gmt":"2020-09-28T06:16:56","slug":"quasar-upgrade-24th-july-recommendations-roadmap-to-genesis-part-2","status":"publish","type":"post","link":"https:\/\/bitcoinsv.io\/2019\/07\/13\/quasar-upgrade-24th-july-recommendations-roadmap-to-genesis-part-2\/","title":{"rendered":"Quasar upgrade 24th July recommendations \u2013 roadmap to Genesis part 2"},"content":{"rendered":"\n

On the 24th<\/sup> of July 2019 the Bitcoin SV will undergo a forking protocol upgrade.  This upgrade has very limited scope with just changing the block size hard cap but it warrants some further explanation.  It was first detailed in part one of this post series<\/a>.<\/p>\n\n\n\n

The first upgrade, code named \u201cQuasar\u201d, is proposed for Jul 24th 2019 and is primarily focused on scaling.  At a protocol level the only change planned for this upgrade is a lifting of the default block size hard cap.  We have previously signaled an intent to raise the cap to 512MB however after consultation with the Bitcoin Association (the owner of the Bitcoin SV project) and miners representing a significant majority of hash rate it has been decided that the Bitcoin SV software will implement a default of 2GB in July<\/b>.  Initially a majority of miner hash rate will manually set their hard cap down to 512MB.<\/em><\/p>\n\n\n\n

Quick recap of caps<\/h2>\n\n\n\n

There are actually three block size caps to consider when thinking about how block size governance works in Bitcoin.  I have previously only talked about two: soft cap and hard cap.  But in this case it\u2019s worth thinking about two different versions of the hard cap.<\/p>\n\n\n\n

Soft cap<\/strong>: Is a miner specific setting that indicates that maximum sized block a specific node will try to mine<\/strong>.<\/p>\n\n\n\n

Hard cap<\/strong>: Is the maximum sized block that a miner will accept<\/strong> as valid. This is the setting we intend to remove entirely in the Genesis upgrade next February.  It is also the one we need to consider in two ways.<\/p>\n\n\n\n

Firstly, there is the default setting.  If you don\u2019t manually set this value on a Bitcoin SV node it will use the default.  The upcoming Quasar upgrade changes this default value from 128mb to 2gb or more specifically 2,000,000,000 bytes.<\/p>\n\n\n\n

Secondly there is the setting that the majority of mining hashrate is using.  In this case we have previously announced that a group of miners totaling a majority of hashrate have signaled their intent to manually set their hard cap to 512mb.<\/p>\n\n\n\n

So let\u2019s call these two cases the \u201cdefault hard cap<\/strong>\u201d and the \u201cconsensus hard cap<\/strong>\u201d respectively.<\/p>\n\n\n\n

Consensus is among miners<\/h2>\n\n\n\n

If you\u2019ve ever heard the nonsense about how it\u2019s important for other people (non-miners) to run fully validating nodes, you\u2019re about to get a real life demonstration that this is simply not true.<\/p>\n\n\n\n

We are not recommending that anyone but miners make manual changes to their hard caps.  This is for the simple reason that it is easier to follow consensus if you don\u2019t enforce a hard cap at all and if you can\u2019t do that, the next best thing is to have a higher hard cap than the consensus hard cap.  We will explain this in more detail later in this post.<\/p>\n\n\n\n

Recommendations for miners<\/h2>\n\n\n\n

If you are a miner it is recommended that you set your hard cap to 512mb and that you set your soft cap to some lower value.  In the Bitcoin SV software these are config parameters that actually have different names.  By way of example I\u2019ll give you the specific config parameters for a 512\/256 cap configuration:<\/p>\n\n\n\n

Hard cap: -excessiveblocksize=512000000\nSoft cap: -blockmaxsize=256000000<\/pre>\n\n\n\n
Recommendations for everyone else<\/h2>\n\n\n\n
By everyone else we mean people\/businesses that are running an instance of Bitcoin SV that is not involved in mining.  I call these \u201cBlockchain listeners\u201d.  Miners write the blockchain, anyone else running Bitcoin SV is just listening to it.<\/p>\n\n\n\n
For these we don\u2019t recommend changing any of the above settings.  Your default hard cap should remain at 2gb.  If you do attempt to change it to match the miners there is a risk the miners will change the setting sometime between now and February next year (and you may not hear about it) and you will be permanently forked off the network until you notice and raise your own limit.<\/p>\n\n\n\n
But what if there\u2019s a bigger block than 512mb?<\/h2>\n\n\n\n
Fair question.  Your node will accept that block initially then one of two thing will happen.<\/p>\n\n\n\n
1\/ If the miner that mined the larger block has a majority of hashrate then the chain will get longer and you\u2019ll continue following the longest chain.  The other miners will have to choose to either raise their limit and follow the longest chain or remain forked.  I\u2019d put my money on the former.<\/p>\n\n\n\n
2\/ If the miner that mined the larger block has minority hashrate then the bock will get orphaned and your Bitcoin SV instance will reorg back to the majority chain.<\/p>\n\n\n\n
That sounds dangerous<\/h2>\n\n\n\n
Of course it does.  We\u2019ve all been told for 10 years that orphans are bad and a security risk. But it\u2019s simply not the case, it\u2019s actually how Bitcoin is supposed to work. I\u2019ve addressed this point extensively here<\/a>.<\/p>\n\n\n\n
Retraining Bitcoin<\/h2>\n\n\n\n
In the introduction we described the Quasar upgrade as being very limited in scope.  That\u2019s not entirely true.  From a technical point of view the changes are limited but its role in the lead up to the Genesis upgrade is much more important that it may seem on the surface.<\/p>\n\n\n\n
Some will no doubt ask \u201cwhat if a malicious party mines blocks larger than 512mb just to cause trouble\u201d.  Well I hope they do because it will be the first real life demonstration of the power of Nakamoto consensus as a capacity governance tool.<\/p>\n\n\n\n
This upgrade represents a very significant cultural shift for Bitcoin.  By separating the default hard cap (developer chosen) from the consensus hard cap (miner chosen) we are diluting the power of the default setting which can only be set by a single group (us).  This is a very active effort by the Bitcoin SV development team to push the responsibility for capacity consensus out of their own hands and into the hands of miners.  The miners are now responsible for managing block size consensus and if they screw it up it will cost them.  The final stage in that transition is removing the default altogether next year (or rather the default will be infinite).  But we think it\u2019s fair to give the miners time to get used their new role and we also need a bit more time to give them better tools to manage uncapped block sizes more safely.<\/p>\n\n\n\n
Putting aside miners for a moment, there is another consideration.  Operators of blockchain listeners are slowly getting used to the idea that they need to make peace with orphans and reorgs or at the least, if they can\u2019t make peace with it, learn how manage in an environment where they are normalized.  It\u2019s not hard to do and we already have some of the tools to do it.  But a reorg or two from time to time is a good reminder.  This is another reason we are pushing businesses onto the STN.  We want to break your services there.  But reorgs don\u2019t really break services they seem to cause more of a mental shock to people who\u2019ve been listening to Core for too long.  So if someone wants to mine 600mb blocks and try to cause some reorgs we\u2019re pretty happy for that to happen.  It will do two things, it will help people in the ecosystem get used to reorgs as normal events and Nakamoto consensus will ensure the event costs some miner dearly which is also a thing they need to get used to.<\/p>\n\n\n\n
Bitcoin is a brutally Darwinian game.  It is a reflection of the natural world in which some of the harsher realities are the very things that drive the strengthening of species and the global ecosystem that hosts them. Quasars are one the most brutal phenomena in nature and the Quasar upgrade is all about helping all Bitcoin participants to understand and adapt to those facts in preparation for the gloves coming off fully after the return to Genesis.<\/p>\n\n\n\n
Steve Shadders<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"
On the 24th of July 2019 the Bitcoin SV will undergo a forking protocol upgrade.  This upgrade has very limited scope with just changing the block size hard cap but it warrants some further explanation.  It was first detailed in part one of this post series. The first upgrade, code named \u201cQuasar\u201d, is proposed for […]<\/p>\n","protected":false},"author":4,"featured_media":4268,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[73],"tags":[],"lang":"en","translations":{"en":2880},"yoast_head":"\nQuasar upgrade 24th July recommendations \u2013 roadmap to Genesis part 2 - Bitcoin SV<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/stag.bitcoinsv.io\/2019\/07\/13\/quasar-upgrade-24th-july-recommendations-roadmap-to-genesis-part-2\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Quasar upgrade 24th July recommendations \u2013 roadmap to Genesis part 2 - Bitcoin SV\" \/>\n<meta property=\"og:description\" content=\"On the 24th of July 2019 the Bitcoin SV will undergo a forking protocol upgrade.  This upgrade has very limited scope with just changing the block size hard cap but it warrants some further explanation.  It was first detailed in part one of this post series. The first upgrade, code named \u201cQuasar\u201d, is proposed for […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/stag.bitcoinsv.io\/2019\/07\/13\/quasar-upgrade-24th-july-recommendations-roadmap-to-genesis-part-2\/\" \/>\n<meta property=\"og:site_name\" content=\"Bitcoin SV\" \/>\n<meta property=\"article:published_time\" content=\"2019-07-13T18:22:58+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2020-09-28T06:16:56+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/bitcoinsv.io\/wp-content\/uploads\/2020\/09\/roadmap-quasar.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1280\" \/>\n\t<meta property=\"og:image:height\" content=\"840\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@BitcoinSVNode\" \/>\n<meta name=\"twitter:site\" content=\"@BitcoinSVNode\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Organization\",\"@id\":\"https:\/\/bitcoinsv.io\/#organization\",\"name\":\"Bitcoin SV\",\"url\":\"https:\/\/bitcoinsv.io\/\",\"sameAs\":[\"https:\/\/twitter.com\/BitcoinSVNode\"],\"logo\":{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/bitcoinsv.io\/#logo\",\"inLanguage\":\"en-US\",\"url\":\"https:\/\/bitcoinsv.io\/wp-content\/uploads\/2020\/10\/bsv-logo-wh-medium.png\",\"width\":800,\"height\":144,\"caption\":\"Bitcoin SV\"},\"image\":{\"@id\":\"https:\/\/bitcoinsv.io\/#logo\"}},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/bitcoinsv.io\/#website\",\"url\":\"https:\/\/bitcoinsv.io\/\",\"name\":\"Bitcoin SV\",\"description\":\"Just another WordPress site\",\"publisher\":{\"@id\":\"https:\/\/bitcoinsv.io\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":\"https:\/\/bitcoinsv.io\/?s={search_term_string}\",\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"en-US\"},{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/stag.bitcoinsv.io\/2019\/07\/13\/quasar-upgrade-24th-july-recommendations-roadmap-to-genesis-part-2\/#primaryimage\",\"inLanguage\":\"en-US\",\"url\":\"https:\/\/bitcoinsv.io\/wp-content\/uploads\/2020\/09\/roadmap-quasar.jpg\",\"width\":1280,\"height\":840},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/stag.bitcoinsv.io\/2019\/07\/13\/quasar-upgrade-24th-july-recommendations-roadmap-to-genesis-part-2\/#webpage\",\"url\":\"https:\/\/stag.bitcoinsv.io\/2019\/07\/13\/quasar-upgrade-24th-july-recommendations-roadmap-to-genesis-part-2\/\",\"name\":\"Quasar upgrade 24th July recommendations \\u2013 roadmap to Genesis part 2 - Bitcoin SV\",\"isPartOf\":{\"@id\":\"https:\/\/bitcoinsv.io\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/stag.bitcoinsv.io\/2019\/07\/13\/quasar-upgrade-24th-july-recommendations-roadmap-to-genesis-part-2\/#primaryimage\"},\"datePublished\":\"2019-07-13T18:22:58+00:00\",\"dateModified\":\"2020-09-28T06:16:56+00:00\",\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/stag.bitcoinsv.io\/2019\/07\/13\/quasar-upgrade-24th-july-recommendations-roadmap-to-genesis-part-2\/\"]}]},{\"@type\":\"Article\",\"@id\":\"https:\/\/stag.bitcoinsv.io\/2019\/07\/13\/quasar-upgrade-24th-july-recommendations-roadmap-to-genesis-part-2\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/stag.bitcoinsv.io\/2019\/07\/13\/quasar-upgrade-24th-july-recommendations-roadmap-to-genesis-part-2\/#webpage\"},\"author\":{\"@id\":\"https:\/\/bitcoinsv.io\/#\/schema\/person\/d1b90c2f0b7b27b52e59ef856a57ab4e\"},\"headline\":\"Quasar upgrade 24th July recommendations \\u2013 roadmap to Genesis part 2\",\"datePublished\":\"2019-07-13T18:22:58+00:00\",\"dateModified\":\"2020-09-28T06:16:56+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/stag.bitcoinsv.io\/2019\/07\/13\/quasar-upgrade-24th-july-recommendations-roadmap-to-genesis-part-2\/#webpage\"},\"publisher\":{\"@id\":\"https:\/\/bitcoinsv.io\/#organization\"},\"image\":{\"@id\":\"https:\/\/stag.bitcoinsv.io\/2019\/07\/13\/quasar-upgrade-24th-july-recommendations-roadmap-to-genesis-part-2\/#primaryimage\"},\"articleSection\":\"Articles\",\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/bitcoinsv.io\/#\/schema\/person\/d1b90c2f0b7b27b52e59ef856a57ab4e\",\"name\":\"Steve Shadders\",\"image\":{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/bitcoinsv.io\/#personlogo\",\"inLanguage\":\"en-US\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/d08dfcc7367f9cdd71cedbd77082b84f?s=96&d=mm&r=g\",\"caption\":\"Steve Shadders\"},\"description\":\"Steve has been involved in Bitcoin infrastructure since early 2011. In his role, he contributes his ecosystem-wide perspective, to support building the mining and UX infrastructure, needed to enable Satoshi\\u2019s Vision.\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","pll_sync_post":[],"_links":{"self":[{"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/posts\/2880"}],"collection":[{"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/comments?post=2880"}],"version-history":[{"count":2,"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/posts\/2880\/revisions"}],"predecessor-version":[{"id":4267,"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/posts\/2880\/revisions\/4267"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/media\/4268"}],"wp:attachment":[{"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/media?parent=2880"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/categories?post=2880"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinsv.io\/wp-json\/wp\/v2\/tags?post=2880"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}