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 ) 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 ; 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: References: From: Jeff Garzik Date: Sun, 14 Jun 2015 22:44:22 -0400 Message-ID: To: Adam Back 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > On Sun, Jun 14, 2015 at 5:23 PM, Adam Back 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
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.

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@cyp= herspace.org> wrote:
Hi<= br>
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:=C2=A0 (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.
=C2=A0
2. there should be=C2=A0 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.=C2=A0 Encoding= this into software veers into personal opinion about what economic policy = should be.

That said =C2=A0-- BIP 100, as a compro= mise, includes a growth limiter.=C2=A0 Abrupt change (1MB -> 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.

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.


=C2=A0
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.=C2=A0 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&qu= ot; 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 v= alue gained by increasing block size
- inherently unpredictable i= n the short term - user experience is that it's possibly difficult to s= ee a gain in utility versus the revenue you are giving up
- REQUI= RES informal miner collusion - probably less transparent than BIP 100 - in = order to solve the who-goes-first problem.
- net result: tough se= ll

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'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?=C2=A0 You are inhe= rently setting your growth policy on top of bitcoin by choosing a price her= e.
- another who-goes-first problem

Anyw= ay, there is a natural equilibrium block size that the free market and user= choice will seek.

Related: =C2=A0There is a lot o= f naive "miner =3D max income =3D max block size" 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.

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.
=










=C2=A0
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.=C2=A0 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.=C2=A0 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<= br> levels that are dangerous for decentralisation security, as an
interventionist subsidy to save them having to do basic integration
work.=C2=A0 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_siz= e_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. =C2=A0 =C2=A0 =C2= =A0https://bitpay.com/


--
Jeff Garzik
Bitcoin core developer and open source = evangelist
BitPay, Inc. =C2=A0 =C2=A0 =C2=A0https://bitpay.com/
--001a1140a1baa61d5705188570c5--