Or viewed with a web-browser here:

https://www.scribd.com/doc/273443462/A-Tran= saction-Fee-Market-Exists-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

= --Apple-Mail=_9E306D4B-96CA-4CDF-92DE-3A900188C49D-- 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 DFD3C7D for ; Tue, 4 Aug 2015 14:22:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E0B2B1C5 for ; Tue, 4 Aug 2015 14:22:20 +0000 (UTC) Received: by wibud3 with SMTP id ud3so179548903wib.1 for ; Tue, 04 Aug 2015 07:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hrfvIWCs2SvV2B/fKIRKc+TfDLpJCJGTWfHJBQOeTjA=; b=kbB1xKetM2i/tkVGzOngaLN6JjKU9m5HdFuqZ7D4kwSzEHUEMQtfrLQWfW+GudqwKF OT4BBELZ4yCJb/wzOO//eNrKdYpOIc2Wl1Vkdm27h2V8nfRiNUhFFR2MubOWxdITS5oz 1BO94vaAUWT1ByNIsybloxnTt+bO/UYjS7RQulfBdGD1WRKST/PpCh0vnxYXtq5jOXmj rPpolrJZ3rhOyuG1B12G7/pVfwIiPQ2bMYAa8w5eEf8IZlmNkdwCWDW0vzX3aeTIRnFC Ly5tEU5iZuRZJq2JXInGsOPBuuaKtVlSlyZz/exb7MJWgHcdofd0oVwnv+ozUm8x5CQ9 M1HA== MIME-Version: 1.0 X-Received: by 10.180.96.1 with SMTP id do1mr7963315wib.37.1438698139680; Tue, 04 Aug 2015 07:22:19 -0700 (PDT) Sender: anthony.j.towns@gmail.com Received: by 10.28.143.141 with HTTP; Tue, 4 Aug 2015 07:22:19 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Aug 2015 00:22:19 +1000 X-Google-Sender-Auth: CXVMCeBkxW26GJYTc7eiWFHLyP4 Message-ID: From: Anthony Towns To: Gavin Andresen Content-Type: multipart/alternative; boundary=f46d04447fc58e0a37051c7d0385 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FROM,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 Subject: Re: [bitcoin-dev] Eli Dourado on "governance" 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 14:22:22 -0000 --f46d04447fc58e0a37051c7d0385 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4 August 2015 at 01:22, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > And the preliminary results of using a prediction market to try to wrestl= e > with the tough tradeoffs looks roughly correct to me, too: > https://blocksizedebate.com/ > =E2=80=8BThe scicast prediction market is shutdown atm (since early July?) = so those numbers aren't live. But... Network hash rate 3,255.17 PH/s (same block size) 5,032.64 PH/s (block size increase) 4,969.68 PH/s (no replace-by-fee) 3,132.09 PH/s (replace-by-fee) Those numbers seem completely implausible: that's ~2.9-3.6 doublings of the current hashrate (< 400PH/s) in 17 months, when it's taken 12 months for the last doubling, and there's a block reward reduction due in that period too. (That might've been a reasonable prediction sometime in the past year, when doublings were slowing from once every ~45 days to once a year; it just doesn't seem a supportable prediction now) That the PH/s rate is higher with bigger blocks is surprising, but given that site also predicts USD/BTC will be $280 with no change but $555 with bigger blocks, so I assume that difference is mostly due to price. Also, 12.5btc at $555 each is about 23 btc at $300 each, so if that price increase is realistic, it would compensate for almost all of the block reward reduction. Daily transaction volume 168,438.22 tx/day (same block size) 193,773.08 tx/day (block size increase) 192,603.80 tx/day (no replace-by-fee) 168,406.73 tx/day (replace-by-fee) That's only a 15% increase in transaction volume due to the block size increase; I would have expected more? 168k-194k tx/day is also only a 30%-50% increase in transaction volume from 130k tx/day currently. If that's really the case, then a 1.5MB-2MB max block size would probably be enough for the next two years... (Predicting that the node count will drop from ~5000 to ~1200 due to increasing block sizes seems quite an indictment as far as centralisation risks go; but given I'm not that convinced by the other predictions, I'm not sure I want to give that much weight to that one either) Cheers, aj --=20 Anthony Towns --f46d04447fc58e0a37051c7d0385 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 4 August 2015 at 01:22, = Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

And the preliminary results of using a predictio= n market to try to wrestle with the tough tradeoffs looks roughly correct t= o me, too:
=C2=A0 =C2=A0https://blocksizedebate.com/

=E2=80=8BThe scicast prediction market is shutdown atm (since early J= uly?) so those numbers aren't live. But...

Network hash rate

<= div class=3D"gmail_default"> 3,255.17 PH/s =C2=A0(same block size)

5,032.64 PH/s =C2= =A0(block size increase)

4,969= .68 PH/s =C2=A0(no replace-by-fee)

3,132.09 PH/s =C2=A0(replace-by-fee)

Those numbers seem completely i= mplausible: that's ~2.9-3.6 doublings of the current hashrate (< 400= PH/s) in 17 months, when it's taken 12 months for the last doubling, an= d there's a block reward reduction due in that period too. (That might&= #39;ve been a reasonable prediction sometime in the past year, when doublin= gs were slowing from once every ~45 days to once a year; it just doesn'= t seem a supportable prediction now)

<= font face=3D"monospace">That the PH/s rate is higher with bigger blocks is = surprising, but given that site also predicts USD/BTC will be $280 with no = change but $555 with bigger blocks, so I assume that difference is mostly d= ue to price. Also, 12.5btc at $555 each is about 23 btc at $300 each, so if= that price increase is realistic, it would compensate for almost all of th= e block reward reduction.

Daily= transaction volume

168,438.22 tx/day =C2=A0(same block size)

193,773.08 tx/day =C2=A0(block size increase)

192,603.80 tx/day =C2=A0(no replace-by-fee)

168,406.73 = tx/day =C2=A0(replace-by-fee)

That's only a 15% increase in transaction volume due to the bl= ock size increase; I would have expected more? 168k-194k tx/day is also onl= y a 30%-50% increase in transaction volume from 130k tx/day currently. If t= hat's really the case, then a 1.5MB-2MB max block size would probably b= e enough for the next two years...

(Predic= ting that the node count will drop from ~5000 to ~1200 due to increasing bl= ock sizes seems quite an indictment as far as centralisation risks go; but = given I'm not that convinced by the other predictions, I'm not sure= I want to give that much weight to that one either)

Cheers,

Anthony Towns <aj@erisian.com.au>

--f46d04447fc58e0a37051c7d0385-- 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 B758C4D3 for ; Tue, 4 Aug 2015 18:28:39 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from peacecow.phauna.org (phauna.org [208.82.98.102]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C80C713A for ; Tue, 4 Aug 2015 18:28:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=phauna.org; s=apricot; h=Message-ID:CC:To:Date:From:Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To; bh=44NztW2UG4Jc6/EOr42vhps8iy+O2li1nwajM3YmY2Y=; b=E84nrnq9rQJuakmVqqTB5mSuoGQhCwc1oDBmtJ2how1e9Vsj9WpsKzklk/VK1YM5bBjEzVXzqs+otgr4dbhRa5kUgksp3WyuvpYwnIXjv3H2xMCOG1oXtrpnn15jbgEB0wQ1v4RmoN/pEbrM5EhiFb4XlBjgXzbrJi+sI6CMQVA=; Received: from [172.56.36.189] (helo=[33.32.24.233]) by peacecow.phauna.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1ZMgx1-00069U-HH; Tue, 04 Aug 2015 18:28:37 +0000 User-Agent: K-9 Mail for Android In-Reply-To: References:

MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----TQNWFJVE964X9XAN01O7GM9P9CYDFL" Content-Transfer-Encoding: 7bit From: Owen Date: Tue, 04 Aug 2015 14:28:27 -0400 To: Anthony Towns , Anthony Towns via bitcoin-dev , Gavin Andresen Message-ID: <5A323AB6-914C-4FF5-9FC2-AB8E02C69F93@phauna.org> X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam_report: Spam detection software, running on the system "peacecow.phauna.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Given there is no money at stake in these prediction games, it is no surprise that the results are implausible. On August 4, 2015 10:22:19 AM EDT, Anthony Towns via bitcoin-dev wrote: >On 4 August 2015 at 01:22, Gavin Andresen via bitcoin-dev < >bitcoin-dev@lists.linuxfoundation.org> wrote: > >> And the preliminary results of using a prediction market to try to >wrestle >> with the tough tradeoffs looks roughly correct to me, too: >> https://blocksizedebate.com/ >> > >The scicast prediction market is shutdown atm (since early July?) so >those >numbers aren't live. But... > >Network hash rate >3,255.17 PH/s (same block size) >5,032.64 PH/s (block size increase) > >4,969.68 PH/s (no replace-by-fee) >3,132.09 PH/s (replace-by-fee) > >Those numbers seem completely implausible: that's ~2.9-3.6 doublings of >the >current hashrate (< 400PH/s) in 17 months, when it's taken 12 months >for >the last doubling, and there's a block reward reduction due in that >period >too. (That might've been a reasonable prediction sometime in the past >year, >when doublings were slowing from once every ~45 days to once a year; it >just doesn't seem a supportable prediction now) > >That the PH/s rate is higher with bigger blocks is surprising, but >given >that site also predicts USD/BTC will be $280 with no change but $555 >with >bigger blocks, so I assume that difference is mostly due to price. >Also, >12.5btc at $555 each is about 23 btc at $300 each, so if that price >increase is realistic, it would compensate for almost all of the block >reward reduction. > >Daily transaction volume >168,438.22 tx/day (same block size) >193,773.08 tx/day (block size increase) > >192,603.80 tx/day (no replace-by-fee) >168,406.73 tx/day (replace-by-fee) > >That's only a 15% increase in transaction volume due to the block size >increase; I would have expected more? 168k-194k tx/day is also only a >30%-50% increase in transaction volume from 130k tx/day currently. If >that's really the case, then a 1.5MB-2MB max block size would probably >be >enough for the next two years... > >(Predicting that the node count will drop from [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RP_MATCHES_RCVD 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] Eli Dourado on "governance" 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:28:39 -0000 ------TQNWFJVE964X9XAN01O7GM9P9CYDFL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Given there is no money at stake in these prediction games, it is no surpri= se that the results are implausible=2E On August 4, 2015 10:22:19 AM EDT, Anthony Towns via bitcoin-dev wrote: >On 4 August 2015 at 01:22, Gavin Andresen via bitcoin-dev < >bitcoin-dev@lists=2Elinuxfoundation=2Eorg> wrote: > >> And the preliminary results of using a prediction market to try to >wrestle >> with the tough tradeoffs looks roughly correct to me, too: >> https://blocksizedebate=2Ecom/ >> > >=E2=80=8BThe scicast prediction market is shutdown atm (since early July?= ) so >those >numbers aren't live=2E But=2E=2E=2E > >Network hash rate >3,255=2E17 PH/s (same block size) >5,032=2E64 PH/s (block size increase) > >4,969=2E68 PH/s (no replace-by-fee) >3,132=2E09 PH/s (replace-by-fee) > >Those numbers seem completely implausible: that's ~2=2E9-3=2E6 doublings = of >the >current hashrate (< 400PH/s) in 17 months, when it's taken 12 months >for >the last doubling, and there's a block reward reduction due in that >period >too=2E (That might've been a reasonable prediction sometime in the past >year, >when doublings were slowing from once every ~45 days to once a year; it >just doesn't seem a supportable prediction now) > >That the PH/s rate is higher with bigger blocks is surprising, but >given >that site also predicts USD/BTC will be $280 with no change but $555 >with >bigger blocks, so I assume that difference is mostly due to price=2E >Also, >12=2E5btc at $555 each is about 23 btc at $300 each, so if that price >increase is realistic, it would compensate for almost all of the block >reward reduction=2E > >Daily transaction volume >168,438=2E22 tx/day (same block size) >193,773=2E08 tx/day (block size increase) > >192,603=2E80 tx/day (no replace-by-fee) >168,406=2E73 tx/day (replace-by-fee) > >That's only a 15% increase in transaction volume due to the block size >increase; I would have expected more? 168k-194k tx/day is also only a >30%-50% increase in transaction volume from 130k tx/day currently=2E If >that's really the case, then a 1=2E5MB-2MB max block size would probably >be >enough for the next two years=2E=2E=2E > >(Predicting that the node count will drop from ~5000 to ~1200 due to >increasing block sizes seems quite an indictment as far as >centralisation >risks go; but given I'm not that convinced by the other predictions, >I'm >not sure I want to give that much weight to that one either) > >Cheers, >aj > >--=20 >Anthony Towns > > >------------------------------------------------------------------------ > >_______________________________________________ >bitcoin-dev mailing list >bitcoin-dev@lists=2Elinuxfoundation=2Eorg >https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev ------TQNWFJVE964X9XAN01O7GM9P9CYDFL Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Given there is no money at stake in these predicti= on games, it is no surprise that the results are implausible=2E

On August 4, 2015 10:22:19 AM EDT, Anthony Towns via= bitcoin-dev <bitcoin-dev@lists=2Elinuxfoundation=2Eorg> wrote:

On 4 August 2015 at 01:22,= Gavin Andresen via bitcoin-dev <bitcoin-dev@lists=2Elinuxfoundation=2Eorg&= gt; wrote:
=

And the preliminary results of usin= g a prediction market to try to wrestle with the tough tradeoffs looks roug= hly correct to me, too:
=C2=A0 =C2=A0https://blocksizedebate=2Ecom/

=E2=80=8BThe scicast prediction market is shutdo=
wn atm (since early July?) so those numbers aren't live=2E But=2E=2E=2E=

Netw=
ork hash rate
 3,255=2E17 PH/s =C2=A0(same block size)=
 5,032=2E64 PH/s =C2=A0(block size increase)

 4,969=2E68 PH/s =C2=A0(no replace-by-fee=
)
<=
span class=3D"Apple-tab-span" style=3D"white-space:pre"> 3,132=2E09 =
PH/s =C2=A0(replace-by-fee)

Those numbers seem completely implausible: that's ~2=
=2E9-3=2E6 doublings of the current hashrate (< 400PH/s) in 17 months, w=
hen it's taken 12 months for the last doubling, and there's a block=
 reward reduction due in that period too=2E (That might've been a reaso=
nable prediction sometime in the past year, when doublings were slowing fro=
m once every ~45 days to once a year; it just doesn't seem a supportabl=
e prediction now)

That the PH/s rate is higher with bigger blocks is surprising, but g=
iven that site also predicts USD/BTC will be $280 with no change but $555 w=
ith bigger blocks, so I assume that difference is mostly due to price=2E Al=
so, 12=2E5btc at $555 each is about 23 btc at $300 each, so if that price i=
ncrease is realistic, it would compensate for almost all of the block rewar=
d reduction=2E

Daily transact=
ion volume
 168,438=
=2E22 tx/day =C2=A0(same block size)
 193,773=2E08 tx/day =C2=A0(block size increase)
 192,603=2E80 tx/day =C2=A0(no replace-by-fee)
 168,406=2E7=
3 tx/day =C2=A0(replace-by-fee)

That's only a 15% increase in transaction volume due to =
the block size increase; I would have expected more? 168k-194k tx/day is al=
so only a 30%-50% increase in transaction volume from 130k tx/day currently=
=2E If that's really the case, then a 1=2E5MB-2MB max block size would =
probably be enough for the next two years=2E=2E=2E

(Predicting that the node count will drop from ~5000 to ~1200 du=
e to increasing block sizes seems quite an indictment as far as centralisat=
ion risks go; but given I'm not that convinced by the other predictions=
, I'm not sure I want to give that much weight to that one either)

Cheers,
=
aj
=

-- 
Anthony Town=
s <aj@erisian=
=2Ecom=2Eau>



bitcoin-dev mailing listbitcoin-dev@lists=2Elinuxfoundation=2Eorg
https://lists=2Elinu=
xfoundation=2Eorg/mailman/listinfo/bitcoin-dev

------TQNWFJVE964X9XAN01O7GM9P9CYDFL-- 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:

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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">

= --Apple-Mail=_49EA117C-CFBD-4894-AFBE-B0D55361B050-- 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 2F49E7F for ; Tue, 4 Aug 2015 21:18:44 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149095.authsmtp.com (outmail149095.authsmtp.com [62.13.149.95]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 2260CEA for ; Tue, 4 Aug 2015 21:18:42 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t74LIXVo033246; Tue, 4 Aug 2015 22:18:33 +0100 (BST) Received: from [25.114.14.211] ([24.114.75.173]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t74LIOPY015153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Aug 2015 22:18:26 +0100 (BST) In-Reply-To: <3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com> References: <1438640036.2828.0.camel@auspira.com>

<3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Peter Todd Date: Tue, 04 Aug 2015 21:18:14 +0000 To: Dave Hudson , Dave Hudson via bitcoin-dev , Peter R Message-ID: <0FB0951B-FCBC-4F50-A10E-34451F6B5D02@petertodd.org> X-Server-Quench: 597e5072-3aee-11e5-b398-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bgdMdgYUGUATAgsB AmMbWVZeUVV7W2s7 aQ5PbARZfE1LQQRt U1dNRFdNFUssBhh9 f2F+OxlzcgRDezBx bUdnWz5eVUMvcEZ6 QFNXRDhTeGZhPWUC AkNRfx5UcAFPdx8U a1UrBXRDAzANdhEy HhM4ODE3eDlSNhEd CChFEUgbR10CFSI9 QBZKMzgiVWgMXSY+ M1QLOl8HAF1ZDUQu MVw8RRoRezUWDQZd fnpMEiIRA1gERjZh SEZcUFFWCjBGTC5G CR1gOhZQDyYaQTdX C0ZeVwpn X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 24.114.75.173/465 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 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 21:18:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 4 August 2015 14:41:53 GMT-04:00, Dave Hudson via bitcoin-dev wrote: >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. Quite correct; this paper is fatally flawed and at best rehashes what we already know happens in the "spherical cow" case, without making it clear that it refers to a completely unrealistic setup. It'd be interested to know who actually wrote it - "Peter R" is obviously a pseudonym and the paper goes into sufficient detail that it makes you wonder why the author didn't see the flaws in it. For those wishing to do actual research, esp. people such as profs mentoring students, keep in mind that in Bitcoin situations where large miners have an advantage over small miners are security exploits, with severity proportional to the difference in profitability. A good example of the type of analysis required is the well known selfish mining paper, which shows how a miner adopting a "selfish" strategy has an advantage - more profit per unit hashing power - than miners who do not adopt that strategy, and additionally, that excess profits scales with increasing hashing power. As for the OP, if this wasn't an attempt at misinformation, my apologies. But keep in mind that you're wading into a highly politically charged research field with billions hanging on the blocksize limit; understand that people aren't happy when flawed papers end up on reddit being used to promote bad ideas. You'd be wise to run future work past experts in the field prior to publishing widely if you dislike heated controversy. -----BEGIN PGP SIGNATURE----- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVwSwJ AAoJEMCF8hzn9Lnc47AH/RknSZpnZ8r4WA4r+S0yJmlo0hKm8gsjUGhaqX7cnuSR dB1ewrsjC4uPtSc8Ej1hzf37E67DTxiz6STq9XdtFSij+ww7SPx+z8yjEpQ0Ld0K OIidQ80WRGJ1UPMUt7pFDU3pxNZI/A46Lg3EmqjY+xAe6+wDlOHjT/miO3tv0uws nNYwrelA4f/KQXkUggGUOW62Sc3fJpUxLurq4eQHflIxtk3KM1reSxwG28KG02j6 lTUEHmMsmE7qoQAl60vwfvVKvvy/RwxpildwNey6IgtCQqWqqEy+WoTsgyVAGIbn +8gR//W2hEIp+W5OSsiVNZ5S/KpcwaIBqZFcoca8838= =HJiv -----END PGP SIGNATURE----- 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 DA592847 for ; Tue, 4 Aug 2015 21:30:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 18F7C1A5 for ; Tue, 4 Aug 2015 21:30:30 +0000 (UTC) Received: by lady2 with SMTP id y2so12276221lad.0 for ; Tue, 04 Aug 2015 14:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MJWcVcPraG97uEWeEizq32dMTfxdZ+8Gpuv6oxraPEs=; b=c7LC7HPzCHsuwr4JZnah6I1djkZv1Cx72RoX/n+zI8DPCE3fnc8tT784TuAn6Whiv1 HhPueOCZJSJsvsZR6/PoWDlVL5hxul1vfLOzcPxJwxDjnG3qKRYWNYwo9SoiVyRI/A1V wHbIqh4BYU4wFBGiCC4vb5ZG4gQ0nSHrg6bCghcWocMqrEO+hQIxLF2jtqMPLGUCkf3Q zv6FZmwPky/iTxgpRWDwleyjFgMP4ycduh7Z+nfNHYPBNziZ5zQXB5SQ3Z3y7Q79hKkX qk7xrYoFXre9YNi0AL4rAOHyqg8ndE1lLVi5IlJ2bZHrsZz47owfpXmn2mV+AV9RbjMM Hgzw== MIME-Version: 1.0 X-Received: by 10.112.239.43 with SMTP id vp11mr6309061lbc.75.1438723828140; Tue, 04 Aug 2015 14:30:28 -0700 (PDT) Received: by 10.25.143.195 with HTTP; Tue, 4 Aug 2015 14:30:28 -0700 (PDT) In-Reply-To: <3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com> References: <1438640036.2828.0.camel@auspira.com>

<3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com> Date: Tue, 4 Aug 2015 17:30:28 -0400 Message-ID: From: Gavin Andresen To: Dave Hudson Content-Type: multipart/alternative; boundary=001a113492b8b4d077051c82fe2a X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 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 21:30:31 -0000 --001a113492b8b4d077051c82fe2a Content-Type: text/plain; charset=UTF-8 On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Fundamentally a block maker (pool or aggregation of pools) does not orphan > its own blocks. Unless the block maker has an infinitely fast connection to it's hashpower OR it's hashpower is not parallelized at all, that's not strictly true -- it WILL orphan its own blocks because two hashing units will find solutions in the time it takes to communicate that solution to the block maker and to the rest of the hashing units. That's getting into "how many miners can dance on the head of a pin" territory, though. I don't think we know whether the communication advantages of putting lots of hashing power physically close together will outweigh the extra cooling costs of doing that (or maybe some other tradeoff I haven't thought of). That would be a fine topic for another paper.... -- -- Gavin Andresen --001a113492b8b4d077051c82fe2a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On T= ue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev &= lt;bitcoin-dev@lists.linuxfoundation.org> wrote:
Fundamentally a block maker (pool or aggregation of p= ools) does not orphan its own blocks.

Unless the bloc= k maker has an infinitely fast connection to it's hashpower OR it's= hashpower is not parallelized at all, that's not strictly true -- it W= ILL orphan its own blocks because two hashing units will find solutions in = the time it takes to communicate that solution to the block maker and to th= e rest of the hashing units.

That's getting into "how many miners can da= nce on the head of a pin" territory, though. I don't think we know= whether the communication advantages of putting lots of hashing power phys= ically close together will outweigh the extra cooling costs of doing that (= or maybe some other tradeoff I haven't thought of). That would be a fin= e topic for another paper....

--
Gavin Andresen

--001a113492b8b4d077051c82fe2a-- 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 9C1CA87A for ; Tue, 4 Aug 2015 21:46:57 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149055.authsmtp.co.uk (outmail149055.authsmtp.co.uk [62.13.149.55]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 067ACEA for ; Tue, 4 Aug 2015 21:46:56 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t74LkpDa094577; Tue, 4 Aug 2015 22:46:51 +0100 (BST) Received: from [25.114.14.211] ([24.114.75.173]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t74Lkkdx006386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Aug 2015 22:46:48 +0100 (BST) In-Reply-To: References: <1438640036.2828.0.camel@auspira.com>

<3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Peter Todd Date: Tue, 04 Aug 2015 21:46:22 +0000 To: Gavin Andresen , Gavin Andresen via bitcoin-dev , Dave Hudson Message-ID: <3E3C6C76-DF1F-4F06-A01F-4E126B70C8F2@petertodd.org> X-Server-Quench: 501f67b7-3af2-11e5-b398-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bgdMdgYUGUATAgsB AmMbWVZeVFt7XGM7 aQ5PbARZfE1LQQRt U1dNRFdNFUssBhh9 XUVKGhlycQZOfjBx YERiWz5eXEUsc0Ev RVNXRDsEeGZhPWUC AkNRfx5UcAFPdx8U a1UrBXRDAzANdhEy HhM4ODE3eDlSNhEd CChFEUgbR10CFSI9 QBZKMzgiVWgMXSY+ M1QLOl8HAF1ZDUQu MVw8RRoRezUWDQZd V3pMEiIRA1gERjZh SEZcUFFWCjBGTC5G CR1gOhZQDyYaQTdX C0ZeVwpn X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 24.114.75.173/465 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 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 21:46:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 4 August 2015 17:30:28 GMT-04:00, Gavin Andresen via bitcoin-dev wrote: >On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev < >bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Fundamentally a block maker (pool or aggregation of pools) does not >orphan >> its own blocks. > > >Unless the block maker has an infinitely fast connection to it's >hashpower >OR it's hashpower is not parallelized at all, that's not strictly true >-- >it WILL orphan its own blocks because two hashing units will find >solutions >in the time it takes to communicate that solution to the block maker >and to >the rest of the hashing units. > >That's getting into "how many miners can dance on the head of a pin" >territory, though. I don't think we know whether the communication >advantages of putting lots of hashing power physically close together >will >outweigh the extra cooling costs of doing that (or maybe some other >tradeoff I haven't thought of). That would be a fine topic for another >paper.... I'd suggest you do more research into how Bitcoin and mining works as the above has a number of serious misunderstandings. Or, I could just point out the obvious rather than try to be polite: you know exactly why the above makes no sense as a reply to this thread and are deliberately lying. If the situation is the latter, your conduct is toxic to the development mailing list discussion, not to mention a waste of all our time, and you should leave. -----BEGIN PGP SIGNATURE----- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVwTKi AAoJEMCF8hzn9Lnc47AH/0txNyw9dLdsfQOsNE14jLEcQifxOkaKLqTJV1O4gn6O L4+T6rPo9pVLTBuVWcsm2A24R/gBL+pYaWgaIyk/3fbSRpg4GfVau0xxh54vQU6m U4L7FPHsdZ2y67frv/+5ExJ2xrVuedhpTciTi2SqSE6C0fioO+YarH0Dvd8I5Wjx f9GnmxLdKytoj2kUaoriSSxsUzMNzxVzq78jEmhMR85TGy73ApeLdgBC/pdNgxZa oAQ0CXCMYgsE59HUOO05xFLazGxNh2epPADTbTTgoNQ9py38evlW254okhRmk9p9 v4i1yTzuv/Y6C0qw2RZcEiT/GTdvajkMKCidLEm3LbY= =W/Ke -----END PGP SIGNATURE----- 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 0B0A687A for ; Tue, 4 Aug 2015 23:38:02 +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 68BCA107 for ; Tue, 4 Aug 2015 23:38:01 +0000 (UTC) Received: from [207.140.24.78] (port=28137 helo=[10.0.0.243]) by heron.directrouter.co.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1ZMlmR-001nSG-3b; Tue, 04 Aug 2015 23:37:59 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_3E1D36B6-5BAC-4F05-8886-EE777A669663" Mime-Version: 1.0 (Mac OS X Mail 8.2 $2102$) From: Dave Hudson In-Reply-To: Date: Tue, 4 Aug 2015 16:37:57 -0700 Message-Id: <2A7FC602-A8A1-4C56-B8F4-92DB411B4AED@hashingit.com> References: <1438640036.2828.0.camel@auspira.com>

<3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com> To: Gavin Andresen 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 23:38:02 -0000 --Apple-Mail=_3E1D36B6-5BAC-4F05-8886-EE777A669663 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 4 Aug 2015, at 14:30, Gavin Andresen = wrote: >=20 > On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev = > wrote: > Fundamentally a block maker (pool or aggregation of pools) does not = orphan its own blocks. >=20 > Unless the block maker has an infinitely fast connection to it's = hashpower OR it's hashpower is not parallelized at all, that's not = strictly true -- it WILL orphan its own blocks because two hashing units = will find solutions in the time it takes to communicate that solution to = the block maker and to the rest of the hashing units. >=20 > That's getting into "how many miners can dance on the head of a pin" = territory, though. I don't think we know whether the communication = advantages of putting lots of hashing power physically close together = will outweigh the extra cooling costs of doing that (or maybe some other = tradeoff I haven't thought of). That would be a fine topic for another = paper.... Yes, but the block maker won't publish the second block it finds for the = same set of transactions. It won't orphan its own block. In fact even if = it does it still doesn't matter because the block maker still gets the = block reward irrespective of which of the two solutions are published. It's not about which hash wins, the issue is who gets paid as a result. --Apple-Mail=_3E1D36B6-5BAC-4F05-8886-EE777A669663 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 4 Aug 2015, at 14:30, Gavin Andresen <gavinandresen@gmail.com> wrote:

On Tue, = Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> = wrote:
Fundamentally a = block maker (pool or aggregation of pools) does not orphan its own = blocks.

Unless the block maker has an = infinitely fast connection to it's hashpower OR it's hashpower is not = parallelized at all, that's not strictly true -- it WILL orphan its own = blocks because two hashing units will find solutions in the time it = takes to communicate that solution to the block maker and to the rest of = the hashing units.

That's getting into "how = many miners can dance on the head of a pin" territory, though. I don't = think we know whether the communication advantages of putting lots of = hashing power physically close together will outweigh the extra cooling = costs of doing that (or maybe some other tradeoff I haven't thought of). = That would be a fine topic for another = paper....

Yes, = but the block maker won't publish the second block it finds for the same = set of transactions. It won't orphan its own block. In fact even if it = does it still doesn't matter because the block maker still gets the = block reward irrespective of which of the two solutions are = published.

It's not about which hash = wins, the issue is who gets paid as a result.

= --Apple-Mail=_3E1D36B6-5BAC-4F05-8886-EE777A669663-- 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 BCE02847 for ; Wed, 5 Aug 2015 00:26:11 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.help.org (mail.help.org [70.90.2.18]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 380D089 for ; Wed, 5 Aug 2015 00:26:11 +0000 (UTC) Received: from [10.1.10.25] (B [10.1.10.25]) by mail.help.org with ESMTPA ; Tue, 4 Aug 2015 20:26:01 -0400 To: bitcoin-dev@lists.linuxfoundation.org References: <1438640036.2828.0.camel@auspira.com>

<3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com> <3E3C6C76-DF1F-4F06-A01F-4E126B70C8F2@petertodd.org> From: Milly Bitcoin Message-ID: <55C1581C.7080804@bitcoins.info> Date: Tue, 4 Aug 2015 20:26:04 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <3E3C6C76-DF1F-4F06-A01F-4E126B70C8F2@petertodd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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 00:26:11 -0000 >For those wishing to do actual research, esp. people such as profs mentoring students, ... >But keep in mind that you're wading into a highly politically charged research field >with billions hanging on the blocksize limit; understand that people aren't happy when >flawed papers end up on reddit being used to promote bad ideas. You'd be wise to run future >work past experts in the field prior to publishing widely if you dislike heated controversy. > Or, I could just point out the obvious rather than try to be polite: you know exactly why >the above makes no sense as a reply to this thread and are deliberately lying. >If the situation is the latter, your conduct is toxic to the development mailing list >discussion, not to mention a waste of all our time, and you should leave. Researchers should also keep in mind that some of developers are immature and have limited knowledge or experience beyond their Bitcoin expertise ("Idiot-savants"). Others want to be in "charge" of drama-laced posts on reddit and they get upset if others do the same things. In any case these rants and attacks by Todd and Garzik should be posted on their personal blogs or reddit instead of this list. Russ 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 76DC988B for ; Wed, 5 Aug 2015 00:41:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E1E6B13E for ; Wed, 5 Aug 2015 00:41:22 +0000 (UTC) Received: by ioea135 with SMTP id a135so34250960ioe.1 for ; Tue, 04 Aug 2015 17:41:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=4q6vbtsVdDEWD4Blk+tYumgruz8lgPKtFgT41o6Y9uY=; b=MOWsG76EGvKu3wrNKbeaEk+LE02F5Q4trt7YkP5ixU5vjYG0xUBTrf4ZQ+dKI6vmNJ 7MZmaljp4Ur0cvbRwr5W42iDxRcbyOkLzGOx7PdRgXg6s+7ubO4qi8fDCM8NWA/M6IZ0 iafdqicT1HGijbW2cMqbPxCjaryqRQE/Hd0so98xIDeYD364yUmC0XCM/arqAjj/U3VV I47Nv6VCOVSzHKNNwXwJumJeM+W9uuOP13b4wpbL5He8PvZOmcfr9fOfcqy1ZV/rl3Md wMXsPaEhtM1hsXzPGP4rCRI6B/1kYxdStZPXJXNUP1n3afqMy8YWVMyH2RUBQklHuBUA 1Sgw== X-Gm-Message-State: ALoCoQk3fG4L0DE5hoL0ZTcjdvPqHCly7xexNy+Wc11e3zVb1GWcXyWIA4ZGwUNVtBO/2Jmk1QsL X-Received: by 10.107.11.155 with SMTP id 27mr7083397iol.121.1438735281930; Tue, 04 Aug 2015 17:41:21 -0700 (PDT) MIME-Version: 1.0 Sender: neil@asdf.co.nz Received: by 10.107.53.226 with HTTP; Tue, 4 Aug 2015 17:40:42 -0700 (PDT) X-Originating-IP: [202.56.47.34] In-Reply-To: <55C1581C.7080804@bitcoins.info> References: <1438640036.2828.0.camel@auspira.com>

<3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com> <3E3C6C76-DF1F-4F06-A01F-4E126B70C8F2@petertodd.org> <55C1581C.7080804@bitcoins.info> From: Neil Fincham Date: Wed, 5 Aug 2015 12:40:42 +1200 X-Google-Sender-Auth: cfmksx-Sjg4PH40XfrEuERKXpVI Message-ID: To: Milly Bitcoin Content-Type: multipart/alternative; boundary=001a113f8cfc67df53051c85a976 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,T_REMOTE_IMAGE 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] "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 00:41:24 -0000 --001a113f8cfc67df53051c85a976 Content-Type: text/plain; charset=UTF-8 > Researchers should also keep in mind that some of developers are immature and have limited knowledge or experience beyond their Bitcoin expertise ("Idiot-savants"). Others want to be in "charge" of drama-laced posts on reddit and they get upset if others do the same things. > In any case these rants and attacks by Todd and Garzik should be posted on their personal blogs or reddit instead of this list. I very rarely comment on list politics but isn't this the kettle calling the pot black? Back to my hole now I promise. On 5 August 2015 at 12:26, Milly Bitcoin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > For those wishing to do actual research, esp. people such as profs >> mentoring students, ... >> > > But keep in mind that you're wading into a highly politically charged >> research field >> with billions hanging on the blocksize limit; understand that people >> aren't happy when >> flawed papers end up on reddit being used to promote bad ideas. You'd be >> wise to run future >> work past experts in the field prior to publishing widely if you dislike >> heated controversy. >> > > Or, I could just point out the obvious rather than try to be polite: you >> know exactly why >> the above makes no sense as a reply to this thread and are deliberately >> lying. >> > > If the situation is the latter, your conduct is toxic to the development >> mailing list >> discussion, not to mention a waste of all our time, and you should leave. >> > > > > > Researchers should also keep in mind that some of developers are immature > and have limited knowledge or experience beyond their Bitcoin expertise > ("Idiot-savants"). Others want to be in "charge" of drama-laced posts on > reddit and they get upset if others do the same things. > > In any case these rants and attacks by Todd and Garzik should be posted on > their personal blogs or reddit instead of this list. > > Russ > > > > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- [image: Facebook] [image: Twitter] [image: LinkedIn] Neil Fincham MineForeman Phone: +64 21 545 583 99 Sala St, Rotorua, New Zealand. 3010 Website | neil@mineforeman.com --001a113f8cfc67df53051c85a976 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

>=C2=A0Researchers should also keep in mind that some of developers are immature= and have limited knowledge or experience beyond their Bitcoin expertise (&= quot;Idiot-savants").=C2=A0 Others want to be in "charge" of= drama-laced posts on reddit and they get upset if others do the same thing= s.

>=C2=A0In any case these rants and attacks by Todd and Garzik should be = posted on their personal blogs or reddit instead of this list.

<= span style=3D"font-size:12.8000001907349px">

I very=C2=A0rarely=C2=A0comment on list= politics but=C2=A0isn't=C2=A0this the kettle calling the pot black?

Back to my hole now I= =C2=A0promise.

On 5 August 2015 at 12:26, Milly Bitcoin via bitcoin-dev <= span dir=3D"ltr"><bitcoin-dev@lists.linuxfoundation.org> w= rote:

For those wishing to do actual research, esp. people such as profs mentorin= g students, ...

But keep in mind that you're wading into a highly politically charged r= esearch field
with billions hanging on the blocksize limit; understand that people aren&#= 39;t happy when
flawed papers end up on reddit being used to promote bad ideas. You'd b= e wise to run future
work past experts in the field prior to publishing widely if you dislike he= ated controversy.

Or, I could just point out the obvious rather than try to be polite: you kn= ow exactly why
the above makes no sense as a reply to this thread and are deliberately lyi= ng.

If the situation is the latter, your conduct is toxic to the development ma= iling list
discussion, not to mention a waste of all our time, and you should leave.

Researchers should also keep in mind that some of developers are immature a= nd have limited knowledge or experience beyond their Bitcoin expertise (&qu= ot;Idiot-savants").=C2=A0 Others want to be in "charge" of d= rama-laced posts on reddit and they get upset if others do the same things.=

In any case these rants and attacks by Todd and Garzik should be posted on = their personal blogs or reddit instead of this list.

Russ

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--
=

Neil Fincham

MineForeman

Phone: +64 21 545 583

99 Sala St, Rotorua, New Zealand. 3010

Website=C2=A0|=C2=A0neil@m= ineforeman.com

--001a113f8cfc67df53051c85a976-- 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 1B7B07D for ; Wed, 5 Aug 2015 03:07:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4F82D1A0 for ; Wed, 5 Aug 2015 03:07:52 +0000 (UTC) Received: by padck2 with SMTP id ck2so23878315pad.0 for ; Tue, 04 Aug 2015 20:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=/hWdtasE1aYNrlqHLn+Dk094W4n8sikJuzPXgVoRrA4=; b=MYKzaxCA7uK/VeUy2h/buNvbgKVn8IinZJ2got8mvi/F30aYNdny/brJo7UsZV1mGZ Rw5mJ+z0HAqOXirbwRp4mSKL+Y7bbT+rRMoZAy94MZ2Vo4k/dqJeHViqCqK6JDyF3syk bopvtCEH3mRgrwqjXqyChjOiPZus+UDuExWle7xnT9tpR6WAiXnnXcqnHldWqIiz0VFv 4hdhkSmuv93/vDGkOi197KfFp/p0/OXa1ynF7HCzF8PDZhObfzAqSHK71ovXBMTM5Vsx Pwk3XPbNzjFLtg4zI99LxLJt40JqLA+9ZMoGgAcE+OB8Gah9POmSOvvpcr7Ek3FaNVaC B0dg== X-Received: by 10.67.15.67 with SMTP id fm3mr14546384pad.114.1438744071980; Tue, 04 Aug 2015 20:07:51 -0700 (PDT) Received: from [192.168.1.107] (cpe-76-167-237-202.san.res.rr.com. [76.167.237.202]) by smtp.gmail.com with ESMTPSA id hx7sm843016pbc.84.2015.08.04.20.07.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Aug 2015 20:07:51 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 $2098$) Content-Type: multipart/signed; boundary="Apple-Mail=_6C84C5CD-BF8B-4B0D-9FE8-AE22367895D3"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Eric Lombrozo In-Reply-To: <5A323AB6-914C-4FF5-9FC2-AB8E02C69F93@phauna.org> Date: Tue, 4 Aug 2015 20:07:48 -0700 Message-Id: <835E3F90-C057-4240-9EB6-D2C7400B662B@gmail.com> References:

<5A323AB6-914C-4FF5-9FC2-AB8E02C69F93@phauna.org> To: Owen X-Mailer: Apple Mail (2.2098) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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: Anthony Towns via bitcoin-dev Subject: Re: [bitcoin-dev] Eli Dourado on "governance" 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 03:07:53 -0000 --Apple-Mail=_6C84C5CD-BF8B-4B0D-9FE8-AE22367895D3 Content-Type: multipart/alternative; boundary="Apple-Mail=_8F28C036-B8A0-4D41-ABD0-83DC64CF37D8" --Apple-Mail=_8F28C036-B8A0-4D41-ABD0-83DC64CF37D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Rather than speculating on fake markets, why don=E2=80=99t we use = theory, empirical data, and engineering to fix the damn problems? > On Aug 4, 2015, at 11:28 AM, Owen via bitcoin-dev = wrote: >=20 > Given there is no money at stake in these prediction games, it is no = surprise that the results are implausible. >=20 > On August 4, 2015 10:22:19 AM EDT, Anthony Towns via bitcoin-dev = wrote: > On 4 August 2015 at 01:22, Gavin Andresen via bitcoin-dev = > wrote: > And the preliminary results of using a prediction market to try to = wrestle with the tough tradeoffs looks roughly correct to me, too: > https://blocksizedebate.com/ >=20 > =E2=80=8BThe scicast prediction market is shutdown atm (since early = July?) so those numbers aren't live. But... >=20 > Network hash rate > 3,255.17 PH/s (same block size) > 5,032.64 PH/s (block size increase) >=20 > 4,969.68 PH/s (no replace-by-fee) > 3,132.09 PH/s (replace-by-fee) >=20 > Those numbers seem completely implausible: that's ~2.9-3.6 doublings = of the current hashrate (< 400PH/s) in 17 months, when it's taken 12 = months for the last doubling, and there's a block reward reduction due = in that period too. (That might've been a reasonable prediction sometime = in the past year, when doublings were slowing from once every ~45 days = to once a year; it just doesn't seem a supportable prediction now) >=20 > That the PH/s rate is higher with bigger blocks is surprising, but = given that site also predicts USD/BTC will be $280 with no change but = $555 with bigger blocks, so I assume that difference is mostly due to = price. Also, 12.5btc at $555 each is about 23 btc at $300 each, so if = that price increase is realistic, it would compensate for almost all of = the block reward reduction. >=20 > Daily transaction volume > 168,438.22 tx/day (same block size) > 193,773.08 tx/day (block size increase) >=20 > 192,603.80 tx/day (no replace-by-fee) > 168,406.73 tx/day (replace-by-fee) >=20 > That's only a 15% increase in transaction volume due to the block size = increase; I would have expected more? 168k-194k tx/day is also only a = 30%-50% increase in transaction volume from 130k tx/day currently. If = that's really the case, then a 1.5MB-2MB max block size would probably = be enough for the next two years... >=20 > (Predicting that the node count will drop from ~5000 to ~1200 due to = increasing block sizes seems quite an indictment as far as = centralisation risks go; but given I'm not that convinced by the other = predictions, I'm not sure I want to give that much weight to that one = either) >=20 > Cheers, > aj >=20 > -- > Anthony Towns > >=20 >=20 > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_8F28C036-B8A0-4D41-ABD0-83DC64CF37D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Rather than speculating on fake markets, why don=E2=80=99t we = use theory, empirical data, and engineering to fix the damn = problems?

On Aug 4, 2015, at 11:28 AM, Owen via = bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Given = there is no money at stake in these prediction games, it is no surprise = that the results are implausible.
On August 4, 2015 10:22:19 AM EDT, Anthony Towns = via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> = wrote:
On 4 August 2015 at = 01:22, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
And the preliminary results of using a = prediction market to try to wrestle with the tough tradeoffs looks = roughly correct to me, too:
https://blocksizedebate.com/

=E2=80=8BThe = scicast prediction market is shutdown atm (since early July?) so those = numbers aren't live. But...

Network hash rate
3,255.17 PH/s (same = block size)
= 5,032.64 PH/s = (block size increase)

4,969.68 PH/s (no = replace-by-fee)
3,132.09 PH/s = (replace-by-fee)

Those = numbers seem completely implausible: that's ~2.9-3.6 doublings of the = current hashrate (< 400PH/s) in 17 months, when it's taken 12 months = for the last doubling, and there's a block reward reduction due in that = period too. (That might've been a reasonable prediction sometime in the = past year, when doublings were slowing from once every ~45 days to once = a year; it just doesn't seem a supportable prediction = now)

That the PH/s rate is higher with bigger = blocks is surprising, but given that site also predicts USD/BTC will be = $280 with no change but $555 with bigger blocks, so I assume that = difference is mostly due to price. Also, 12.5btc at $555 each is about = 23 btc at $300 each, so if that price increase is realistic, it would = compensate for almost all of the block reward = reduction.

Daily = transaction volume
168,438.22 tx/day (same block = size)
= 193,773.08 tx/day (block size increase)

= 192,603.80 = tx/day (no replace-by-fee)
168,406.73 tx/day = (replace-by-fee)

That's= only a 15% increase in transaction volume due to the block size = increase; I would have expected more? 168k-194k tx/day is also only a = 30%-50% increase in transaction volume from 130k tx/day currently. If = that's really the case, then a 1.5MB-2MB max block size would probably = be enough for the next two years...

(Predicting that the node = count will drop from ~5000 to ~1200 due to increasing block sizes seems = quite an indictment as far as centralisation risks go; but given I'm not = that convinced by the other predictions, I'm not sure I want to give = that much weight to that one either)

Cheers,
aj

-- =
Anthony Towns <aj@erisian.com.au>
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a>
________________________________= _______________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">

= --Apple-Mail=_8F28C036-B8A0-4D41-ABD0-83DC64CF37D8-- --Apple-Mail=_6C84C5CD-BF8B-4B0D-9FE8-AE22367895D3 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 iQIcBAEBCgAGBQJVwX4EAAoJEJNAI64YFENUXN8P/2VhOB2+biWsMm2y5NDIxIIQ pD8mI/Jus+KLRZgETBAS7tBknz//eak1NkMWOmQDF8CkjFYP6NR6gLow0zwx+5qY eBZBEXvSQNwETTp5eI58QRlyak0sODQ7lSLRx2eOcBRQTukbxz1XJXoSJmaVWmB0 Y9z7Y5s6Y/1aH6BqG6B3rhNzFAcxgrSyyjTapygKAy7yRsWd53ScdWRswjZy9gtF UolCkG4yY5Fnxxe3QR4rIQG9MbhdFxbXYRNWJHgVPXayqdSuzI2gr+lt/p/di6Jz RH7tpjvfx/y5r6bHnAQUtdRqVvPCQyshd0vzbSMvdDNasZhYFr53HAefjfpD+AUL RHBC/a9qNdwoKKln51aNo6zYDqyHOwZq3kKeTsuRBoG6xESu5E6+7Mw5CEWp2p++ 6Wt9ZUg9ahqzMYhIhJ8ezWtHhP+hFHJAszjjJAiBEObFMZ2wMniLHcF7Z6KaKUz/ hBtyPNmpv9c9evuRVWqqV3kNFHsK6mX9FjXHxVXHqgIr7QUxudO2yokBIn8NWe8F /nIHFmlUo1MY6ixscUlRLUQHNCo5PyQlZs7IycCRuOa9u4dduGwKao/C3HZ5WFji SOiqouNMbeSiI8cEUaWYNDS042YSrBcqmTvglEi00qdMOXDpVsT1ypnkbC+txxbY 74aJjwL4bfg0vNN1Nbkm =41NE -----END PGP SIGNATURE----- --Apple-Mail=_6C84C5CD-BF8B-4B0D-9FE8-AE22367895D3-- 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 2E4917E for ; Wed, 5 Aug 2015 06:32:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DFC7030 for ; Wed, 5 Aug 2015 06:32:24 +0000 (UTC) Received: by padck2 with SMTP id ck2so28013889pad.0 for ; Tue, 04 Aug 2015 23:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=6qF7NpIa4hbeKT+ez6wjPpslNXYc+7cK/4+Oe+FD4MQ=; b=JOsaHl3nNsh5kH3bB7cT6XpDOo8vqKXG4OfslOGLBChg1gKbKbrVZ5rfnej2xpnrM/ mBJa385uqCsnu96wUNNMA33Lgvmj3Dun2nfIiaiXGKunGI7tYY2Hlpy9X6MTQRwW4EJc 4yvsRJbQtpRhEGBKZcznIsvcU0++vOZ5lHXWeC9NjGD1VqyQ9Sv1q5DWPMCSuXRKwBxN 85lzFIT87mxfbgz+CSLIDjB7rb/+knRsnFwcaBYvfOEK8yULQSCXLSvs1XBxH+wb1cQC 2XYP7sxMKLq78z6gXYXXKqey8hs8w5LwH/oCNvkdkfjaJMQP38ifkrVZG6+69PWwHp2L v9DQ== X-Received: by 10.66.230.201 with SMTP id ta9mr16258442pac.95.1438756344599; Tue, 04 Aug 2015 23:32:24 -0700 (PDT) Received: from mail.outlook.com (ec2-54-149-197-188.us-west-2.compute.amazonaws.com. [54.149.197.188]) by smtp.gmail.com with ESMTPSA id cq5sm1508516pad.11.2015.08.04.23.32.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Aug 2015 23:32:23 -0700 (PDT) Date: Wed, 5 Aug 2015 06:32:23 +0000 (UTC) From: Mashuri Clark To: , Owen , Eric Lombrozo Message-ID: <207C5360C6E6B691.EE5B6328-B96A-4704-9818-D158751E7CAD@mail.outlook.com> In-Reply-To: <835E3F90-C057-4240-9EB6-D2C7400B662B@gmail.com> References:

<5A323AB6-914C-4FF5-9FC2-AB8E02C69F93@phauna.org> <835E3F90-C057-4240-9EB6-D2C7400B662B@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9769_2068777552.1438756343021" X-Mailer: Outlook for iOS and Android X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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: Anthony Towns via bitcoin-dev Subject: Re: [bitcoin-dev] Eli Dourado on "governance" 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 06:32:26 -0000 ------=_Part_9769_2068777552.1438756343021 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Why not speculate on a real market? =C2=A0Peter Sztorc proposed a sidechain= that could be implemented now using Blockstream's method: http://www.truthcoin.info/blog/win-win-blocksize/ -- MC On Tue, Aug 4, 2015 at 8:08 PM -0700, "Eric Lombrozo via bitcoin-dev" wrote: Rather than speculating on fake markets, why don=E2=80=99t we use theory, e= mpirical data, and engineering to fix the damn problems? On Aug 4, 2015, at 11:28 AM, Owen via bitcoin-dev wrote: Given there is no money at stake in these prediction games, it is no surpri= se that the results are implausible. On August 4, 2015 10:22:19 AM EDT, Anthony Towns via bitcoin-dev wrote: On 4 August 2015 at 01:22, Gavin Andresen via bitcoin-dev wrote: And the preliminary results of using a prediction market to try to wrestle = with the tough tradeoffs looks roughly correct to me, too:=C2=A0 =C2=A0http= s://blocksizedebate.com/ =E2=80=8BThe scicast prediction market is shutdown atm (since early July?) = so those numbers aren't live. But... Network hash rate 3,255.17 PH/s =C2=A0(same block size) 5,032.64 PH/s =C2=A0(block size incr= ease) 4,969.68 PH/s =C2=A0(no replace-by-fee) 3,132.09 PH/s =C2=A0(replace-by-fee) Those numbers seem completely implausible: that's ~2.9-3.6 doublings of the= current hashrate (< 400PH/s) in 17 months, when it's taken 12 months for t= he last doubling, and there's a block reward reduction due in that period t= oo. (That might've been a reasonable prediction sometime in the past year, = when doublings were slowing from once every ~45 days to once a year; it jus= t doesn't seem a supportable prediction now) That the PH/s rate is higher with bigger blocks is surprising, but given th= at site also predicts USD/BTC will be $280 with no change but $555 with big= ger blocks, so I assume that difference is mostly due to price. Also, 12.5b= tc at $555 each is about 23 btc at $300 each, so if that price increase is = realistic, it would compensate for almost all of the block reward reduction= . Daily transaction volume 168,438.22 tx/day =C2=A0(same block size) 193,773.= 08 tx/day =C2=A0(block size increase) 192,603.80 tx/day =C2=A0(no replace-by-fee) 168,406.73 tx/day =C2=A0(repla= ce-by-fee) That's only a 15% increase in transaction volume due to the block size incr= ease; I would have expected more? 168k-194k tx/day is also only a 30%-50% i= ncrease in transaction volume from 130k tx/day currently. If that's really = the case, then a 1.5MB-2MB max block size would probably be enough for the = next two years... (Predicting that the node count will drop from ~5000 to ~1200 due to increa= sing block sizes seems quite an indictment as far as centralisation risks g= o; but given I'm not that convinced by the other predictions, I'm not sure = I want to give that much weight to that one either) Cheers,aj --=20 Anthony Towns bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ------=_Part_9769_2068777552.1438756343021 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Why not speculate on a real market? Pet= er Sztorc proposed a sidechain that could be implemented now using Blockstr= eam's method:

http://www.truthcoin.info/blog/win= -win-blocksize/

--
MC

On Tue, Aug 4, 2015 at 8:08 PM -0700, "Eric= Lombrozo via bitcoin-dev" <bitcoin-dev@lists.lin= uxfoundation.org> wrote:

R= ather than speculating on fake markets, why don=E2=80=99t we use theory, em= pirical data, and engineering to fix the damn problems?
On A= ug 4, 2015, at 11:28 AM, Owen via bitcoin-dev <bitcoin-dev@lists.linuxfoundatio= n.org> wrote:
Given there is no money at stake in these predicti= on games, it is no surprise that the results are implausible.
On August 4, 2015 10:22:19 A= M EDT, Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org= > wrote:
On 4 = August 2015 at 01:22, Gavin Andresen via bitcoin-dev <bitcoin= -dev@lists.linuxfoundation.org> wrote:
=
And the preliminary results of = using a prediction market to try to wrestle with the tough tradeoffs looks = roughly correct to me, too:
https://blocksized= ebate.com/
=E2=80=8BThe scicast prediction market is shutdown atm (since early Ju= ly?) so those numbers aren't live. But...

Network hash rat= e
3,255.17 PH/s (same blo= ck size)
5,032.64 PH/s (block size incre= ase)

4,969.68 PH/s (no replace-by-fee)
3= ,132.09 PH/s (replace-by-fee)

Those numbers see= m completely implausible: that's ~2.9-3.6 doublings of the current hashrate= (< 400PH/s) in 17 months, when it's taken 12 months for the last doubli= ng, and there's a block reward reduction due in that period too. (That migh= t've been a reasonable prediction sometime in the past year, when doublings= were slowing from once every ~45 days to once a year; it just doesn't seem= a supportable prediction now)

That the PH/s rate i= s higher with bigger blocks is surprising, but given that site also predict= s USD/BTC will be $280 with no change but $555 with bigger blocks, so I ass= ume that difference is mostly due to price. Also, 12.5btc at $555 each is a= bout 23 btc at $300 each, so if that price increase is realistic, it would = compensate for almost all of the block reward reduction.

Dai= ly transaction volume
168,438.22 tx/day (same block size)
193,773.08 tx/day (= block size increase)

192,603.80 tx/day &nb= sp;(no replace-by-fee)
168,406.73 tx/day (= replace-by-fee)
<= span style=3D"font-family:monospace" class=3D"">
That's only a 15% increase in transaction v= olume due to the block size increase; I would have expected more? 168k-194k= tx/day is also only a 30%-50% increase in transaction volume from 130k tx/= day currently. If that's really the case, then a 1.5MB-2MB max block size w= ould probably be enough for the next two years...

=
(Predictin= g that the node count will drop from ~5000 to ~1200 due to increasing block= sizes seems quite an indictment as far as centralisation risks go; but giv= en I'm not that convinced by the other predictions, I'm not sure I want to = give that much weight to that one either)

<= /div>
Cheer= s,
aj

-- <= br class=3D"" />
Anthony Towns <aj@erisian.com.au>
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
=
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
____________________________________= ___________
bitcoin-dev mailing list
bitcoin-dev@l= ists.linuxfoundation.org
https://lists.linuxfoundation.= org/mailman/listinfo/bitcoin-dev
<= br class=3D"" />

------=_Part_9769_2068777552.1438756343021-- 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 738809A for ; Wed, 5 Aug 2015 08:33:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A24DE10E for ; Wed, 5 Aug 2015 08:33:13 +0000 (UTC) Received: by obdeg2 with SMTP id eg2so26427512obd.0 for ; Wed, 05 Aug 2015 01:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w47m/ZXocOSR+SkzAX5YQA1fz3E7jR96Zv+tSzC2r7k=; b=cM+JeqgxsdVtLHC0glTejrTrLRWPBhMaCQbkEeta8UoKXIsei3WQLuwBS0p5AdTn2/ Sj3ZD2vCiwUmklscdg4TdByN5nFwEI9QpVVaUZh0lMP4M9cc+TfHPvDM0W19jV43Rwy7 m961gV/8IqxfGpjDxXRzltddu5aoqLGcrGnN38n8b+tFqfD1e0NCcF3w56PDfAkrtl3K rGfXCo4MLTOm+gTRbjradEFWO/qAl6QmZwGOQnEx1F0aoal8+0QSOesLKfypW56LuaAb eH8bSSUolPq2+C4fI40AOSFhz7W68P5ko1nYi9Kw4zR9hPnqRUlTOK9BqjnxDwcnsppB PjIQ== MIME-Version: 1.0 X-Received: by 10.60.178.33 with SMTP id cv1mr7020174oec.11.1438763593083; Wed, 05 Aug 2015 01:33:13 -0700 (PDT) Received: by 10.202.224.212 with HTTP; Wed, 5 Aug 2015 01:33:13 -0700 (PDT) In-Reply-To: References: <1438640036.2828.0.camel@auspira.com>

Date: Wed, 5 Aug 2015 10:33:13 +0200 Message-ID: From: Benjamin To: Peter R Content-Type: multipart/alternative; boundary=089e01182252e1b4cf051c8c4025 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 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 08:33:14 -0000 --089e01182252e1b4cf051c8c4025 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Very interesting paper. When you talk about a market, what are you referring to exactly? A market means that demand and supply are matched continuously, and Bitcoin has no such mechanism. A lot of discussion has been around fixing the "supply" of blocksize. A floating number would mean that a hardcoded number or function would be replaced by a decision process involving users (demand). I don't think a fee market exists and that demand or supply are not easily definable. Ideally supply of transaction capability would completely depend on demand, and a price would exist such that demand can react to longterm or shorterm supply constraints. In such a scenario there would be no scalability concerns, as scale would be almost perfectly elastic. On Tue, Aug 4, 2015 at 8:40 AM, Peter R via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Dear Bitcoin-Dev Mailing list, > > I=E2=80=99d like to share a research paper I=E2=80=99ve recently complete= d titled =E2=80=9CA > Transaction Fee Market Exists Without a Block Size Limit.=E2=80=9D In ad= dition 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 functioni= ng > 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 th= e > size of the UTXO set. > > It can be downloaded in PDF format here: > > https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf > > Or viewed with a web-browser here: > > > https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-Exists-With= out-a-Block-Size-Limit > > *Abstract. *This paper shows how a rational Bitcoin miner should select > transactions from his node=E2=80=99s 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 b= y > accounting for orphaning risk. The latter represents the fees offered by > the transactions in mempool, and is expressed versus the minimum block si= ze > required to claim a given portion of the fees. The paper explains how th= e > supply and demand curves from classical economics are related to the > derivatives of these two curves, and proves that producing the quantity o= f > block space indicated by their intersection point maximizes the miner=E2= =80=99s > profit. The paper then shows that an unhealthy fee market=E2=80=94where = miners are > incentivized to produce arbitrarily large blocks=E2=80=94cannot exist sin= ce it > requires communicating information at an arbitrarily fast rate. The pape= r > concludes by considering the conditions under which a rational miner woul= d > 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 > > --089e01182252e1b4cf051c8c4025 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Very interesting paper. When you talk about a market, what= are you referring to exactly? A market means that demand and supply are ma= tched continuously, and Bitcoin has no such mechanism. A lot of discussion = has been around fixing the "supply" of blocksize. A floating numb= er would mean that a hardcoded number or function would be replaced by a de= cision process involving users (demand). I don't think a fee market exi= sts and that demand or supply are not easily definable. Ideally supply of t= ransaction capability would completely depend on demand, and a price would = exist such that demand can react to longterm or shorterm supply constraints= . In such a scenario there would be no scalability concerns, as scale would= be almost perfectly elastic.

On Tue, Aug 4, 2015 at 8:40 AM, Peter R via bitcoin-dev <= span dir=3D"ltr"><bitcoin-dev@lists.linuxfoundation.org> w= rote:

Dear Bitcoin-Dev Mailing list,

I=E2=80=99d l= ike to share a research paper I=E2=80=99ve recently completed titled =E2=80= =9CA Transaction Fee Market Exists Without a Block Size Limit.=E2=80=9D =C2= =A0In addition to presenting some useful charts such as the cost to produce= large spam blocks, I think the paper convincingly demonstrates that, due t= o the orphaning cost, a block size limit is not necessary to ensure a funct= ioning fee market. =C2=A0

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

It can be downloaded in PDF format here:
=

https://dl.dropboxusercontent.com/u/43331= 625/feemarket.pdf

Or viewed with a web-browser= here:

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

Abstract. =C2= =A0This paper shows how a rational Bitcoin miner should select transact= ions from his node=E2=80=99s mempool, when creating a new block, in order t= o maximize his profit in the absence of a block size limit. To show this, t= he paper introduces the block space supply curve and the mempool demand cur= ve.=C2=A0 The former describes the cost for a miner to supply block space b= y accounting for orphaning risk.=C2=A0 The latter represents the fees offer= ed by the transactions in mempool, and is expressed versus the minimum bloc= k size required to claim a given portion of the fees.=C2=A0 The paper expla= ins how the supply and demand curves from classical economics are related t= o the derivatives of these two curves, and proves that producing the quanti= ty of block space indicated by their intersection point maximizes the miner= =E2=80=99s profit.=C2=A0 The paper then shows that an unhealthy fee market= =E2=80=94where miners are incentivized to produce arbitrarily large blocks= =E2=80=94cannot exist since it requires communicating information at an arb= itrarily fast rate.=C2=A0 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. =C2=A0

B= est regards,
Peter

_______________________________= ________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--089e01182252e1b4cf051c8c4025-- 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 1A3FB83D for ; Wed, 5 Aug 2015 09:18:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3B6867C for ; Wed, 5 Aug 2015 09:18:50 +0000 (UTC) Received: by labkb6 with SMTP id kb6so2721350lab.2 for ; Wed, 05 Aug 2015 02:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=puSb88IkRW1c0oin29UY5AxKaTbPaARdSN6LdgKzh7s=; b=WGsCcpFZYNoj9fmjPqZQgYG1pxQ/Nw94IZfYT3+6MkG2CvbmaYBOXXceJiHhvnNUJn zvXdWZwDs+HWK5mYGeJGkyidV75dJwfq0CjS6DU6aaNYavCdiVegtq1V8Vcw2XKaPxW0 7M/waT+GpMxVqTsL+AahFHTJ5gsrJSSKIY+ZmaQMKz8zKevxAY6xx4qoeFhY8KzUFunh u8JHrG3K5+r1woOhR/3W+1eP6UDmVu1jaB0agbbOZ8BdkFhPJgOTvZ0c5N2odWGIn1Bx ZTNbsI9cGEaXdIgv/oBbefQpV4lAfYC/OAbWrH5OuVyR900dv0zvk9F0pxc90j16C7UB 3pCg== X-Received: by 10.112.77.103 with SMTP id r7mr8272861lbw.63.1438766328324; Wed, 05 Aug 2015 02:18:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.22.25 with HTTP; Wed, 5 Aug 2015 02:18:28 -0700 (PDT) In-Reply-To: References: <1438640036.2828.0.camel@auspira.com>

From: Hector Chu Date: Wed, 5 Aug 2015 10:18:28 +0100 Message-ID: To: Benjamin Content-Type: multipart/alternative; boundary=001a11c3f026ea28f5051c8ce313 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 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 09:18:51 -0000 --001a11c3f026ea28f5051c8ce313 Content-Type: text/plain; charset=UTF-8 On 5 August 2015 at 09:33, Benjamin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > A market means that demand and supply are matched continuously, and > Bitcoin has no such mechanism. > Not all markets need to have highly liquid trading outlets in order to be thought of as such. Inefficient markets are where there is an imperfect matching mechanism. I don't think a fee market exists and that demand or supply are not easily > definable. > Demand and supply are reflected in the market in the following two prices: - BTC/USD - Average transaction fee levels * Average transaction volume rate. In other words, this is the block-by-block, remainder of the block reward after subtracting the subsidy and priced in BTC. Actually the first one is the only proxy reflecting the current and future promise of Bitcoin, while the second only reflects the present. Miners would be uniquely placed to know how best to vary the block size to maximize their profit resulting from these two prices. The fact that they are unable to is limiting their collective profits, reducing competition between miners and increasing the average tx fee for users. In that respect a dynamic block size voted on by miners periodically would go some way to rectify this inefficiency. This needn't have to happen on the block chain itself; we could have a continuous prediction market for the block size, and the informed participants (miners) would stand to profit from the uninformed from trading in such a market. How to get the block chain to use the block size thus determined is another technical matter. --001a11c3f026ea28f5051c8ce313 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 5= August 2015 at 09:33, Benjamin via bitcoin-dev <bitco= in-dev@lists.linuxfoundation.org> wrote:

A market means that demand and supply are ma= tched continuously, and Bitcoin has no such mechanism.

Not all markets need to have highly liquid trading outlet= s in order to be thought of as such. Inefficient markets are where there is= an imperfect matching mechanism.

I don't think a fee market exists and that d= emand or supply are not easily definable.

Demand and supply are reflected in the market in the following two pri= ces:

- BTC/USD

- Average transaction fee levels * Avera= ge transaction volume rate. In other words, this is the block-by-block, rem= ainder of the block reward after subtracting the subsidy and priced in BTC.=

Actually the first one is the only proxy reflecti= ng the current and future promise of Bitcoin, while the second only reflect= s the present. Miners would be uniquely placed to know how best to vary the= block size to maximize their profit resulting from these two prices. The f= act that they are unable to is limiting their collective profits, reducing = competition between miners and increasing the average tx fee for users.

In that respect a dynamic block size voted on by mine= rs periodically would go some way to rectify this inefficiency. This needn&= #39;t have to happen on the block chain itself; we could have a continuous = prediction market for the block size, and the informed participants (miners= ) would stand to profit from the uninformed from trading in such a market. = How to get the block chain to use the block size thus determined is another= technical matter.

--001a11c3f026ea28f5051c8ce313-- 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 4814067 for ; Wed, 5 Aug 2015 09:57:57 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C17317C for ; Wed, 5 Aug 2015 09:57:56 +0000 (UTC) Received: from mail-qg0-f48.google.com ([209.85.192.48]) by mrelay.perfora.net (mreueus002) with ESMTPSA (Nemesis) id 0Lm5DD-1YnJis3jrF-00ZheT for ; Wed, 05 Aug 2015 11:57:56 +0200 Received: by qged69 with SMTP id d69so25710467qge.0 for ; Wed, 05 Aug 2015 02:57:54 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.141.28.11 with SMTP id f11mr16290113qhe.78.1438768674891; Wed, 05 Aug 2015 02:57:54 -0700 (PDT) Received: by 10.96.226.68 with HTTP; Wed, 5 Aug 2015 02:57:54 -0700 (PDT) In-Reply-To: References: <1438640036.2828.0.camel@auspira.com>

Date: Wed, 5 Aug 2015 11:57:54 +0200 Message-ID: From: Adam Back To: Hector Chu Content-Type: text/plain; charset=UTF-8 X-Provags-ID: V03:K0:tO4FfUinjaBi1G7yHPsgNI2InOQv+0knko6Xk5WPmFS0j5TOwdZ Q9P87K0X2nIB+SSt9aWInE5fD52hVVPpxwjGlgvqsC3D2Dcl7MtEtOSQ5ngAMwHtb/JfWWT tulnKlcHu0QsGOkHtXicicRLTguQ4oy9pfEWMrzGgugWXIHOmeW2n/w9UHTevU+KaK9e9IJ Np5Ssts5FBeTz8REQtmsg== X-UI-Out-Filterresults: notjunk:1;V01:K0:vQiworOb6HA=:xlf7YvOG87GWE8aWmFq1+z 619k49x/sKSNf1//Gdw+boHMyv1/MPrmCUIgytgPaoJYUooYRISq4w/X3/OHa2OL0vccMO1oc N0P6CWNhGE65+I35Eh3xsHPp4OJ+3zqeP9k5JCOBTHyAyLpQ+yXy970EKXC8LtfClj06/royG uhQfa+e9IMNyGsCDtjWvikFhwPETOm2EQa7Gbb+mLj+7vQEW5qHZdn5xiU3Hkp39VihgjikN3 OLvfeBnCBRppSNzFxU6zW3mAQcnGgchXmRlmwtbTIV5rO6iNoYAmZkyOApzDJQbD4XXXDQ+Rn M0SNG3EP/it7Iunz5iVyw0Yq36Ctfd1Tr6vnr3Vti2qWoq8j5HY8y8XSMAdlXPVY9L9GBHhqP AhkMBsP+70rC9QUF72Av4tu+Oydj7Jn5x5aTymp8DW6ZVKES4U7L57V+82wL/6Ov4N11RAsjp JeaUlTzeTQ9biDE7UJ/Hcz2T6JBIxD2/LrE5cuELhtyi/SYebemU+5HNl/8Rw3K+MitmLHdkr +3V/Q8a79jdMe1GLv1c4W9Z9lfRMigrlBh2evA2MTsb6XUSSiH8XaYOIXrDUoIhVpoSS4pakw 5c5GNGVdeVGEVSahpcpHbprAw5C6TDrOIj9VPMdIZJT0WydCQkgrayBE3nwnbUQ51w9pP2D8z zdvowZrD09ZNduTB+qlrd4CwaCriq6f09HgEyDjTvSRhlzA== X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 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 09:57:57 -0000 On 5 August 2015 at 11:18, Hector Chu via bitcoin-dev wrote: > Miners would be uniquely placed to know how best to vary the block size to maximize their > profit resulting from these two prices. [...] > In that respect a dynamic block size voted on by miners periodically would > go some way to rectify this inefficiency. This kind of thing has been discussed here, even recently. It is not without problems. You may find the flexcap idea summarised in outline by Greg Maxwell and Mark Friedenbach a month or so back interesting in showing that one can achieve such effects without handing over a free vote to miners and hence avoid many (though probably not all) of the side-effects inherent in giving miners control. About side-effects, I think we can make argument that there are limits because other than in an extremis sense, miners are not necessarily in alignment with security, nor maximising user utility and value delivered. For example switching cost economics are common in networks (cell phone service pricing), maybe Bitcoin would have a really high switching cost if miners would cartelise. Also miners are in a complex game competing with each other, and this degree of control risks selfish mining issues or other cartel attacks or bandwidth/verification/latency related attacks being made worse. eg see the recent paper by Aviv Zohar. Generally speaking economically dependent full nodes are holding miners honest by design. Changing that dynamic by shifting influence can have security and control impacting side-effects, and needs to be thought about carefully. About security to try to make those comparisons a bit more formal I posted this taxonomy of types of security that proposals could be compared against, in order of security: 1. consensus rule (your block is invalid if you attack) 2. economic incentive alignment (you tend to lose money if you attack) 3. overt (attack possible but detectable, hence probably less likely to happen for reputation or market signal reasons even if possible anonymously) 4. meta incentive (assume people would not attack if they have an investment or interest in seeing Bitcoin continue to succeed) Adam 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 F3A2B899 for ; Wed, 5 Aug 2015 10:26:21 +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 CDBDC30 for ; Wed, 5 Aug 2015 10:26:20 +0000 (UTC) Received: from [192.168.1.85] ([84.97.181.71]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MIu7d-1ZOrq711Oz-002Ze9; Wed, 05 Aug 2015 12:26:18 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_82C09D11-AEC1-497F-BA05-2290BD7F7896" Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) From: Peter R In-Reply-To: Date: Wed, 5 Aug 2015 03:26:19 -0700 Message-Id: References: <1438640036.2828.0.camel@auspira.com>

To: Benjamin X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:3IMJPZbVabljXSJX5/w1OJU34P9vmROLmqJo5CbYn+BtMVTyreL EJwFAukAdj5C0p5CXPkCzIW41RQNdDhMbUsxnNygEqjJ7FqNwLojopY5vG7cHzHxsE3boRd HoQ0z0mvKsEnKAtMW2BljztLibeGAaC6dJFoZYhMzQP0dLlhVMLFDoSJhcL+D6N/iZLGuFw DJ51m8NRq39ufgF81Jbwg== X-UI-Out-Filterresults: notjunk:1;V01:K0:rQIM97N3c/s=:p55jXe8FYXfjxAi0eBaw9U TeefXLbCzLfU5RUG0hb9hh3Q6VRyn3rvrFvxTV+rnJgyOix0Y3MTVO+KExH+6lVs/Gz/0uykE EQIQLmhDAVdva7MlGoziRJgNeY95klMrNrzPVJ+Omz8rJdo/ltgpTSoPlzyiYcOdmWTIW2TkE oIWK8s9uojYtmBSMHzRzKRKn2nubeIm9zXO+gahXjWaQPk/RZ98cbzEvwgyPSaqR/ib+tBjf2 54SLZ7VwFoEEL5JFyKnQYTg2naKa3587BdgIfKjfsTEB7oq+yLcHYrJ/20h2jw3HjhTvoIts5 UAhP79QcCXYvHZguy2h2it6PlLxcZQVlYBS8enesVPohrJQBz80WtdA4ddykCogAMzlITFZBt zfaBoSp+EuzPAHiLgAJyC3pqWjsgBhySmXYMzAbF6xmhwiqPryibLWfOxRpQ/lCapDZ1SHrT3 sThE/d/JKR+/xRlhT2NeAD5/t9+b0aUMNj0jWF2YK8yfuBMG3GWt1xUAhBVA/RdwJQzTi8nkH 0hsQ+ds18jBfM2Wh7zekja7iPM2Yz0u/nDgdadim+BxUpJp3j0pIQ2EfpwLm/GBYUB//PwUOm mJHUsWC4kc9g+nglx81j5bIVGDl+d4mDU03KNSPHKDoJu0Lic9eAop0ljSjlCPlvnOH5gv1AB y2BOgyzks9gHG+tPv8maQLB09tVdxhcxpqbz1u390vkCoi+FXnDm32X7/HA4+y3eNAXU= 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 10:26:22 -0000 --Apple-Mail=_82C09D11-AEC1-497F-BA05-2290BD7F7896 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thank you for the feedback, Benjamin. > When you talk about a market, what are you referring to exactly? I define what I mean by healthy, unhealthy, and non-existent markets in = Section 7, and I show a figure to illustrate the supply and demand = curves in each of these three cases. A healthy market is defined as one = where a rational miner would be incentivized to produce a finite block. = An unhealthy market is one where a miner would be incentivized to = produce an arbitrarily large block. A non-existant market is one where = a miner is better off publishing an empty block. I show that so long as = block space in a normal economic commodity that obeys the Law of Demand, = and that the Shannon-Hartley theorem applies to the communication of the = block solutions between miners, that an unhealthy market is not = possible. =20 > A market means that demand and supply are matched continuously, and = Bitcoin has no such mechanism. Take a look at my definitions for the mempool demand curve (Sec 4) and = the block space supply curve (Sec 5). I show that the miner's profit is = a maximum at the point where the derivatives of these two curves = intersect. I think of this as when "demand and supply are matched." > ...I don't think a fee market exists and that demand or supply are not = easily definable. Do you not find the definitions presented in the paper for these curves = useful? The mempool demand curve represents the empirical demand = measureable from a miner=92s mempool, while the block space supply curve = represents the additional cost to create a block of size Q by accounting = for orphaning risk. =20 > Ideally supply of transaction capability would completely depend on = demand, and a price would exist such that demand can react to longterm = or shorterm supply constraints. Supply and demand do react. For example, if the cost to produce block = space decreases (e.g., due to improvements in network interconnectivity) = then a miner will be able to profitably include a greater number of = transactions in his block. =20 Furthermore, not only is there a minimum fee density below which no = rational miner should include any transactions as Gavin observed, but = the required fee density for inclusion also naturally increases if = demand for space within a block is elevated. A rational miner will not = necessarily include all fee-paying transactions, as urgent higher-paying = transactions bump lower-fee transactions out, thereby bidding up the = minimum fee density exponentially with demand. > In such a scenario there would be no scalability concerns, as scale = would be almost perfectly elastic. Agreed. =20 Best regards, Peter >=20 > On Tue, Aug 4, 2015 at 8:40 AM, Peter R via bitcoin-dev = wrote: > 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 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >=20 >=20 --Apple-Mail=_82C09D11-AEC1-497F-BA05-2290BD7F7896 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

When you talk about a market, what are you referring to = exactly?

I define what I mean by = healthy, unhealthy, and non-existent markets in Section 7, and I show a = figure to illustrate the supply and demand curves in each of these three = cases. A healthy market is defined as one where a rational miner = would be incentivized to produce a finite block. An unhealthy = market is one where a miner would be incentivized to produce an = arbitrarily large block. A non-existant market is one where a = miner is better off publishing an empty block. I show that so long = as block space in a normal economic commodity that obeys the Law of = Demand, and that the Shannon-Hartley theorem applies to the = communication of the block solutions between miners, that an unhealthy = market is not possible.

A market means that demand and = supply are matched continuously, and Bitcoin has no such = mechanism.

Take a look at my = definitions for the mempool demand curve (Sec 4) and the block space = supply curve (Sec 5). I show that the miner's profit is a maximum = at the point where the derivatives of these two curves intersect. = I think of this as when "demand and supply are = matched."

...I don't think a fee market exists and that demand or = supply are not easily definable. =

Do you not find the definitions = presented in the paper for these curves useful? The mempool demand = curve represents the empirical demand measureable from a miner=92s = mempool, while the block space supply curve represents the additional = cost to create a block of size Q by accounting for orphaning risk. =

Ideally supply of transaction capability would completely = depend on demand, and a price would exist such that demand can react to = longterm or shorterm supply = constraints.

Supply and demand do = react. For example, if the cost to produce block space decreases = (e.g., due to improvements in network interconnectivity) then a miner = will be able to profitably include a greater number of transactions in = his block.

Furthermore, not only is = there a minimum fee density below which no rational miner should include = any transactions as Gavin observed, but the required fee density for = inclusion also naturally increases if demand for space within a block is = elevated. A rational miner will not necessarily include all = fee-paying transactions, as urgent higher-paying transactions bump = lower-fee transactions out, thereby bidding up the minimum fee density = exponentially with demand.

In such a scenario there would be no = scalability concerns, as scale would be almost perfectly = elastic.

Agreed. =

Best = regards,

Peter

On= Tue, Aug 4, 2015 at 8:40 AM, 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.p= df

Or viewed with a web-browser = here:

https://www.scribd.com/doc/273443462/A-Transaction-Fee-M= arket-Exists-Without-a-Block-Size-Limit

Ab= stract. 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.li= nuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitco= in-dev

= --Apple-Mail=_82C09D11-AEC1-497F-BA05-2290BD7F7896-- 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 5CD1B89E for ; Wed, 5 Aug 2015 10:52:00 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8444230 for ; Wed, 5 Aug 2015 10:51:59 +0000 (UTC) Received: by labjt7 with SMTP id jt7so8428155lab.0 for ; Wed, 05 Aug 2015 03:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3cNAj24PKLNg84afvRfrMltHf2984HHfOZi9gW9CI9s=; b=ncV755gBbU5iBk0FleyANx7sYhq4DgsA9DDHIXswPNFxSKFg7UDNxxEl9lS5uIQJ0Y zz2iXivYZD2Rof0aQ6Skb0QNkR1PxiK1hbMub0XvD6tng5nNIvHeyDl7X0bMbOot/jDS +2hZ55shdjSVsiGDARmR4ohxoSF4hkHyNqLC4aLBI4ZLDZwOjD1VkldyCih+VRpOyhiL jYxU8qwbw106YkdS3/I/syrlrcIJ6huYKjOHGulrm6H+ntT77TVVK4OO+60ctKOVr+Zs Zd9QtyE2u1MvoNd8dhwrQwYRvXD9k3AH2DDshwt0Eixwp51ZnCzttxkItBLlgLPe9H6G ZkpA== X-Received: by 10.112.148.130 with SMTP id ts2mr8692466lbb.17.1438771917579; Wed, 05 Aug 2015 03:51:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.22.25 with HTTP; Wed, 5 Aug 2015 03:51:37 -0700 (PDT) In-Reply-To: References: <1438640036.2828.0.camel@auspira.com>

From: Hector Chu Date: Wed, 5 Aug 2015 11:51:37 +0100 Message-ID: To: Adam Back Content-Type: multipart/alternative; boundary=047d7b3a81ea0f6f71051c8e3192 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 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 10:52:00 -0000 --047d7b3a81ea0f6f71051c8e3192 Content-Type: text/plain; charset=UTF-8 On 5 August 2015 at 10:57, Adam Back wrote: > You may find the flexcap idea summarised in outline by Greg Maxwell > and Mark Friedenbach a month or so back interesting in showing that > one can achieve such effects without handing over a free vote to > miners and hence avoid many (though probably not all) of the > side-effects inherent in giving miners control. > The market I am thinking of would be open to all, not just miners. But miners would probably be best placed to profit from such a market, as it is their business to know about the revenue/costs tradeoff. About side-effects, I think we can make argument that there are limits > because other than in an extremis sense, miners are not necessarily in > alignment with security, nor maximising user utility and value > delivered. > If the block size was increasing at every settlement date (the dates on which, every 3 months say, the block size would be adjusted to the level indicated by the market) and users were getting concerned about centralization, the natural tendency would be for: a) The block size prediction market would tend to go back down. b) BTC/USD would tend to go down, reducing miner profit and indicating to them that the block size is too high. c) Transaction rate would decrease as some users stop using Bitcoin, also decreasing miner profit. --047d7b3a81ea0f6f71051c8e3192 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 5= August 2015 at 10:57, Adam Back <adam@cypherspace.org> w= rote:

You may find the flexcap idea summa= rised in outline by Greg Maxwell
and Mark Friedenbach a month or so back interesting in showing that
one can achieve such effects without handing over a free vote to
miners and hence avoid many (though probably not all) of the
side-effects inherent in giving miners control.

The market I am thinking of would be open to all, not just miners.= But miners would probably be best placed to profit from such a market, as = it is their business to know about the revenue/costs tradeoff.

About side-effects, I think we can make argument that there are limits
because other than in an extremis sense, miners are not necessarily in
alignment with security, nor maximising user utility and value
delivered.

If the block size was increa= sing at every settlement date (the dates on which, every 3 months say, the = block size would be adjusted to the level indicated by the market) and user= s were getting concerned about centralization, the natural tendency would b= e for:

a) The block size prediction market would tend to go back = down.

b) BTC/USD would tend to go down, reducing miner profit and= indicating to them that the block size is too high.

c) Transacti= on rate would decrease as some users stop using Bitcoin, also decreasing mi= ner profit.

--047d7b3a81ea0f6f71051c8e3192-- 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 9455889E for ; Wed, 5 Aug 2015 11:07:37 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 345D8106 for ; Wed, 5 Aug 2015 11:07:37 +0000 (UTC) Received: from mail-qg0-f46.google.com ([209.85.192.46]) by mrelay.perfora.net (mreueus002) with ESMTPSA (Nemesis) id 0MG8VV-1ZbUj90FWx-00FE9C for ; Wed, 05 Aug 2015 13:07:36 +0200 Received: by qgj62 with SMTP id 62so1319637qgj.2 for ; Wed, 05 Aug 2015 04:07:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.23.102 with SMTP id 93mr15290998qgo.61.1438772855179; Wed, 05 Aug 2015 04:07:35 -0700 (PDT) Received: by 10.96.226.68 with HTTP; Wed, 5 Aug 2015 04:07:35 -0700 (PDT) In-Reply-To: References: <1438640036.2828.0.camel@auspira.com>

Date: Wed, 5 Aug 2015 13:07:35 +0200 Message-ID: From: Adam Back To: Hector Chu Content-Type: text/plain; charset=UTF-8 X-Provags-ID: V03:K0:KepgIJDOLTWooDq8HESwA6vAL7TZMk5rsa+0HlPh2ztrRdb3eM1 CiMfKYmidaJJWqT3McZS1R5haKPwlqoJPEL3PuIDC+EY6W5CtVPumwA/RHQlLLwr3qhj3nW GGWHRwivO/aC6A6Ruc+jL2fDHUtRZzxTo98qNXw9QK6yQvILQcQs1/iFToDfCAOZAB1TyZa 2Bk3V5wN43JHhi9c/B01g== X-UI-Out-Filterresults: notjunk:1;V01:K0:73MDWcFkiag=:fxthw+SJIOFgEwsNNkN5Ea /+qFkzLAZ9Adx/0ehxxdFzvEqPw2QTnTyzdDQRMP4dVUzQ3eckTsXV5nRBDIIenPgsIuhQrEW HhJ+1oUGqTeKVUEHPet782QnZABss9Xi4idIVGZ/BSNuiXEZSiZR+novexydxe7nVgFQRMtR9 2rECyj2M8ufHau6K/CA00RcBkj0LM590etByXXn0c2+I3h4KtJvm1cevuh0IPJV4YwFtlnpy1 j1POODjqsO6ic38Xse0iL0DtvE64HbTjHkkpHcwpLQYA1ImPVBXMgkpl0bsGUTbyht3FCU1// Y7+gJZhBis7+ts+MlMr6oxlsYwKSE9XtZdEelsJL9LfmT/XH7MUYEdrIv/cZV5QknCZPFRatd C6ywS6E7e6xt6ZPNE6Ak8Z3/rCwsn3M6rt6YJm6RbGDfguIGD6gGA3tT9Wb9f8aSNWgXA3DKQ tb9rHTdSj8xfzK5kEoQdMG0rFq4jQeg25Siypkv4S3hhcKOj/5gpMQRxieEIHGLlj8rSg9OgM 1j6mUHl+2F0sjWTTYeme4NkBC0kzUoKYD9oj11+R26kRBvoVWDq9pOAyhFmWSFWmn/o3xjuHr m7DqPzkot9o8Ia+g8hEZNOpvKbYQixAQHx7oNOCc5Y6xUuTb89uplg/X1Bnb7JKlGiCvbAbyi 7Y2KCQRGPm/wsp9GkVGVj5wQbwp3t9kekx9GtU9Q3lPEDLw== X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 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 11:07:37 -0000 On 5 August 2015 at 12:51, Hector Chu wrote: > The market I am thinking of would be open to all, not just miners. But > miners would probably be best placed to profit from such a market, as it is > their business to know about the revenue/costs tradeoff. This prediction market in block-size seems like something extremely complex to operate and keep secure in a decentralised fashion. There are several experimental projects right now trying to figure out how to do this securely, using blockchain ideas, but it is early days for those projects. We also have no particular reason to suppose other than meta-incentive, that it should result in a secure parameter set. I suspect that, while it is interesting in the abstract, it risks converting a complex security problem into an even more complex one, rather than constituting an incremental security improvement which is more the context of day to day discussions here. Adam 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 88E9D8A7 for ; Wed, 5 Aug 2015 11:36:16 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CB0007C for ; Wed, 5 Aug 2015 11:36:15 +0000 (UTC) Received: by labow3 with SMTP id ow3so26693646lab.1 for ; Wed, 05 Aug 2015 04:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kk6wAmKz8KIxeaC19u9wE4hvK1iKs86sGrEqa4nBXFQ=; b=wOX8GHUaIrcjlQ9IfNxlTv4K4mw0lZWKYGOVsswOJpC81WTcxpXHWcfcgLYR5B6fWQ SyME37dskfDIasgx3C2ke6aJqEnZzLDt9HStnO2oslweWWYNM/62cm4hcuU9r/0p0E5e WoIqWeT4T+AZnjIfbJAHaeQMI/CcS59hbvCDUbjbqzS4e8eeftRqBzyDnp4fEF86Gb+R eWN1CJdHsU6iE19PcNWMnNj1EmxvMXDwHRZf3LnX0d04xNnH80Rc7WTy1uGJMUeyrhYq buKgnZ9OesmOO9hMQO/pNh70TohjG/12qlTizAT7iBpEy6cGT9VpUN+p6wB3cqSJOhAy THJw== X-Received: by 10.112.77.103 with SMTP id r7mr8721022lbw.63.1438774573564; Wed, 05 Aug 2015 04:36:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.22.25 with HTTP; Wed, 5 Aug 2015 04:35:53 -0700 (PDT) In-Reply-To: References: <1438640036.2828.0.camel@auspira.com>

From: Hector Chu Date: Wed, 5 Aug 2015 12:35:53 +0100 Message-ID: To: Adam Back Content-Type: multipart/alternative; boundary=001a11c3f0265e88ed051c8ecf4d X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 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 11:36:16 -0000 --001a11c3f0265e88ed051c8ecf4d Content-Type: text/plain; charset=UTF-8 On 5 August 2015 at 12:07, Adam Back wrote: > This prediction market in block-size seems like something extremely > complex to operate and keep secure in a decentralised fashion. Why would it need to be decentralised? Bitcoin.org could run the exchange, and the profits from the exchange could be used to fund Core development. We also have no particular reason to suppose other than > meta-incentive, that it should result in a secure parameter set. > Security is a continuous variable, trading off against others. If security gradually begins to be threatened as a result of block size gradually increasing, the concerns of users will be enough that the bears will gain control over the bulls on the block size market. I suspect that, while it is interesting in the abstract, it risks > converting a complex security problem into an even more complex one, > rather than constituting an incremental security improvement which is > more the context of day to day discussions here. Hard problems call for complex solutions. --001a11c3f0265e88ed051c8ecf4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 5= August 2015 at 12:07, Adam Back <adam@cypherspace.org> w= rote:

This prediction market in block-siz= e seems like something extremely
complex to operate and keep secure in a decentralised fashion.

Why would it need to be decentralised? Bitcoin.org coul= d run the exchange, and the profits from the exchange could be used to fund= Core development.

We al= so have no particular reason to suppose other than
meta-incentive, that it should result in a secure parameter set.

Security is a continuous variable, trading off ag= ainst others. If security gradually begins to be threatened as a result of = block size gradually increasing, the concerns of users will be enough that = the bears will gain control over the bulls on the block size market.
<= div>

I suspect that, while it is interesting in the abstract, it risks
converting a complex security problem into an even more complex one,
rather than constituting an incremental security improvement which is
more the context of day to day discussions here.

Hard problems call for complex solutions.=C2=A0

--001a11c3f0265e88ed051c8ecf4d-- 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 1C42B89E for ; Wed, 5 Aug 2015 13:28:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6240113A for ; Wed, 5 Aug 2015 13:28:30 +0000 (UTC) Received: by pdrh1 with SMTP id h1so803708pdr.0 for ; Wed, 05 Aug 2015 06:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=L/JV4nTLz1HGhnVJnJb6wYpIX6TBcgHb/zfH2czELJU=; b=qKEGA67uaWIJChZb8tnK4oQaZI/Ucp0CT6HUuoHZNfO+R7RXClq0XzitmtHV9FIe8X cHD9yfc3yLKYdp/EkjJ9x1IkNxR/WWFVpx7GE/CQ7T+2MoOBvBATBayuYUesVwcHg+cR jDhBpjgL7ucwkog0644ktf8BbeiC0Ob66INDqnGBbvBdBN129HTiuCNSCY0R+hpuXf5y b9uiFTkChBxFn0ysDnsJiPan2xtmcqn+ZxxGmrdczhLI5BSdEkZ/oHYVFDwCiaTOhlgM MtJRP3zdvwt/uRX7cxX7ViFo6RzV3DtjpJnth7YKeZmAWEaj+54NSTo68RH7UvKAtaAX 3cxg== X-Received: by 10.70.50.165 with SMTP id d5mr19769998pdo.93.1438781310112; Wed, 05 Aug 2015 06:28:30 -0700 (PDT) Received: from mail.outlook.com (ec2-54-149-197-188.us-west-2.compute.amazonaws.com. [54.149.197.188]) by smtp.gmail.com with ESMTPSA id dc8sm2979789pdb.23.2015.08.05.06.28.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Aug 2015 06:28:29 -0700 (PDT) Date: Wed, 5 Aug 2015 13:28:27 +0000 (UTC) From: Mashuri Clark To: bitcoin-dev@lists.linuxfoundation.org, Owen , Eric Lombrozo Message-ID: <207C5360C6E6B691.029C42D2-8BAC-43F4-A8B3-CD9B9EAAA319@mail.outlook.com> In-Reply-To: <835E3F90-C057-4240-9EB6-D2C7400B662B@gmail.com> References:

<5A323AB6-914C-4FF5-9FC2-AB8E02C69F93@phauna.org> <835E3F90-C057-4240-9EB6-D2C7400B662B@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10069_1280351723.1438781307927" X-Mailer: Outlook for iOS and Android X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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: Anthony Towns via bitcoin-dev Subject: Re: [bitcoin-dev] Eli Dourado on "governance" 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 13:28:31 -0000 ------=_Part_10069_1280351723.1438781307927 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable CORRECTION: That's Paul Sztorc. Not Peter. =C2=A0Apologies for my abysmal p= roofreading. -- MC On Tue, Aug 4, 2015 at 8:08 PM -0700, "Eric Lombrozo via bitcoin-dev" wrote: Rather than speculating on fake markets, why don=E2=80=99t we use theory, e= mpirical data, and engineering to fix the damn problems? On Aug 4, 2015, at 11:28 AM, Owen via bitcoin-dev wrote: Given there is no money at stake in these prediction games, it is no surpri= se that the results are implausible. On August 4, 2015 10:22:19 AM EDT, Anthony Towns via bitcoin-dev wrote: On 4 August 2015 at 01:22, Gavin Andresen via bitcoin-dev wrote: And the preliminary results of using a prediction market to try to wrestle = with the tough tradeoffs looks roughly correct to me, too:=C2=A0 =C2=A0http= s://blocksizedebate.com/ =E2=80=8BThe scicast prediction market is shutdown atm (since early July?) = so those numbers aren't live. But... Network hash rate 3,255.17 PH/s =C2=A0(same block size) 5,032.64 PH/s =C2=A0(block size incr= ease) 4,969.68 PH/s =C2=A0(no replace-by-fee) 3,132.09 PH/s =C2=A0(replace-by-fee) Those numbers seem completely implausible: that's ~2.9-3.6 doublings of the= current hashrate (< 400PH/s) in 17 months, when it's taken 12 months for t= he last doubling, and there's a block reward reduction due in that period t= oo. (That might've been a reasonable prediction sometime in the past year, = when doublings were slowing from once every ~45 days to once a year; it jus= t doesn't seem a supportable prediction now) That the PH/s rate is higher with bigger blocks is surprising, but given th= at site also predicts USD/BTC will be $280 with no change but $555 with big= ger blocks, so I assume that difference is mostly due to price. Also, 12.5b= tc at $555 each is about 23 btc at $300 each, so if that price increase is = realistic, it would compensate for almost all of the block reward reduction= . Daily transaction volume 168,438.22 tx/day =C2=A0(same block size) 193,773.= 08 tx/day =C2=A0(block size increase) 192,603.80 tx/day =C2=A0(no replace-by-fee) 168,406.73 tx/day =C2=A0(repla= ce-by-fee) That's only a 15% increase in transaction volume due to the block size incr= ease; I would have expected more? 168k-194k tx/day is also only a 30%-50% i= ncrease in transaction volume from 130k tx/day currently. If that's really = the case, then a 1.5MB-2MB max block size would probably be enough for the = next two years... (Predicting that the node count will drop from ~5000 to ~1200 due to increa= sing block sizes seems quite an indictment as far as centralisation risks g= o; but given I'm not that convinced by the other predictions, I'm not sure = I want to give that much weight to that one either) Cheers,aj --=20 Anthony Towns bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ------=_Part_10069_1280351723.1438781307927 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

CORRECTION: That's Paul Sztorc. Not Peter. &n= bsp;Apologies for my abysmal proofreading.

--
MC

On Tue, Aug 4, 2015 at 8:08 PM -0700, "Eric= Lombrozo via bitcoin-dev" <bitcoin-dev@lists.lin= uxfoundation.org> wrote:

R= ather than speculating on fake markets, why don=E2=80=99t we use theory, em= pirical data, and engineering to fix the damn problems?
On A= ug 4, 2015, at 11:28 AM, Owen via bitcoin-dev <bitcoin-dev@lists.linuxfoundatio= n.org> wrote:
Given there is no money at stake in these predicti= on games, it is no surprise that the results are implausible.
On August 4, 2015 10:22:19 A= M EDT, Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org= > wrote:
On 4 = August 2015 at 01:22, Gavin Andresen via bitcoin-dev <bitcoin= -dev@lists.linuxfoundation.org> wrote:
=
And the preliminary results of = using a prediction market to try to wrestle with the tough tradeoffs looks = roughly correct to me, too:
https://blocksized= ebate.com/
=E2=80=8BThe scicast prediction market is shutdown atm (since early Ju= ly?) so those numbers aren't live. But...

Network hash rat= e
3,255.17 PH/s (same blo= ck size)
5,032.64 PH/s (block size incre= ase)

4,969.68 PH/s (no replace-by-fee)
3= ,132.09 PH/s (replace-by-fee)

Those numbers see= m completely implausible: that's ~2.9-3.6 doublings of the current hashrate= (< 400PH/s) in 17 months, when it's taken 12 months for the last doubli= ng, and there's a block reward reduction due in that period too. (That migh= t've been a reasonable prediction sometime in the past year, when doublings= were slowing from once every ~45 days to once a year; it just doesn't seem= a supportable prediction now)

That the PH/s rate i= s higher with bigger blocks is surprising, but given that site also predict= s USD/BTC will be $280 with no change but $555 with bigger blocks, so I ass= ume that difference is mostly due to price. Also, 12.5btc at $555 each is a= bout 23 btc at $300 each, so if that price increase is realistic, it would = compensate for almost all of the block reward reduction.

Dai= ly transaction volume
168,438.22 tx/day (same block size)
193,773.08 tx/day (= block size increase)

192,603.80 tx/day &nb= sp;(no replace-by-fee)
168,406.73 tx/day (= replace-by-fee)
<= span style=3D"font-family:monospace" class=3D"">
That's only a 15% increase in transaction v= olume due to the block size increase; I would have expected more? 168k-194k= tx/day is also only a 30%-50% increase in transaction volume from 130k tx/= day currently. If that's really the case, then a 1.5MB-2MB max block size w= ould probably be enough for the next two years...

=
(Predictin= g that the node count will drop from ~5000 to ~1200 due to increasing block= sizes seems quite an indictment as far as centralisation risks go; but giv= en I'm not that convinced by the other predictions, I'm not sure I want to = give that much weight to that one either)

<= /div>
Cheer= s,
aj

-- <= br class=3D"" />
Anthony Towns <aj@erisian.com.au>
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
=
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
____________________________________= ___________
bitcoin-dev mailing list
bitcoin-dev@l= ists.linuxfoundation.org
https://lists.linuxfoundation.= org/mailman/listinfo/bitcoin-dev
<= br class=3D"" />

------=_Part_10069_1280351723.1438781307927-- 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 825C689F for ; Wed, 5 Aug 2015 19:05:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1F6FE220 for ; Wed, 5 Aug 2015 19:05:07 +0000 (UTC) Received: by labow3 with SMTP id ow3so35081172lab.1 for ; Wed, 05 Aug 2015 12:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WNu4ZSXP1x7y/cSGoBlkJi5mIyJPn1Jlm6XtZGoNarE=; b=otVgPu9q38K69e3iLbADkkW9fT583VdwkEqYZX4+RNYrscTiMU62SJv6z+lEPb+4BJ glM9uvu9YcpDkbIyQFTw9oUDpL1tUS4w8KQTUERXNidfBLCmoonFvl0Din4v2vWbHvwF 8x1CLkaFSUHUnBtFirp2tFeEA+Su0r8xZaow7uKVaA802wqFktEn//Wz3CO0oxbMCikW XPyT7cepd1cZvAPZlZKB7pwkNcDh2vY6ZQNuriBB43sk88nYd4FhOi7d5YS25ANlyEqC 5k0gEPRAEdoEAjipcbF/fmKxdocbIbv4ZmFxqgT5+a0KAmS6P5EhisaToO7H/TKs7c91 uVTg== X-Received: by 10.152.30.100 with SMTP id r4mr10635031lah.92.1438801505393; Wed, 05 Aug 2015 12:05:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.22.25 with HTTP; Wed, 5 Aug 2015 12:04:35 -0700 (PDT) In-Reply-To: References: <1438640036.2828.0.camel@auspira.com>

From: Hector Chu Date: Wed, 5 Aug 2015 20:04:35 +0100 Message-ID: To: Adam Back Content-Type: multipart/alternative; boundary=089e0158cba0a1a44a051c951435 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 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 19:05:08 -0000 --089e0158cba0a1a44a051c951435 Content-Type: text/plain; charset=UTF-8 To put some flesh on the bones of this idea, imagine a hypothetical security named BLK. Demand for bigger blocks should buy up BLK and demand for smaller blocks should short BLK. The price of BLK in BTC is the ideal block size. Now imagine that there are futures contracts for the security BLK. On the settlement date of those futures the current BLK/BTC price of those futures is taken to be the new Bitcoin block size for the next 3 months. For instance, if I predict or want the block size to be higher on September than it currently is, I would buy up September BLK futures. My actions would nudge the price up, and if come September I am right I get what I want and have a floating profit on the futures market. The nice thing about a futures market is that it allows capacity planning for the months ahead. Also there is no need for an underlying BLK security for a futures market in BLKs to exist. If the market is efficient and correctly sets the block size, BTC/USD will rise and the BTC profits of the market participants will go up in USD terms as a result. On 5 August 2015 at 12:35, Hector Chu wrote: > On 5 August 2015 at 12:07, Adam Back wrote: > >> This prediction market in block-size seems like something extremely >> complex to operate and keep secure in a decentralised fashion. > > > Why would it need to be decentralised? Bitcoin.org could run the exchange, > and the profits from the exchange could be used to fund Core development. > > We also have no particular reason to suppose other than >> meta-incentive, that it should result in a secure parameter set. >> > > Security is a continuous variable, trading off against others. If security > gradually begins to be threatened as a result of block size gradually > increasing, the concerns of users will be enough that the bears will gain > control over the bulls on the block size market. > > I suspect that, while it is interesting in the abstract, it risks >> converting a complex security problem into an even more complex one, >> rather than constituting an incremental security improvement which is >> more the context of day to day discussions here. > > > Hard problems call for complex solutions. > --089e0158cba0a1a44a051c951435 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

To put some flesh on the bones of this idea, imagine a hyp= othetical security named BLK. Demand for bigger blocks should buy up BLK an= d demand for smaller blocks should short BLK. The price of BLK in BTC is th= e ideal block size.

Now imagine that there are futures contracts for th= e security BLK. On the settlement date of those futures the current=C2=A0BL= K/BTC=C2=A0price of those futures is taken to be the new Bitcoin block size= for the next 3 months.

For instance, if I predict or want the bl= ock size to be higher on September than it currently is, I would buy up Sep= tember BLK futures. My actions would nudge the price up, and if come Septem= ber I am right I get what I want and have a floating profit on the futures = market.

The nice thing about a futures market is that it allows c= apacity planning for the months ahead. Also there is no need for an underly= ing BLK security for a futures market in BLKs to exist.

If the ma= rket is efficient and correctly sets the block size, BTC/USD will rise and = the BTC profits of the market participants will go up in USD terms as a res= ult.

O= n 5 August 2015 at 12:35, Hector Chu <hectorchu@gmail.com>= wrote:

On 5 August 2015 at = 12:07, Adam Back <adam@cypherspace.org> wrote:
This prediction market in block-size seems like som= ething extremely
complex to operate and keep secure in a decentralised fashion.

Why would it need to be decentralised? Bitcoin.o= rg could run the exchange, and the profits from the exchange could be used = to fund Core development.

We also have no particular reason to suppose other than<= br> meta-incentive, that it should result in a secure parameter set.

Security is a continuous variable, trading= off against others. If security gradually begins to be threatened as a res= ult of block size gradually increasing, the concerns of users will be enoug= h that the bears will gain control over the bulls on the block size market.=

I suspect that, while it is interesting in the abstract, it risks
converting a complex security problem into an even more complex one,
rather than constituting an incremental security improvement which is
more the context of day to day discussions here.

Hard problems call for complex solutions.=C2=A0

--089e0158cba0a1a44a051c951435-- 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 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-- 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 88EC57AE for ; Wed, 5 Aug 2015 22:44:24 +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 B721A1A9 for ; Wed, 5 Aug 2015 22:44:23 +0000 (UTC) Received: from [207.140.24.78] (port=43894 helo=[10.0.0.145]) by heron.directrouter.co.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1ZN7Q5-001YL2-LE; Wed, 05 Aug 2015 22:44:21 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 $2102$) From: Dave Hudson In-Reply-To: <7F9283D5-5F0F-4318-BE64-A1C20A5B7606@gmx.com> Date: Wed, 5 Aug 2015 15:44:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2312E340-EA7D-48DC-B3FF-319D6AF9E955@hashingit.com> References: <1438640036.2828.0.camel@auspira.com>

<3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com> <7F9283D5-5F0F-4318-BE64-A1C20A5B7606@gmx.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 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:44:24 -0000 >=20 > On 5 Aug 2015, at 15:15, Peter R wrote: >=20 > Hi Dave, >=20 > Thank you for the feedback regarding my paper. =20 >=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. >=20 > 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. I think this would be really interesting. It's an area that seems to be = lacking research. While I've not had time to model it I did have a quick discussion with = the author of the Organ-of-Corti blog a few months ago and he seemed to = think that the Poisson process model isn't quite accurate here. = Intuitively this makes sense as until a block has fully propagated we're = only seeing some fraction of the actual hashing network operating on the = same problem, so we actually see slightly fewer very quick blocks than = we might expect. I do suspect that if we were to model this more accurately we might be = able to infer the "typical" propagation characteristics by measuring the = deviation from the expected distribution. >> 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. >=20 > 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. \ Agreed - I think this would be really interesting! >> 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. >=20 > 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). I really look forward to seeing the revised version. Seeing the = differences will also help assess how much impact there is from = simplified models. Regards, Dave 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 0E6ED83D for ; Wed, 5 Aug 2015 23:45:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7C43B14C for ; Wed, 5 Aug 2015 23:45:55 +0000 (UTC) Received: by pawu10 with SMTP id u10so47339001paw.1 for ; Wed, 05 Aug 2015 16:45:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=XlILZrKhqjXyFyz69Yxl22+TtdKvA7RSWTrz41AlgKM=; b=SwXqJpBGOD53D4TaRPWCb5+VbRS8CebOvPFtrfg9ovmQj/5p5PN2KH6CRHSANBUrdt ZylC0caP6VYwhY2/7jpjcy3IYbggFCOltA2+wchzErtAeEBocQqDaoFRHNTPs3ypbXbE ioIE7VPSXoVn68nWVI+OPIg9UCuZpQ1nWIcoAE8Hl3Dd0qek+SwIeEDq+F+aLFZlGbBf g90Sfff2M83BuZ4uL2DYvcNsWYPNOF2zsoeAHp1DjsNdIUX/7Z36DKIXe/8hVyla4Z27 OR5lV4OokT5l80OOgJIVFEmAYJwHVqPOg2idNVu+VGKBnJTs+mhx47d/kcMoNIxi+3Am I7YQ== X-Gm-Message-State: ALoCoQnmyoA4nrBwh86zXPdSl8KUM5LVFLpgk9Db6SK1tRnvoNo0IfczW1V/dTY/Q+Q1S6UFC93H X-Received: by 10.68.173.97 with SMTP id bj1mr24543510pbc.122.1438818355215; Wed, 05 Aug 2015 16:45:55 -0700 (PDT) Received: from [10.100.1.239] ([204.58.254.99]) by smtp.googlemail.com with ESMTPSA id p1sm4179817pdb.3.2015.08.05.16.45.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 16:45:53 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: <1438640036.2828.0.camel@auspira.com>

<3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com> <7F9283D5-5F0F-4318-BE64-A1C20A5B7606@gmx.com> <2312E340-EA7D-48DC-B3FF-319D6AF9E955@hashingit.com> From: Tom Harding Message-ID: <55C2A012.7080908@thinlink.com> Date: Wed, 5 Aug 2015 16:45:22 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <2312E340-EA7D-48DC-B3FF-319D6AF9E955@hashingit.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_WEB autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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 23:45:56 -0000 On 8/5/2015 3:44 PM, Dave Hudson via bitcoin-dev wrote: > I do suspect that if we were to model this more accurately we might be > able to infer the "typical" propagation characteristics by measuring > the deviation from the expected distribution. The paper models propagation using a single time value that is a function of block size. Modeling the propagation distribution (which is totally separate from the poisson model of block production) would add a lot of complexity and my guess is the outcome would be little changed. >> On 5 Aug 2015, at 15:15, Peter R wrote: >> 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. Why complicate the analysis by assuming that a miner who finds two blocks sequentially does not publish the first, or that other miners would orphan miner's first block unless both were very quick? In general you don't consider anything beyond 1 block in the future, which seems fine. >>> 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). Correcting for non-orphaning of one's own blocks could be as simple as adding a factor (1 - h/H) to equation 4, which it appears would leave hashpower as an independent variable in the results. But at worst, the discussion can be considered to apply directly only to low-hashpower miners right now. Overall, the paper does not predict big changes to per/kb fees or spam costs for the kinds of block sizes being discussed for the immediate future (8MB). But it does conclude that these fees will rise, not fall, with bigger blocks. Also it is welcome that this paper actually mentions the bitcoin exchange rate as a factor in relation to block size (it points out that a spam attack is much more expensive in fiat terms today than it was years ago). 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 C228C83D for ; Fri, 7 Aug 2015 16:26:36 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from manxnetsf05.manx.net (outbound.manx.net [213.137.31.12]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C84B414B for ; Fri, 7 Aug 2015 16:26:35 +0000 (UTC) Received: from 195.10.99.101 (EHLO coldstorage.localnet) ([195.10.99.101]) by manxnetsf05.manx.net (MOS 4.4.5a-GA FastPath queued) with ESMTP id EFT77864; Fri, 07 Aug 2015 17:26:33 +0100 (BST) From: Thomas Zander To: Bitcoin Dev Date: Fri, 07 Aug 2015 18:26:32 +0200 Message-ID: <5856715.iKN6YjXc3K@coldstorage> User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Mirapoint-Received-SPF: 195.10.99.101 coldstorage.localnet thomas@thomaszander.se 5 none X-Junkmail-Status: score=10/50, host=manxnetsf05.manx.net X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.55C4DC39.01C4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-07-29 09:23:55, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.55C4DC39.01C4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-07-29 09:23:55, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2faf161b69436b8a843c2fe4706581e3 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 Subject: Re: [bitcoin-dev] Eli Dourado on "governance" 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: Fri, 07 Aug 2015 16:26:36 -0000 On Monday 3. August 2015 11.22.14 Gavin Andresen via bitcoin-dev wrote: > (my only big disagreement with those predictions is the 'Number of nodes' > -- I don't think replace-by-fee would affect that number, and I think even > with no change we will see the number of full nodes on the network drop to > a couple thousand, because the general-purpose-home-PC is headed the way of > the dodo [] On the other hand, things like the Raspberry PI and similar hardware are gaining ground fast. And they can run a node just fine. I have many friends that run such small hardware for things like Owncloud.org because it is decentralized. When Bitcoin gets traction with these people, I have no doubt a nice portion of them will run a node for the same reason they are running their private cloud. Trust No One. Or, in other words, when Bitcoin grows in popularity and more people find it interesting (and we fix longstanding issues in Core), the desktop node that eventually get shut down will be replaced with the next generation hardware of a different kind of Bitcoin user. -- Thomas Zander 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 4970A898 for ; Sun, 30 Aug 2015 20:09:02 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B5742194 for ; Sun, 30 Aug 2015 20:09:01 +0000 (UTC) Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LbMmA-1Ypu8x1mKQ-00kugV; Sun, 30 Aug 2015 22:08:58 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_A626710B-3D53-4A85-A348-EDDCB866C4AA" Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) From: Peter R In-Reply-To: Date: Sun, 30 Aug 2015 13:08:58 -0700 Message-Id: <8A71E9FB-1901-4044-B2E0-04DEFE58C045@gmx.com> References: <1438640036.2828.0.camel@auspira.com>

<6ED57388-6EC3-4515-BF3F-E753301537AB@gmx.com>

<6FED5604-4A6F-4CE1-B42E-36626375D557@gmx.com> <6BA86443-7534-4AAA-92BC-EC9B1603DE5F@gmx.com> <27B16AB4-0DAD-4665-BF08-7A0C0A70D8D8@gmx.com>

To: Daniele Pinna X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:/ZabFh+n39582WQLCDbu7wty47zHLtVnVi94ZYejCKkA1Af4xIB 2srNeFdmGqEa7MuDqJuyTrn4Z7j6NCoGOx6CVU3bgu1kSRExzuEpEf1lS6nzipeyEVCQlhl B2Wo0BzjrkyYerpwHyXqyT3aNLvEmQEaT3jXza/WfVkzAHP2ba725MywWSW704+3vSGYBNG wBuKqPKQA9QpC+ZV8bAcw== X-UI-Out-Filterresults: notjunk:1;V01:K0:GyaF/VlvWj8=:yDzYf1TYampC1icUXow7AK mivz2RGMqOGvCeTK0ydckO81lYatkz+iG3UsDN/rueJNig+r4oNSmP97xaI6CB3YlSI4WDik0 rxN8Oumx+FKckT8vieJtsfBamopiF0jqbs4IvgKA5D1i40ftyAnbrwY5MGlzOFJO4damF2Cmb Lex9hqesScW+Pwx01P5fTBTkFBCXS3gD44is11cXpwbdq6mETSYsLjawgMSxpIO2ZD1fHgy94 h8751xmKyaEsUDbQT3MewvwNRi5dlDtAN6k68mbuP16qOzD8X6K2Tff75bfxrD/0YsW7jNfju gjDhN29VMxkhLaRcZduzZ/julvcuMU45oicMHhEISYSgWB9Xl5Y8tJVC6a1YaIYOSFTSnM3L4 jdG1AvqIrgDD2SHx5OyJaYIwO5zOXW1uXw2EF0ngorzfMwiTaYoxyRDnCTXVaeOXHa0RimAUa sRkHNvgISEPfVkZpDOQdEu4oTwMP3TgQdNauspQF/YDkRWdrPuH/mrXvwL4JnGMl7KVgB8cFY XMAO9d4LdZYmvxbhM0rnTsCdYGMbka6MP691tuiuS0ZDfBIbUB1uxJUrpsJS1d8Hs795ascEy F7UqdF7vgBQuqiuQCSb3zkKlq2hwBQeGKrI6x9OQLsdFi8UFXrDyN5jKjDMGd9+AZZ87dUZ3Z Ux8fpnlVpZ+MtHjsYFkj4D+w4wCvS9zLQAlJCRH0xJNb/E6hPTKw+5wMcPFqRdDN5/fZIq8tM XEDrjQYsft0bd4vjX/3If4svfIXuBM7nZqnGTw== X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, 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] "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: Sun, 30 Aug 2015 20:09:02 -0000 --Apple-Mail=_A626710B-3D53-4A85-A348-EDDCB866C4AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Daniele, I don't think there is any contention over the idea that miners that = control a larger percentage of the hash rate, h / H, have a = profitability advantage if you hold all the other variables of the = miner's profit equation constant. I think this is important: it is a = centralizing factor similar to other economies of scale. =20 However, that is outside the scope of the result that an individual = miner's profit per block is always maximized at a finite block size Q* = if Shannon Entropy about each transaction is communicated during the = block solution announcement. This result is important because it = explains how a minimum fee density exists and it shows how miners cannot = create enormous spam blocks for "no cost," for example. =20 Best regards, Peter > 2) Whether it's truly possible for a miner's marginal profit per unit = of hash to decrease with increasing hashrate in some parametric = regime.This however directly contradicts the assumption that an optimal = hashrate exists beyond which the revenue per unit of hash v' < v if h' = > h.=20 > Q.E.D=20 >=20 > This theorem in turn implies the following corollary: >=20 > COROLLARY: The marginal profit curve is a monotonically increasing of = miner hashrate. >=20 > This simple theorem, suggested implicitly by Gmaxwell disproves any = and all conclusions of my work. Most importantly, centralization = pressures will always be present.=20 --Apple-Mail=_A626710B-3D53-4A85-A348-EDDCB866C4AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Daniele,

I don't think there is any contention over = the idea that miners that control a larger percentage of the hash rate, = h / H, have a profitability advantage if you hold all the = other variables of the miner's profit equation constant. I think = this is important: it is a centralizing factor similar to other = economies of scale.

However, that is = outside the scope of the result that an individual miner's profit per = block is always maximized at a finite block size Q* if Shannon Entropy = about each transaction is communicated during the block solution = announcement. This result is important because it explains how a = minimum fee density exists and it shows how miners cannot create = enormous spam blocks for "no cost," for example. =

Best = regards,

Peter

2) Whether it's truly possible for a miner's = marginal profit per unit of hash to decrease with increasing hashrate in = some parametric regime.This however directly contradicts the = assumption that an optimal hashrate exists beyond which the revenue per = unit of hash v' < v if h' > = h.

This theorem in turn implies the following = corollary:

COROLLARY: The marginal profit curve = is a monotonically increasing of miner hashrate.

This simple theorem, = suggested implicitly by Gmaxwell disproves any and all conclusions of my = work. Most importantly, centralization pressures will always be = present.

= --Apple-Mail=_A626710B-3D53-4A85-A348-EDDCB866C4AA-- 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 C155B486 for ; Sun, 30 Aug 2015 21:03:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 917CAE2 for ; Sun, 30 Aug 2015 21:03:09 +0000 (UTC) Received: by lbvd4 with SMTP id d4so15021269lbv.3 for ; Sun, 30 Aug 2015 14:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aNLpUpi10xZ1CezDtJ2+AIFHuaLE14JhjN+1+G7UXzw=; b=XIoItiHGaNrgKr3g3FOgXe3iCbcxEV6Xs704oKYwgIxlY42PaYqap7uAI/GMT3Ynal kx/T4lWnE4uZTPNtjMcH00tKtsj6Csc2/qMH1rjuvXhAJGz1GWW/RzrhabqcGS2iuL8x q30j70IsJRfTJHf2uG7ghAUOVvWOwuwUOP3JzEpQyaZL3b31xmsRBEk3E82lNtWYRkS9 xs78DRVLMmsLOwh3/0wrP3Z/mbZbSjVDLxNo4vre5yQnodDd5WEPl62lEkV588nPS/xE 2MJjzNfVY6Fpf52hEhemJ91NenqDwUqEedMUowb6RSVONzYemgjawnxiGvPUN6naUS8d PoHw== X-Received: by 10.152.6.73 with SMTP id y9mr9050949lay.45.1440968587485; Sun, 30 Aug 2015 14:03:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.143.229 with HTTP; Sun, 30 Aug 2015 14:02:48 -0700 (PDT) In-Reply-To: <8A71E9FB-1901-4044-B2E0-04DEFE58C045@gmx.com> References: <1438640036.2828.0.camel@auspira.com>

<6ED57388-6EC3-4515-BF3F-E753301537AB@gmx.com>

<6FED5604-4A6F-4CE1-B42E-36626375D557@gmx.com> <6BA86443-7534-4AAA-92BC-EC9B1603DE5F@gmx.com> <27B16AB4-0DAD-4665-BF08-7A0C0A70D8D8@gmx.com>

<8A71E9FB-1901-4044-B2E0-04DEFE58C045@gmx.com> From: Daniele Pinna Date: Sun, 30 Aug 2015 23:02:48 +0200 Message-ID: To: Peter R Content-Type: multipart/alternative; boundary=089e01494220ca2dcd051e8da4da X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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] "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: Sun, 30 Aug 2015 21:03:10 -0000 --089e01494220ca2dcd051e8da4da Content-Type: text/plain; charset=UTF-8 "However, that is outside the scope of the result that an individual miner's profit per block is always maximized at a finite block size Q* if Shannon Entropy about each transaction is communicated during the block solution announcement. This result is important because it explains how a minimum fee density exists and it shows how miners cannot create enormous spam blocks for "no cost," for example. " Dear Peter, This might very well not be the case. Since the expected revenue ** in our formulas is but a lower bound to the true expected revenue, and the fee supply curve [image: M_s(Q)\propto 1/\langle V\rangle], if the true expected revenue doesn't decay faster than the mempool's average transaction fee (or, more simply, if it doesn't decay to zero) then the maximum miner surplus will be unbounded and unhealthy fee markets will emerge. Best, Daniele Daniele Pinna, Ph.D On Sun, Aug 30, 2015 at 10:08 PM, Peter R wrote: > Hi Daniele, > > I don't think there is any contention over the idea that miners that > control a larger percentage of the hash rate, *h */ *H*, have a > profitability advantage if you hold all the other variables of the miner's > profit equation constant. I think this is important: it is a centralizing > factor similar to other economies of scale. > > However, that is outside the scope of the result that an individual > miner's profit per block is always maximized at a finite block size Q* if > Shannon Entropy about each transaction is communicated during the block > solution announcement. This result is important because it explains how a > minimum fee density exists and it shows how miners cannot create enormous > spam blocks for "no cost," for example. > > Best regards, > Peter > > > 2) Whether it's truly possible for a miner's marginal profit per unit of > hash to decrease with increasing hashrate in some parametric regime.This > however directly contradicts the assumption that an optimal hashrate exists > beyond which the revenue per unit of hash *v' < v *if *h' > h. * > *Q.E.D * > > This theorem in turn implies the following corollary: > > *COROLLARY: **The marginal profit curve is a monotonically increasing of > miner hashrate.* > > This simple theorem, suggested implicitly by Gmaxwell disproves any and > all conclusions of my work. Most importantly, centralization pressures will > always be present. > > > --089e01494220ca2dcd051e8da4da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

"However= , that is outside the scope of the result that an individual miner's pr= ofit per block is always maximized at a finite block size Q* if Shannon Ent= ropy about each transaction is communicated during the block solution annou= ncement.=C2=A0 This result is important because it explains how a minimum f= ee density exists and it shows how miners cannot create enormous spam block= s for "no cost," for example. "

Dear Peter,

This might very well not be the case. Since the expected revenue= <V> in our formulas is but a lower bound to the true e= xpected revenue, and the fee supply curve $3D"M_s(Q)\propto$ , i= f the true expected revenue doesn't decay faster than the mempool's= average transaction fee (or, more simply, if it doesn't decay to zero)= then the maximum miner surplus will be unbounded and unhealthy fee markets= will emerge.

Best,

Daniele=

Daniele Pinna, Ph.D

On Sun, Aug 30, 2015 at 10:08 PM, Peter R <pe= ter_r@gmx.com> wrote:

Hi Daniele,

I don't t= hink there is any contention over the idea that miners that control a large= r percentage of the hash rate, h / H, have a profitability ad= vantage if you hold all the other variables of the miner's profit equat= ion constant.=C2=A0 I think this is important: it is a centralizing factor = similar to other economies of scale. =C2=A0

Howeve= r, that is outside the scope of the result that an individual miner's p= rofit per block is always maximized at a finite block size Q* if Shannon En= tropy about each transaction is communicated during the block solution anno= uncement.=C2=A0 This result is important because it explains how a minimum = fee density exists and it shows how miners cannot create enormous spam bloc= ks for "no cost," for example. =C2=A0

Be= st regards,
Peter

2) Whether it's truly possible for a miner'= ;s marginal profit per unit of hash to decrease with increasing hashrate in= some parametric regime.This however directly contradicts the assump= tion that an optimal hashrate exists beyond which the revenue per unit of h= ash=C2=A0v' = < v=C2=A0i= f=C2=A0=C2=A0h' > h.=C2=A0
Q.E.D=C2=A0
=
This theorem in turn implies the following corollary:

<= span style=3D"font-size:12.8000001907349px">COROLLARY:=C2=A0<= span style=3D"font-size:12.8000001907349px">The marginal profit curve is= a monotonically increasing of miner hashrate.

<= span style=3D"font-size:12.8000001907349px">This simple theorem, suggested = implicitly by Gmaxwell disproves any and all conclusions of my work. Most i= mportantly, centralization pressures will always be present.=C2=A0