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 9900D9B for ; Tue, 4 Aug 2015 18:41:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from heron.directrouter.co.uk (heron.directrouter.co.uk [89.145.69.228]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C8A3811B for ; Tue, 4 Aug 2015 18:41:57 +0000 (UTC) Received: from [207.140.24.78] (port=55589 helo=[10.0.0.190]) by heron.directrouter.co.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1ZMh9v-001vkW-G5; Tue, 04 Aug 2015 18:41:55 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_49EA117C-CFBD-4894-AFBE-B0D55361B050" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Dave Hudson In-Reply-To: Date: Tue, 4 Aug 2015 11:41:53 -0700 Message-Id: <3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com> References: <1438640036.2828.0.camel@auspira.com> To: Peter R X-Mailer: Apple Mail (2.2102) 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.linuxfoundation.org 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-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE 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 Subject: Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests 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: Tue, 04 Aug 2015 18:41:58 -0000 --Apple-Mail=_49EA117C-CFBD-4894-AFBE-B0D55361B050 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The paper is nicely done, but I'm concerned that there's a real problem = with equation 4. The orphan rate is not just a function of time; it's = also a function of the block maker's proportion of the network hash = rate. Fundamentally a block maker (pool or aggregation of pools) does = not orphan its own blocks. In a degenerate case a 100% pool has no = orphaned blocks. Consider that a 1% miner must assume a greater risk = from orphaning than, say, a pool with 25%, or worse 40% of the hash = rate. I suspect this may well change some of the conclusions as larger block = makers will definitely be able to create larger blocks than their = smaller counterparts. Cheers, Dave > On 3 Aug 2015, at 23:40, Peter R via bitcoin-dev = wrote: >=20 > Dear Bitcoin-Dev Mailing list, >=20 > I=92d like to share a research paper I=92ve recently completed titled = =93A Transaction Fee Market Exists Without a Block Size Limit.=94 In = addition to presenting some useful charts such as the cost to produce = large spam blocks, I think the paper convincingly demonstrates that, due = to the orphaning cost, a block size limit is not necessary to ensure a = functioning fee market. =20 >=20 > The paper does not argue that a block size limit is unnecessary in = general, and in fact brings up questions related to mining cartels and = the size of the UTXO set. =20 >=20 > It can be downloaded in PDF format here: >=20 > https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf = >=20 > Or viewed with a web-browser here: >=20 > = https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-Exists-Witho= ut-a-Block-Size-Limit = >=20 > Abstract. This paper shows how a rational Bitcoin miner should select = transactions from his node=92s mempool, when creating a new block, in = order to maximize his profit in the absence of a block size limit. To = show this, the paper introduces the block space supply curve and the = mempool demand curve. The former describes the cost for a miner to = supply block space by accounting for orphaning risk. The latter = represents the fees offered by the transactions in mempool, and is = expressed versus the minimum block size required to claim a given = portion of the fees. The paper explains how the supply and demand = curves from classical economics are related to the derivatives of these = two curves, and proves that producing the quantity of block space = indicated by their intersection point maximizes the miner=92s profit. = The paper then shows that an unhealthy fee market=97where miners are = incentivized to produce arbitrarily large blocks=97cannot exist since it = requires communicating information at an arbitrarily fast rate. The = paper concludes by considering the conditions under which a rational = miner would produce big, small or empty blocks, and by estimating the = cost of a spam attack. =20 >=20 > Best regards, > Peter > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_49EA117C-CFBD-4894-AFBE-B0D55361B050 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
The paper is nicely done, but I'm concerned = that there's a real problem with equation 4. The orphan rate is not just = a function of time; it's also a function of the block maker's proportion = of the network hash rate. Fundamentally a block maker (pool or = aggregation of pools) does not orphan its own blocks. In a degenerate = case a 100% pool has no orphaned blocks. Consider that a 1% miner must = assume a greater risk from orphaning than, say, a pool with 25%, or = worse 40% of the hash rate.

I suspect this may well change some of the conclusions as = larger block makers will definitely be able to create larger blocks than = their smaller counterparts.


Cheers,
Dave


On = 3 Aug 2015, at 23:40, Peter R via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Dear = Bitcoin-Dev Mailing list,

I=92d like to share a research paper I=92ve recently = completed titled =93A Transaction Fee Market Exists Without a Block Size = Limit.=94  In addition to presenting some useful charts such as the = cost to produce large spam blocks, I think the paper convincingly = demonstrates that, due to the orphaning cost, a block size limit is not = necessary to ensure a functioning fee market.  

The paper does not argue = that a block size limit is unnecessary in general, and in fact brings up = questions related to mining cartels and the size of the UTXO set. =   

It = can be downloaded in PDF format here:

https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf<= /div>

Or viewed with = a web-browser here:


Abstract.  This = paper shows how a rational Bitcoin miner should select transactions from = his node=92s mempool, when creating a new block, in order to maximize = his profit in the absence of a block size limit. To show this, the paper = introduces the block space supply curve and the mempool demand curve. =  The former describes the cost for a miner to supply block space by = accounting for orphaning risk.  The latter represents the fees = offered by the transactions in mempool, and is expressed versus the = minimum block size required to claim a given portion of the fees. =  The paper explains how the supply and demand curves from classical = economics are related to the derivatives of these two curves, and proves = that producing the quantity of block space indicated by their = intersection point maximizes the miner=92s profit.  The paper then = shows that an unhealthy fee market=97where miners are incentivized to = produce arbitrarily large blocks=97cannot exist since it requires = communicating information at an arbitrarily fast rate.  The paper = concludes by considering the conditions under which a rational miner = would produce big, small or empty blocks, and by estimating the cost of = a spam attack.  

Best regards,
Peter
______________________________________________= _
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">

= --Apple-Mail=_49EA117C-CFBD-4894-AFBE-B0D55361B050--