path: root/c0/a4c7e5faa45e1fe6f71aa532500d41a54c5109

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <jgarzik@bitpay.com>) id 1Z4KOI-0004Z7-Bh
	for bitcoin-development@lists.sourceforge.net;
	Mon, 15 Jun 2015 02:44:50 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 209.85.214.178 as permitted sender)
	client-ip=209.85.214.178; envelope-from=jgarzik@bitpay.com;
	helo=mail-ob0-f178.google.com; 
Received: from mail-ob0-f178.google.com ([209.85.214.178])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z4KOG-0007wo-QZ
	for bitcoin-development@lists.sourceforge.net;
	Mon, 15 Jun 2015 02:44:50 +0000
Received: by obbsn1 with SMTP id sn1so55098278obb.1
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 14 Jun 2015 19:44:43 -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:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=cfbgIaM26rcXI+/UmxMi/HL37EljQRHv2syNPzP3OB0=;
	b=Rm1sVFhADJSc6mUhIPESYPmnrteJwC/H+KAiZOFyRI5wuqbEnuIdR7WbTupvD6bYZ+
	xSYDyZ8nlUyDhFzAHNgJu1U/gPrM0JYakMERAovFRo3UOu49VBieDRs00Kr1xCukii2M
	YBkNs1rlRwm9bYgjA7ZWwbclYVTsklTqWuDvc5AUj2WpkoWSa4PESCdbcPHMO9Lj5dxP
	SzjXf8KPubKA2v69GHsBZUGBB9oCqOT8uZ1QIGXzPMEfIAkiTZKhbmiWyFqLmRjQfwT2
	AzVdA5IN/SSdOptH4jUzB2yKfFg4esJK9kp4kiu+yLrQjS8lHLp2rSgp516d6ClcL31Y
	LYiA==
X-Gm-Message-State: ALoCoQl6jW0sJPempPan5HiBeM+zZrjMaAb5UXPiVPtjTBXZfvzHw0MQCrdnKDg1Y2zVuyYxfdMu
X-Received: by 10.202.102.227 with SMTP id m96mr20469235oik.98.1434336283199; 
	Sun, 14 Jun 2015 19:44:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.108.149 with HTTP; Sun, 14 Jun 2015 19:44:22 -0700 (PDT)
In-Reply-To: <CAJHLa0Mj7kAz4=yrZo=+nvoV97rF_xAvHGt+A3D2qE3P16zKBw@mail.gmail.com>
References: <CALqxMTHrnSS9MGgKO-5+=fVhiOOvk12Recs11S0PcSUxQT1wdQ@mail.gmail.com>
	<CAJHLa0Mj7kAz4=yrZo=+nvoV97rF_xAvHGt+A3D2qE3P16zKBw@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Sun, 14 Jun 2015 22:44:22 -0400
Message-ID: <CAJHLa0OcHuWcQeS7dRYHjyqBBkLyxr3XXe2sYGC9Xh2e4UOKDw@mail.gmail.com>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=001a1140a1baa61d5705188570c5
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Z4KOG-0007wo-QZ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] comments on BIP 100
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2015 02:44:50 -0000

--001a1140a1baa61d5705188570c5
Content-Type: text/plain; charset=UTF-8

Adding - in re pay-to-FOO - these schemes are inherently short term, such
that it is near-impossible for the market to plan for what happens in 12+
months.

On Sun, Jun 14, 2015 at 10:28 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:

> On Sun, Jun 14, 2015 at 5:23 PM, Adam Back <adam@cypherspace.org> wrote:
>
>> Hi
>>
>> I made these comments elsewhere, but I think really we should be
>> having these kind of conversations here rather than scattered around.
>>
>> These are about Jeff Garzik's outline draft BIP 100 I guess this is
>> the latest draft:  (One good thing about getting off SF would be
>> finally JGarzik's emails actually not getting blocked!).
>>
>> http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
>>
>> may have changed since the original [1]
>>
>> Over the original proposal:
>>
>> 1. there should be a hard cap, not indefinitely growing.
>>
>>
> In the latest draft there is an explicit 32MB ceiling now.
>
> Users will need to opt into growth beyond 32MB via a 2nd hard fork.
>
>
>
>> 2. there should be  a growth limiter (no more than X%/year)
>>
>>
> As a general principle, this is an area of market disagreement, and should
> not be our call.  Encoding this into software veers into personal opinion
> about what economic policy should be.
>
> That said  -- BIP 100, as a compromise, includes a growth limiter.  Abrupt
> change (1MB -> 32MB!) is awful on markets.  Good policies include a
> measured pace of transition from policy A to policy B.  It gives the
> community time to assess system effectiveness - while also allowing free
> market input.
>
> In the long run I hope the cap is removed (see below), and the intention
> is to -slowly- and -transparently- move from the tightly controlled limit
> to something the free market and users are choosing.
>
>
>
>
>> 3. I think the miners should not be given a vote that has no costs to
>> cast, because their interests are not necessarily aligned with users
>> or businesses.
>>
>> I think Greg Maxwell's difficulty adjust [2] is better here for that
>> reason.  It puts quadratic cost via higher difficulty for miners to
>> vote to increase block-size, which miners can profitably do if there
>> are transactions with fees available to justify it. There is also the
>> growth limiter as part of Greg's proposal. [3]
>>
>>
> "paying with difficulty" has severe negative elements that will likely
> cause it never to be used:
> - complex and difficult for miners to reason
> - fails the opportunity cost test - dollar cost lost losing the block race
> versus value gained by increasing block size
> - inherently unpredictable in the short term - user experience is that
> it's possibly difficult to see a gain in utility versus the revenue you are
> giving up
> - REQUIRES informal miner collusion - probably less transparent than BIP
> 100 - in order to solve the who-goes-first problem.
> - net result: tough sell
>
> Paying bitcoins to future miners makes a lot more sense.  Initially I was
> a fan of pay-with-diff, but freezing bitcoins (CLTV) or timelock'd
> anyone-can-spend has much more clear incentives, if you want to go down
> that road.
>
> Problems with pay-to-increase-block-size:
> - how much to pay?  You are inherently setting your growth policy on top
> of bitcoin by choosing a price here.
> - another who-goes-first problem
>
> Anyway, there is a natural equilibrium block size that the free market and
> user choice will seek.
>
> Related:  There is a lot of naive "miner = max income = max block size"
> reasoning going on, with regards to fees.  This is defining the bounds of
> an economically scarce resource.  There are many reasons why a miner will
> today, in the real world, limit their block size. WRT fee income, if block
> size is too large the fee competition in the overall market is low-to-zero,
> fee income rapidly collapses.  Then factor in price and demand elasticity
> on top of that.
>
> Quite frankly, there seems to be a natural block size equilibrium ceiling,
> and I worry about miners squeezing the market by maximizing their fee
> income through constrained block sizes and competition at the low end.
> This is of course already possible today - miners may openly or covertly
> collude to keep the block size low.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>> I think bitcoin will have to involve layering models that uplift
>> security to higher layers, but preserve security assurances, and
>> smart-contracts even, with protocols that improve the algorithmic
>> complexity beyond O(n^2) in users, like lightning, and there are
>> multiple other candidates with useful tradeoffs for various use-cases.
>>
>> One thing that is concerning is that few in industry seem inclined to
>> take any development initiatives or even integrate a library.  I
>> suppose eventually that problem would self-correct as new startups
>> would make a more scalable wallet and services that are layer2 aware
>> and eat the lunch of the laggards.  But it will be helpful if we
>> expose companies to the back-pressure actually implied by an O(n^2)
>> scaling protocol and don't just immediately increase the block-size to
>> levels that are dangerous for decentralisation security, as an
>> interventionist subsidy to save them having to do basic integration
>> work.  Otherwise I think whichever any kind of kick the can some 2-5
>> years down the road we consider, we risk the whole saga repeating in a
>> few years, when no algorithmic progress has been made and even more
>> protocol inertia has set in.
>>
>> Adam
>>
>> [1] original proposal comments on reddit
>>
>> https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/
>>
>> [2] flexcap propoal by Greg Maxwell see post by Mark Freidenbach
>>
>> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07599.html
>>
>> [3] growth limited proposal for flexcap by Greg Maxwell
>>
>> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07620.html
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

--001a1140a1baa61d5705188570c5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Adding - in re pay-to-FOO - these schemes are inherently s=
hort term, such that it is near-impossible for the market to plan for what =
happens in 12+ months.</div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">On Sun, Jun 14, 2015 at 10:28 PM, Jeff Garzik <span dir=3D"ltr">=
&lt;<a href=3D"mailto:jgarzik@bitpay.com" target=3D"_blank">jgarzik@bitpay.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><span class=3D"">On Sun, Jun 14, 2015 at 5:23 PM, Adam Back <span dir=3D"=
ltr">&lt;<a href=3D"mailto:adam@cypherspace.org" target=3D"_blank">adam@cyp=
herspace.org</a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<=
br>
<br>
I made these comments elsewhere, but I think really we should be<br>
having these kind of conversations here rather than scattered around.<br>
<br>
These are about Jeff Garzik&#39;s outline draft BIP 100 I guess this is<br>
the latest draft:=C2=A0 (One good thing about getting off SF would be<br>
finally JGarzik&#39;s emails actually not getting blocked!).<br>
<br>
<a href=3D"http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf=
" rel=3D"noreferrer" target=3D"_blank">http://gtf.org/garzik/bitcoin/BIP100=
-blocksizechangeproposal.pdf</a><br>
<br>
may have changed since the original [1]<br>
<br>
Over the original proposal:<br>
<br>
1. there should be a hard cap, not indefinitely growing.<br>
<br></blockquote><div><br></div></span><div>In the latest draft there is an=
 explicit 32MB ceiling now.</div><div><br></div><div>Users will need to opt=
 into growth beyond 32MB via a 2nd hard fork.</div><span class=3D""><div><b=
r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. there should be=C2=A0 a growth limiter (no more than X%/year)<br>
<br></blockquote><div><br></div></span><div>As a general principle, this is=
 an area of market disagreement, and should not be our call.=C2=A0 Encoding=
 this into software veers into personal opinion about what economic policy =
should be.</div><div><br></div><div>That said =C2=A0-- BIP 100, as a compro=
mise, includes a growth limiter.=C2=A0 Abrupt change (1MB -&gt; 32MB!) is a=
wful on markets.=C2=A0 Good policies include a measured pace of transition =
from policy A to policy B.=C2=A0 It gives the community time to assess syst=
em effectiveness - while also allowing free market input.</div><div><br></d=
iv><div>In the long run I hope the cap is removed (see below), and the inte=
ntion is to -slowly- and -transparently- move from the tightly controlled l=
imit to something the free market and users are choosing.</div><span class=
=3D""><div><br></div><div><br></div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
3. I think the miners should not be given a vote that has no costs to<br>
cast, because their interests are not necessarily aligned with users<br>
or businesses.<br>
<br>
I think Greg Maxwell&#39;s difficulty adjust [2] is better here for that<br=
>
reason.=C2=A0 It puts quadratic cost via higher difficulty for miners to<br=
>
vote to increase block-size, which miners can profitably do if there<br>
are transactions with fees available to justify it. There is also the<br>
growth limiter as part of Greg&#39;s proposal. [3]<br>
<br></blockquote><div><br></div></span><div>&quot;paying with difficulty&qu=
ot; has severe negative elements that will likely cause it never to be used=
:</div><div>- complex and difficult for miners to reason</div><div>- fails =
the opportunity cost test - dollar cost lost losing the block race versus v=
alue gained by increasing block size</div><div>- inherently unpredictable i=
n the short term - user experience is that it&#39;s possibly difficult to s=
ee a gain in utility versus the revenue you are giving up</div><div>- REQUI=
RES informal miner collusion - probably less transparent than BIP 100 - in =
order to solve the who-goes-first problem.</div><div>- net result: tough se=
ll</div><div><br></div><div>Paying bitcoins to future miners makes a lot mo=
re sense.=C2=A0 Initially I was a fan of pay-with-diff, but freezing bitcoi=
ns (CLTV) or timelock&#39;d anyone-can-spend has much more clear incentives=
, if you want to go down that road.</div><div><br></div><div>Problems with =
pay-to-increase-block-size:</div><div>- how much to pay?=C2=A0 You are inhe=
rently setting your growth policy on top of bitcoin by choosing a price her=
e.</div><div>- another who-goes-first problem</div><div><br></div><div>Anyw=
ay, there is a natural equilibrium block size that the free market and user=
 choice will seek.</div><div><br></div><div>Related: =C2=A0There is a lot o=
f naive &quot;miner =3D max income =3D max block size&quot; reasoning going=
 on, with regards to fees.=C2=A0 This is defining the bounds of an economic=
ally scarce resource.=C2=A0 There are many reasons why a miner will today, =
in the real world, limit their block size. WRT fee income, if block size is=
 too large the fee competition in the overall market is low-to-zero, fee in=
come rapidly collapses.=C2=A0 Then factor in price and demand elasticity on=
 top of that.</div><div><br></div><div>Quite frankly, there seems to be a n=
atural block size equilibrium ceiling, and I worry about miners squeezing t=
he market by maximizing their fee income through constrained block sizes an=
d competition at the low end.=C2=A0 This is of course already possible toda=
y - miners may openly or covertly collude to keep the block size low.</div>=
<div><div class=3D"h5"><div><br></div><div><br></div><div><br></div><div><b=
r></div><div><br></div><div><br></div><div><br></div><div><br></div><div><b=
r></div><div><br></div><div><br></div><div><br></div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">
I think bitcoin will have to involve layering models that uplift<br>
security to higher layers, but preserve security assurances, and<br>
smart-contracts even, with protocols that improve the algorithmic<br>
complexity beyond O(n^2) in users, like lightning, and there are<br>
multiple other candidates with useful tradeoffs for various use-cases.<br>
<br>
One thing that is concerning is that few in industry seem inclined to<br>
take any development initiatives or even integrate a library.=C2=A0 I<br>
suppose eventually that problem would self-correct as new startups<br>
would make a more scalable wallet and services that are layer2 aware<br>
and eat the lunch of the laggards.=C2=A0 But it will be helpful if we<br>
expose companies to the back-pressure actually implied by an O(n^2)<br>
scaling protocol and don&#39;t just immediately increase the block-size to<=
br>
levels that are dangerous for decentralisation security, as an<br>
interventionist subsidy to save them having to do basic integration<br>
work.=C2=A0 Otherwise I think whichever any kind of kick the can some 2-5<b=
r>
years down the road we consider, we risk the whole saga repeating in a<br>
few years, when no algorithmic progress has been made and even more<br>
protocol inertia has set in.<br>
<br>
Adam<br>
<br>
[1] original proposal comments on reddit<br>
<a href=3D"https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_s=
oft_fork_block_size_increase/" rel=3D"noreferrer" target=3D"_blank">https:/=
/www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_siz=
e_increase/</a><br>
<br>
[2] flexcap propoal by Greg Maxwell see post by Mark Freidenbach<br>
<a href=3D"https://www.mail-archive.com/bitcoin-development@lists.sourcefor=
ge.net/msg07599.html" rel=3D"noreferrer" target=3D"_blank">https://www.mail=
-archive.com/bitcoin-development@lists.sourceforge.net/msg07599.html</a><br=
>
<br>
[3] growth limited proposal for flexcap by Greg Maxwell<br>
<a href=3D"https://www.mail-archive.com/bitcoin-development@lists.sourcefor=
ge.net/msg07620.html" rel=3D"noreferrer" target=3D"_blank">https://www.mail=
-archive.com/bitcoin-development@lists.sourceforge.net/msg07620.html</a><br=
>
<br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/=
listinfo/bitcoin-development</a><br>
</blockquote></div></div></div><span class=3D"HOEnZb"><font color=3D"#88888=
8"><br><br clear=3D"all"><div><br></div>-- <br><div>Jeff Garzik<br>Bitcoin =
core developer and open source evangelist<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=
=A0<a href=3D"https://bitpay.com/" target=3D"_blank">https://bitpay.com/</a=
></div>
</font></span></div></div>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature">Jeff Garzik<br>Bitcoin core developer and open source =
evangelist<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.co=
m/" target=3D"_blank">https://bitpay.com/</a></div>
</div>

--001a1140a1baa61d5705188570c5--