Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 73145102A for ; Sun, 7 Feb 2016 17:24:10 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E02632F for ; Sun, 7 Feb 2016 17:24:08 +0000 (UTC) Received: from 119246245241.ctinets.com ([119.246.245.241]:51099 helo=2012R2) by server47.web-hosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86) (envelope-from ) id 1aST4A-000f1a-JY; Sun, 07 Feb 2016 12:24:07 -0500 From: To: "'Jonathan Toomim'" , "'Anthony Towns'" References: <1804222.7gVHPiWqto@kiwi> <201602062046.40193.luke@dashjr.org> <20160207151927.GA14750@sapphire.erisian.com.au> <57C403C6-2680-4C3D-8860-E33A525A99D4@toom.im> In-Reply-To: <57C403C6-2680-4C3D-8860-E33A525A99D4@toom.im> Date: Mon, 8 Feb 2016 01:24:25 +0800 Message-ID: <22e401d161cc$66af6b50$340e41f0$@xbt.hk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_22E5_01D1620F.74D431F0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH4jF1VS2oYOn83eis4ezLyrErEQAKPS4/SAWOghZICnxtKJgMInfBgAnCdUFECASrdP55iGSxg Content-Language: en-hk X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server47.web-hosting.com X-AntiAbuse: Original Domain - lists.linuxfoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - xbt.hk X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id: jl2012@xbt.hk X-Authenticated-Sender: server47.web-hosting.com: jl2012@xbt.hk X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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:24:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_22E5_01D1620F.74D431F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You are making a very na=EFve assumption that miners are just looking = for profit for the next second. Instead, they would try to optimize their = short term and long term ROI. It is also well known that some miners would = mine at a loss, even not for ideological reasons, if they believe that their = action is beneficial to the network and will provide long term ROI. It happened after the last halving in 2012. Without any immediate price = appreciation, the hashing rate decreased by only less than 10% =20 http://bitcoin.sipa.be/speed-ever.png =20 =20 From: bitcoin-dev-bounces@lists.linuxfoundation.org [mailto:bitcoin-dev-bounces@lists.linuxfoundation.org] On Behalf Of = Jonathan Toomim via bitcoin-dev Sent: Monday, 8 February, 2016 01:11 To: Anthony Towns Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes =20 =20 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. =20 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. =20 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. =20 Basically, any miners who stick to the minority branch are going to lose = a lot of money. =20 =20 ------=_NextPart_000_22E5_01D1620F.74D431F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

You are making a very na=EFve assumption that miners are just looking = for profit for the next second. Instead, they would try to optimize = their short term and long term ROI. It is also well known that some = miners would mine at a loss, even not for ideological reasons, if they = believe that their action is beneficial to the network and will provide = long term ROI. It happened after the last halving in 2012. Without any = immediate price appreciation, the hashing rate decreased by only less = than 10%

 

http://bitcoin.sipa.be/spe= ed-ever.png

 

 

From:<= /b> = bitcoin-dev-bounces@lists.linuxfoundation.org = [mailto:bitcoin-dev-bounces@lists.linuxfoundation.org] On Behalf Of = Jonathan Toomim via bitcoin-dev
Sent: Monday, 8 February, = 2016 01:11
To: Anthony Towns = <aj@erisian.com.au>
Cc: = bitcoin-dev@lists.linuxfoundation.org
Subject: Re: = [bitcoin-dev] BIP proposal: Increase block size limit to 2 = megabytes

 

 

On = Feb 7, 2016, at 7:19 AM, Anthony Towns via bitcoin-dev <bitcoin-dev@lists.l= inuxfoundation.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.

 

 

------=_NextPart_000_22E5_01D1620F.74D431F0--