From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <peter_r@gmx.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8005F728 for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 26 Nov 2016 23:35:56 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 503B7CE for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 26 Nov 2016 23:35:55 +0000 (UTC) Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx001 [212.227.17.184]) with ESMTPSA (Nemesis) id 0LdHeL-1cbd1715N3-00iT7z; Sun, 27 Nov 2016 00:35:52 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_0B1F3391-D70D-48C7-875B-9532A9BA582E" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Peter R <peter_r@gmx.com> In-Reply-To: <2318925.r6f9XVyAit@cherry> Date: Sat, 26 Nov 2016 15:35:49 -0800 Message-Id: <6AAD09CF-937E-4D35-B70A-CFDAB84A6B32@gmx.com> References: <C10BF9D1-435D-47C9-B98C-9B118B5922A1@gmx.com> <CAKzdR-rL9ndo9JZodLiSc0BEThiF1kQMs4yvkjJyc_8nzmp8DA@mail.gmail.com> <CAKzdR-oE44Qcb1sfz3RmcVmtR9qzB+9J5ufTgGmdQ_Xctenh7A@mail.gmail.com> <2318925.r6f9XVyAit@cherry> To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:KghG9RfxUKtXnES3lXFY/jdH6KL8R4Cz8ubFgvHJusgMFUugCDk Ne8tSQ74GUg2wkMgG85xB9uj+U9epcO8bt2CWZc82JTWFnImXjAFNig3uouSKaPg/2XNQN9 Z0hWCx1EHaerg7ebJtNECdXsMKAOafktCNxqKclyrJR1BVwnKu39XxNRB3MBtBWx8/cs6FF xAflXrctaEWrGhUc6z5Pw== X-UI-Out-Filterresults: notjunk:1;V01:K0:76uCOtAuZq4=:FHeX1tO4YCstqFe8+PrSxM lloupK30c7rB/lQhpnEN6oLIhhYfwMhBDgKTiJOZxVVz8rYgVLGp6Fri7O4mqd833ysXyZdep aq8sp9jTHaL+S0X5pTLMRV39rMB4uNwLeVOiAfI0alYph6oX4URN8tQiK7Jb4DGpPBynHYcrC MD1o6S3NNuE4INiLusTS7vT4mf17ET6eQ79YXxVfd1K/ZxGli/b91hKgW67k1c0pBBk75W35i /w/2WoRhhL97JLp2BIhRXV5qhlvhpE516+9zJ92WMy0sOcq38AjHujd+kL2wj3tOxlDl68cjN bSrUcA99Hafn0as64CWVI37pBNHP8zW3pGo2zd55lput4Iln9Q/dJ7pufdNvDCvjfDG0UDX+y hXyvpBWYRecbB0OQD0jXeob/5Za/tAeDGJLy2uCBqA+ilBYOsnH48RTOj+lxGpJ0bOnupMykw 3P2NVh+DTsQmNTbet/zW908cGE2sxEqQQ4q0Rxa/ASzoJQ1zRzQOv4tUvQ0cCzVECBJ3Nbxwv KAaElkhsLTVCzYo8FhZuYJzPAzWLg4XJn4JFNY4H1fccjHh47F8qMXmPo9na1FbEwAQd6hPOU wRgg+aSPv90XOH3vXWV2Fu0SCkNF6lCFfeazoG6HchZs4T2Np1g5YkCr1xNQ246sXiPi5rHX3 P9CpOUJCKC2wjpaZipfCFW/uFHxkpRsue4lS17YXfP0tboy/eY3DKR1UjExNZdYttZlY/aCOh 3n+3je5fzJegrWyZZzqRPh0AbwL4V9vk43WYbs/qmXau28oIU8VQTX4dOnzO1kUJ51ZOeg7rd fGLwJtumgOX5lhrjYBjE4EYK9+qvl3dd22vzM29JWMprf/jIoc5pMawHKw3249SI7EkpV+YBL Gk9g96M5j2Q8kg14lSyQ== X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 27 Nov 2016 00:40:39 +0000 Subject: Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Sat, 26 Nov 2016 23:35:56 -0000 --Apple-Mail=_0B1F3391-D70D-48C7-875B-9532A9BA582E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Great discussion, Sergio and Tom! > I now think my reasoning and conclusions are based on a false premise: = that BU block size policies for miners can be heterogeneous. Right, miners who set their block size limits (BSL) above OR below the = "effective BSL" are disadvantaged. Imagine that we plot the = distribution (by hash power) for all miners' BSLs. We might get a chart = that looks like this: http://imgur.com/a/tWNr6 <http://imgur.com/a/tWNr6> In this chart, the "effective BSL" is defined as the largest block size = that no less than half the hash power will accept. =20 If a block is mined with a size Q that is less than the "effective BSL," = then all the hash power with BSLs between BSL_min and Q will be forked = from the longest chain (until they update their software if they're = running Core or until their acceptance depth is hit if they're running = BU). This wastes these miners' hash power. =20 However, if a block is mined with a size Q that is greater than the = effective BSL, then all the hash power with BSLs between Q and BSL_max = will temporarily be mining on a "destined to be orphaned" chain. This = also wastes these miners' hash power. =20 Therefore, it is in the best interest of miners to all set the same = block size limit (and reliably signal in their coinbase TX what that = limit is, as done by Bitcoin Unlimited miners). =20 We have empirical evidence the miners in fact behave this way:=20 (1) No major miner has ever set his block size limit to less than 1 MB = (not even those such as Luke-Jr who think 1 MB is too big) because doing = so would just waste money. =20 (2) After switching to Bitcoin Unlimited, both ViaBTC and the = Bitcoin.com pool temporarily set their BSLs to 2 MB and 16 MB, = respectively (of course keeping their _generation limit_ at 1MB). = However, both miners quickly reduced these limits back to 1 MB when they = realized how it was possible to lose money in an attack scenario. (This = actually surprised me because the only way they could lose money is if = some _other_ miner wasted even more money by purposely mining a = destined-to-be-orphaned block.) =20 The follow-up article I'm working on is about the topics we're = discussing now, particularly about how Bitcoin Unlimited's = =E2=80=9Cnode-scale=E2=80=9D behavior facilitates the emergence of a = fluid and organic block size limit at the network scale. Happy to keep = continue with this current discussion, however. Best regards Peter --Apple-Mail=_0B1F3391-D70D-48C7-875B-9532A9BA582E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><div class=3D"">Great discussion, Sergio and Tom!</div><div = class=3D""><br class=3D""></div><div class=3D""><blockquote type=3D"cite" = class=3D"">I now think my reasoning and conclusions are based on a false = premise: that BU block size policies for miners can be = heterogeneous.</blockquote></div><div class=3D""><br class=3D""></div><div= class=3D"">Right, miners who set their block size limits (BSL) above OR = below the "effective BSL" are disadvantaged. Imagine that we plot = the distribution (by hash power) for all miners' BSLs. We might = get a chart that looks like this:</div><div class=3D""><br = class=3D""></div><div class=3D""><a href=3D"http://imgur.com/a/tWNr6" = class=3D"">http://imgur.com/a/tWNr6</a></div><div class=3D""><br = class=3D""></div><div class=3D"">In this chart, the "effective BSL" is = defined as the largest block size that no less than half the hash power = will accept. </div><div class=3D""><br class=3D""></div><div = class=3D"">If a block is mined with a size Q that is less than the = "effective BSL," then all the hash power with BSLs between BSL_min and Q = will be forked from the longest chain (until they update their software = if they're running Core or until their acceptance depth is hit if = they're running BU). This wastes these miners' hash power. = </div><div class=3D""><br class=3D""></div><div class=3D"">However, = if a block is mined with a size Q that is greater than the effective = BSL, then all the hash power with BSLs between Q and BSL_max will = temporarily be mining on a "destined to be orphaned" chain. This = also wastes these miners' hash power. </div><div class=3D""><br = class=3D""></div><div class=3D"">Therefore, it is in the best interest = of miners to all set the same block size limit (and reliably signal in = their coinbase TX what that limit is, as done by Bitcoin Unlimited = miners). </div><div class=3D""><br class=3D""></div><div = class=3D"">We have empirical evidence the miners in fact behave this = way: </div><div class=3D""><br class=3D""></div><div class=3D"">(1) = No major miner has ever set his block size limit to less than 1 MB (not = even those such as Luke-Jr who think 1 MB is too big) because doing so = would just waste money. </div><div class=3D""><br = class=3D""></div><div class=3D"">(2) After switching to Bitcoin = Unlimited, both ViaBTC and the <a href=3D"http://Bitcoin.com" = class=3D"">Bitcoin.com</a> pool temporarily set their BSLs to 2 MB and = 16 MB, respectively (of course keeping their _generation limit_ at 1MB). = However, both miners quickly reduced these limits back to 1 MB = when they realized how it was possible to lose money in an attack = scenario. (This actually surprised me because the only way they = could lose money is if some _other_ miner wasted even more money by = purposely mining a destined-to-be-orphaned block.) = </div><div class=3D""><br class=3D""></div><div class=3D"">The= follow-up article I'm working on is about the topics we're discussing = now, particularly about how Bitcoin Unlimited's =E2=80=9Cnode-scale=E2=80=9D= behavior facilitates the emergence of a fluid and organic block size = limit at the network scale. Happy to keep continue with this = current discussion, however.</div><div class=3D""><br = class=3D""></div><div class=3D"">Best regards</div><div = class=3D"">Peter</div><div class=3D""><br class=3D""></div></body></html>= --Apple-Mail=_0B1F3391-D70D-48C7-875B-9532A9BA582E--