From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yz43E-0003vK-F6 for bitcoin-development@lists.sourceforge.net; Sun, 31 May 2015 14:17:20 +0000 Received-SPF: softfail (sog-mx-1.v43.ch3.sourceforge.com: transitioning domain of hashingit.com does not designate 89.145.69.228 as permitted sender) client-ip=89.145.69.228; envelope-from=dave@hashingit.com; helo=heron.directrouter.co.uk; Received: from heron.directrouter.co.uk ([89.145.69.228]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Yz43C-0005lp-Dc for bitcoin-development@lists.sourceforge.net; Sun, 31 May 2015 14:17:20 +0000 Received: from host109-152-68-249.range109-152.btcentralplus.com ([109.152.68.249]:1165 helo=[192.168.1.82]) by heron.directrouter.co.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1Yz435-001GyJ-H5; Sun, 31 May 2015 14:17:11 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_88D58663-F638-4D02-8E15-8B3F178C8EFB" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Dave Hudson In-Reply-To: Date: Sun, 31 May 2015 15:17:10 +0100 Message-Id: <91BD6826-3A60-4DD6-807A-2DCEDB00CE87@hashingit.com> References: <554BE0E1.5030001@bluematt.me> To: Gavin Andresen X-Mailer: Apple Mail (2.2098) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - heron.directrouter.co.uk X-AntiAbuse: Original Domain - lists.sourceforge.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hashingit.com X-Get-Message-Sender-Via: heron.directrouter.co.uk: authenticated_id: dave@hashingit.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 2.0 (++) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1Yz43C-0005lp-Dc Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2015 14:17:20 -0000 --Apple-Mail=_88D58663-F638-4D02-8E15-8B3F178C8EFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 31 May 2015, at 13:52, Gavin Andresen = wrote: >=20 > On Sat, May 30, 2015 at 9:31 PM, Chun Wang <1240902@gmail.com = > wrote: > If someone propagate a 20MB block, it will take at best 6 seconds for > us to receive to verify it at current configuration, result of one > percent orphan rate increase. >=20 > That orphan rate increase will go to whoever is producing the 20MB = blocks, NOT you. There's an interesting incentives question if the mining fees ever = become large enough to be interesting. Given two potential blocks on = which to build then for the best interests of the system we'd want = miners to select the block that confirmed the largest number of = transactions since that puts less pressure on the network later. This is = at odds with the incentives for our would-be block maker though because = the incentive for mining would be to use whichever block left the = largest potential fees available; that's generally going to be the = smaller of the two. This, of course, only gets worse as the block reward reduces and fees = become the dominant way for miners to be paid (and my hypothesis that = eventually this could lead to miners trying to deliberately orphan = earlier blocks to "steal" fees because the fixed block reward is no = longer the dominant part of their income). When coupled with the block propagation delay problem increasing the = risk of orphan races I'm pretty sure that this actually leads to miners = having an incentive to continually mine smaller blocks, and that's aside = from the question of whether smaller blocks will push up fees (which = also benefits miners).=20 Cheers, Dave --Apple-Mail=_88D58663-F638-4D02-8E15-8B3F178C8EFB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 31 May 2015, at 13:52, Gavin Andresen <gavinandresen@gmail.com> wrote:

On Sat, = May 30, 2015 at 9:31 PM, Chun Wang <1240902@gmail.com> wrote:
If someone propagate a 20MB block, it will take at best 6 seconds for
us to receive to verify it at current configuration, result of one
percent orphan rate increase.

That orphan rate increase will go to = whoever is producing the 20MB blocks, NOT = you.

There's an interesting incentives question if the = mining fees ever become large enough to be interesting. Given two = potential blocks on which to build then for the best interests of the = system we'd want miners to select the block that confirmed the largest = number of transactions since that puts less pressure on the network = later. This is at odds with the incentives for our would-be block maker = though because the incentive for mining would be to use whichever block = left the largest potential fees available; that's generally going to be = the smaller of the two.

This, of = course, only gets worse as the block reward reduces and fees become the = dominant way for miners to be paid (and my hypothesis that eventually = this could lead to miners trying to deliberately orphan earlier blocks = to "steal" fees because the fixed block reward is no longer the dominant = part of their income).

When coupled = with the block propagation delay problem increasing the risk of orphan = races I'm pretty sure that this actually leads to miners having an = incentive to continually mine smaller blocks, and that's aside from the = question of whether smaller blocks will push up fees (which also = benefits miners). 


Cheers,
Dave


= --Apple-Mail=_88D58663-F638-4D02-8E15-8B3F178C8EFB--