Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6CEAB486 for ; Wed, 5 Aug 2015 22:15:45 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2CDC5235 for ; Wed, 5 Aug 2015 22:15:44 +0000 (UTC) Received: from [10.192.6.201] ([77.158.42.68]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MLfH9-1ZMpix3tHX-000uoe; Thu, 06 Aug 2015 00:15:41 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_067B9CA0-8438-495F-88B4-D7031AF163B5" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Peter R In-Reply-To: <3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com> Date: Wed, 5 Aug 2015 15:15:43 -0700 Message-Id: <7F9283D5-5F0F-4318-BE64-A1C20A5B7606@gmx.com> References: <1438640036.2828.0.camel@auspira.com> <3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com> To: Dave Hudson X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:NzdZejPgZlonnWG6GtnRCaJaAb7CByYOoP7nOhpQeJcdpUzjHIH hmTSpCa95k+4IJGzA/7Aj1Wl/gXcCGenXPiIu0CmhoPuK6wx+St1893DC+ho0t7PBG5g0GN HBzbPYOvIfi7NUAwLg/L5jeKfhHtc5DY6CiJGu5ht2UOnOdfuM/rcdkYvY/d1Mf28dz7+KV W284nf7yYeZZDLvBY5snQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:nIIefz3xfrs=:/1lYiiKM5HbAKgPoYjY8Ud H+afoflPBR4xfVz8c68lyy4k7VUmKTGBr4v2Lqtau1nIzzaANt6cc3OxVaAItrLalcNZyFCVL Zb9cPq27E9ga4zmVx/s0aUnoixlQxqj3/nhiIfFtPwD9ccsBhkqCet6yQhfA0a6TVoHpjZuL9 QIfJup5ijn6VDDmImi4F8ZxvxlB7BEn+lKjHWqVbTm3mEQxVvkKw/VVqnZVmzazs1A3dXaof8 s+81yJ24qqRiF5NMxF2W/qAuxEyTxuMDDFJgwzrtSPRhsC/YrjVJ7mLhJGsm+091evT01m1xA 2GeFBaeWcFB6WPuMPOtdyp7ClS6KmXI88bq9/DfOcfJb8ygzYgeNyLLfMOJi/qcwa2qX8X0P/ QPUtC5PoVraV7Qt27i1VjcmGIfC7+rSBwS+ESpc/kurEyTMdbRdZIteUTj+I+kqCAeXR7pds7 8s0uf2ynqcDqqXkGs7A5IYSsmVRmG11JFteaWJlE4P/LiptTomXVGkgy8EWbXFqWyfSk4UyKN 4RbW4snONYD7thGmEuthtPz3whLAEBDkcvmM66f8pb5s3iEOkiKGAt5I11sLX2mXc/9hpLGTV KchjY4EgLmZBACjG5SjkrLm20O+FPOULIB9fn3wPMebEc2oh8bG0kEHRt2LKYKS5X+HX3YVYb TbVYGhCgTpBqsLTsLgqTrNx9uVJOQFfcOdMirypvmqW+n3nh+349/5XWF0ChWYgQ5I3U= X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, 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 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: Wed, 05 Aug 2015 22:15:45 -0000 --Apple-Mail=_067B9CA0-8438-495F-88B4-D7031AF163B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Dave, Thank you for the feedback regarding my paper. =20 > 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. With the benefit of hindsight, I think the paper would be stronger if it = also analyzed how the model changes (or doesn't) if we assume zero = propagation impedance for intra-miner communication, as you suggested = (the "you don't orphan your own blocks" idea). Note that the paper did = briefly discuss miner-dependent propagation times in the second = paragraph of page 9 and in note 13. =20 > In a degenerate case a 100% pool has no orphaned blocks. Agreed. In this case there's no information to communicate (since the = miner has no peers) and so the Shannon-Hartley limit doesn't apply. My = model makes no attempt to explain this case. =20 > 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'd like to explore this in more detail. Although a miner may not = orphan his own block, by building on his own block he may now orphan two = blocks in a row. At some point, his solution or solutions must be = communicated to his peers. And if there's information about the = transactions in his blocks to communicate, I think there's a cost = associated with that. It's an interesting problem and I'd like to = continue working on it. =20 > 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. It will be interesting to see. I suspect that the main result that "a = healthy fee market exists" will still hold (assuming of course that a = single miner with >50% of the hash power isn't acting maliciously). = Whether miners with larger value of h/H have a profit advantage, I'm not = sure (but that was outside the scope of the paper anyways). =20 Best regards, Peter >> 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 >=20 --Apple-Mail=_067B9CA0-8438-495F-88B4-D7031AF163B5 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.

With the benefit of = hindsight, I think the paper would be stronger if it also analyzed how = the model changes (or doesn't) if we assume zero propagation impedance = for intra-miner communication, as you suggested (the "you don't orphan = your own blocks" idea).  Note that the paper did briefly = discuss miner-dependent propagation times in the second paragraph of = page 9 and in note 13.  

In a degenerate case a 100% pool has no orphaned blocks. =

Agreed.  In this case = there's no information to communicate (since the miner has no peers) and = so the Shannon-Hartley limit doesn't apply.  My model makes no = attempt to explain this case.  

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'd like to explore this in = more detail.  Although a miner may not orphan his own block, by = building on his own block he may now orphan two blocks in a row. =  At some point, his solution or solutions must be communicated to = his peers.  And if there's information about the transactions in = his blocks to communicate, I think there's a cost associated with that. =  It's an interesting problem and I'd like to continue working on = it.  

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.

It = will be interesting to see.  I suspect that the main result that "a = healthy fee market exists" will still hold (assuming of course that a = single miner with >50% of the hash power isn't acting maliciously). =  Whether miners with larger value of h/H have a profit advantage, = I'm not sure (but that was outside the scope of the paper anyways). =  

Best = regards,
Peter



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:

https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-E= xists-Without-a-Block-Size-Limit

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
ht= tps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


= --Apple-Mail=_067B9CA0-8438-495F-88B4-D7031AF163B5--