From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C6536EC3 for ; Sun, 7 Feb 2016 17:08:09 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2D4AB2F for ; Sun, 7 Feb 2016 17:08:09 +0000 (UTC) Received: from [192.168.1.190] (63.135.62.197.nwinternet.com [63.135.62.197] (may be forged)) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u17H81mC028097 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 7 Feb 2016 09:08:02 -0800 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_55B03182-8517-4609-A516-4D99910E6055"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Jonathan Toomim In-Reply-To: <20160207151927.GA14750@sapphire.erisian.com.au> Date: Sun, 7 Feb 2016 09:10:39 -0800 Message-Id: <57C403C6-2680-4C3D-8860-E33A525A99D4@toom.im> References: <1804222.7gVHPiWqto@kiwi> <201602062046.40193.luke@dashjr.org> <20160207151927.GA14750@sapphire.erisian.com.au> To: Anthony Towns X-Mailer: Apple Mail (2.1878.6) X-Sonic-CAuth: UmFuZG9tSVZInbt+RlgNB9mHN9y3y2A4OmyurglbmKtW2BeGbIfJVQANSn2o4xoq9XJwMPrPSnarjCYa/Jr2hyOMpTA/WZJf X-Sonic-ID: C;FiswWL3N5RGtVsEl14k5kQ== M;EojHWL3N5RGtVsEl14k5kQ== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, 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 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 17:08:09 -0000 --Apple-Mail=_55B03182-8517-4609-A516-4D99910E6055 Content-Type: multipart/alternative; boundary="Apple-Mail=_285C1A46-7DBC-46CA-BE9B-3EB7FC22C651" --Apple-Mail=_285C1A46-7DBC-46CA-BE9B-3EB7FC22C651 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 7, 2016, at 7:19 AM, Anthony Towns via bitcoin-dev = wrote: > The stated reasoning for 75% versus 95% is "because it gives "veto = power" > to a single big solo miner or mining pool". But if a 20% miner wants = to > "veto" the upgrade, with a 75% threshold, they could instead simply = use > their hashpower to vote for an upgrade, but then not mine anything on > the new chain. At that point there'd be as little as 55% mining the = new > 2MB chain with 45% of hashpower remaining on the old chain. That'd be = 18 > minute blocks versus 22 minute blocks, which doesn't seem like much of > a difference in practice, and at that point hashpower could plausibly > end up switching almost entirely back to the original consensus rules > prior to the grace period ending. Keep in mind that within a single difficulty adjustment period, the = difficulty of mining a block on either chain will be identical. Even if = the value of a 1MB branch coin is $100 and the hashrate on the 1 MB = branch is 100 PH/s, and the value of a 2 MB branch coin is $101 and the = hashrate on the 2 MB branch is 1000 PH/s, the rational thing for a miner = to do (for the first adjustment period) is to mine on the 2 MB branch, = because the miner would earn 1% more on that branch. So you're assuming that 25% of the hashrate chooses to remain on the = minority version during the grace period, and that 20% chooses to switch = back to the minority side. The fork happens. One branch has 1 MB blocks = every 22 minutes, and the other branch has 2 MB blocks every 18 minutes. = The first branch cannot handle the pre-fork transaction volume, as it = only has 45% of the capacity that it had pre-fork. The second one can, = as it has 111% of the pre-fork capacity. This makes the 1 MB branch much = less usable than the 2 MB branch, which in turn causes the market value = of newly minted coins on that branch to fall, which in turn causes = miners to switch to the more profitable 2MB branch. This exacerbates the = usability difference, which exacerbates the price difference, etc. = Having two competing chains with equal hashrate using the same PoW = function and nearly equal features is not a stable state. Positive = feedback loops exist to make the vast majority of the users and the = hashrate join one side. Basically, any miners who stick to the minority branch are going to lose = a lot of money. --Apple-Mail=_285C1A46-7DBC-46CA-BE9B-3EB7FC22C651 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Feb 7, 2016, at 7:19 AM, Anthony = Towns via bitcoin-dev <bitcoin-dev@lists.li= nuxfoundation.org> wrote:

The stated reasoning for 75% versus 95% is "because it = gives "veto power"
to a single big solo miner or mining pool". But if a 20% = miner wants to
"veto" the upgrade, with a 75% threshold, they could = instead simply use
their hashpower to vote for an upgrade, but then not mine = anything on
the new chain. At that point there'd be as little as 55% = mining the new
2MB chain with 45% of hashpower remaining on the old chain. = That'd be 18
minute blocks versus 22 minute blocks, which doesn't seem = like much of
a difference in practice, and at that point hashpower could = plausibly
end up switching almost entirely back to the original = consensus rules
prior to the grace period = ending.

Keep in mind = that within a single difficulty adjustment period, the difficulty of = mining a block on either chain will be identical. Even if the value of a = 1MB branch coin is $100 and the hashrate on the 1 MB branch is 100 PH/s, = and the value of a 2 MB branch coin is $101 and the hashrate on the 2 MB = branch is 1000 PH/s, the rational thing for a miner to do (for the first = adjustment period) is to mine on the 2 MB branch, because the miner = would earn 1% more on that branch.

So you're = assuming that 25% of the hashrate chooses to remain on the minority = version during the grace period, and that 20% chooses to switch back to = the minority side. The fork happens. One branch has 1 MB blocks every 22 = minutes, and the other branch has 2 MB blocks every 18 minutes. The = first branch cannot handle the pre-fork transaction volume, as it only = has 45% of the capacity that it had pre-fork. The second one can, as it = has 111% of the pre-fork capacity. This makes the 1 MB branch much less = usable than the 2 MB branch, which in turn causes the market value of = newly minted coins on that branch to fall, which in turn causes miners = to switch to the more profitable 2MB branch. This exacerbates the = usability difference, which exacerbates the price difference, etc. = Having two competing chains with equal hashrate using the same PoW = function and nearly equal features is not a stable state. Positive = feedback loops exist to make the vast majority of the users and the = hashrate join one side.

Basically, any miners = who stick to the minority branch are going to lose a lot of = money.
= --Apple-Mail=_285C1A46-7DBC-46CA-BE9B-3EB7FC22C651-- --Apple-Mail=_55B03182-8517-4609-A516-4D99910E6055 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWt3qPAAoJEIEuMk4MG0P1RlAH/2Fw9718jV9uFMNoATOmDGkw MXX5yhvm2NxRvZ1W3Z3IsJlbfFry1CNHeAHqRuWaMZUJ5Jepqbinrl4pbqcSpQF8 Q/N+EnfcjhEgZTfhovhI9cbmkM1oAhS+snXtEJltRXYwBqi8ImNyaEzhuWi4mVvc pdiVIMATn5/wOM8WHirXV54DUTbWWP6xbf38HQUy8cuDKMEjpRXne8wZlnV9uLts FxJ+nl2qj+gy1SEK4ivn/q3+hiqOBZBEu2gB/Jy38BqN2FCZSq7cF1M0K97TkyAl Gk10hKNou08CDlr18R8EgHYWfBcYURAgVYpGwF0FdQQCF5yX3b9CgqfjW0ASnQs= =wBky -----END PGP SIGNATURE----- --Apple-Mail=_55B03182-8517-4609-A516-4D99910E6055--