path: root/60/926420d510b758a841cd0580f2664cf39286e8

Return-Path: <will.madden@novauri.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F2A8F279
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  7 Aug 2015 00:37:20 +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 12DE215D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  7 Aug 2015 00:37:20 +0000 (UTC)
Received: by iodd187 with SMTP id d187so97758232iod.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 06 Aug 2015 17:37:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to
	:references:subject:mime-version:content-type;
	bh=dK+zQCqsjzGpCgdFqVUQG5mVN0c4NySXrMiX/Wakhfo=;
	b=Ez0w8bJuqJdGGFP+Ee5Pvv7uzL+AQj3Xcdf9E3y6XRf4IxD10GIN5aJwqMLHCStp3/
	2tXXQgtUBwKbTw0EEb5yc2RKFd1BI2VXqVCLyBU0vEZWwhnjSrG4L2AROVZjljnfkDxr
	kBY6OABgLpqj1XReW45A2YuPQkJuxJUVVfb+JxVXLEd+VQx4iKSlli664z4SmqsBVchT
	uEpKV54tN/UAr8zMi6V4pEdUFcuzYyO31gIgDbHwrbLzLcbBY3fb+D66zi5QT0D0NwiO
	70qqP2642noY10X2kcjjJ8WeB/t5R5l/ga7CJVP+F1Y6n/MpaUG5Sxeac/+4fEO8t0Tu
	7X1A==
X-Gm-Message-State: ALoCoQmIzalrGO+ykb0aohVEsKN4HAvSiBf8eirmHiDeA+LRRPz/9TgrWBtuNdWeKGCAAjXdAVie
X-Received: by 10.107.166.71 with SMTP id p68mr5787147ioe.67.1438907839482;
	Thu, 06 Aug 2015 17:37:19 -0700 (PDT)
Received: from Williams-MBP (c-73-34-122-98.hsd1.co.comcast.net.
	[73.34.122.98]) by smtp.gmail.com with ESMTPSA id
	m134sm5725134ioe.42.2015.08.06.17.37.17
	(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 06 Aug 2015 17:37:18 -0700 (PDT)
Date: Thu, 6 Aug 2015 18:37:16 -0600
From: Will <will.madden@novauri.com>
To: Pieter Wuille via bitcoin-dev
	<bitcoin-dev@lists.linuxfoundation.org>, Dave Scotese
	<dscotese@litmocracy.com>, Pieter Wuille <pieter.wuille@gmail.com>
Message-ID: <etPan.55c3fdbc.17f5b300.180e@Williams-MBP>
In-Reply-To: <CAPg+sBhura_n92GErDeQVScJh6Y_J3t6KAED9mHYXjSbgMnGJw@mail.gmail.com>
References: <1c808715eac12f67cf9865dfd97c0a37@xbt.hk>
	<CAGLBAhf34uqzxprY37QnfhDpP4FddfRKGnTeHe+o5Zh-rguD-Q@mail.gmail.com>
	<CAPg+sBhura_n92GErDeQVScJh6Y_J3t6KAED9mHYXjSbgMnGJw@mail.gmail.com>
X-Mailer: Airmail (303)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="55c3fdbc_4727356_180e"
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Wrapping up the block size debate with voting
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Aug 2015 00:37:21 -0000

--55c3fdbc_4727356_180e
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I think the key is comity and humility in terms of being honest about our=
 inability to predict future trends in a meaningful way while passing thr=
ough scrutiny coming from divergent perspectives. =C2=A08MB + 40% annuall=
y (at whatever increase frequency is preferred, at coinbase halvings seem=
s most ideal) is the proposal to use.

What if 40% is too fast=3F =C2=A0=C2=A0
If 40% turns out to be excessive, miners have a built in incentive to cap=
 their blocks at a lower amount that meets the supply / demand equilibriu=
m vs. the price of bitcoin trading on the free market. =C2=A0 The key her=
e is to understand =E2=80=9Cprice of bitcoin on the free market=E2=80=9D.=
 =C2=A0Most developers don=E2=80=99t understand free market economics bey=
ond gambling, which is a good bit of the problem here. =C2=A0

Bottom line is, miners directly benefit from higher bitcoin prices when d=
enominated in other currencies. =C2=A0This fact will naturally limit exce=
ssive growth of blk*.dat. size, because if the storage requirements for b=
itcoin grow out of reach of amateurs, it will lead to excessive centraliz=
ation and capture by powerful interests, which would threaten to convert =
bitcoin to a form of sovereign currency and kill free demand for bitcoin =
(and tank the price). =C2=A0Miners don=E2=80=99t want that without some o=
ther body paying them to make econonically distorted decisions. =C2=A0The=
y will limit the size themselves if they see this as an emerging threat. =
=C2=A0It=E2=80=99s in their best interests and will keep them in business=
 longer.

Now, is there a risk that some excessively well funded entity could artif=
icially inflate the price of bitcoin while this bribing miners to let blk=
*.dat size grow out of hand (distorting miner economics) in some sort of =
=E2=80=9Csubsidies for increased liquidity=E2=80=9D corruption scheme=3F =
=C2=A0No there isn=E2=80=99t, because we are going to have a cap on the s=
ize that is reasonable enough that we know it won=E2=80=99t force out any=
 amateurs for at least 5 years, and likely longer.

What if 40% is too slow=3F
That=E2=80=99s a problem anyone who actually owns bitcoin would like to h=
ave. =C2=A0We=E2=80=99ll gladly support an increase in the rate if demand=
 supports it later with a subsequent change. =C2=A0We=E2=80=99ll have to =
do this eventually anyway when SHA256 and RIPEMD160 exhibit collisions, o=
r some other non-self imposed existential threat rears its head.

Long game
Now, this entire scheme is predicated on the price going higher over the =
extended term. =C2=A0I would argue that if we are doing a good job, the p=
rice should go higher. =C2=A0Isn=E2=80=99t that the best barometer of per=
formance=3F =C2=A0Demand for the scarce units inside the protocol denomin=
ated in other currencies=3F

8MB is 1MB + 40% a year from January 2009 to today. =C2=A040% a year is a=
s good as we are going to get in terms of our extrapolated estimation of =
future ability to host full nodes. =C2=A0Anything else is overengineering=
 something we can=E2=80=99t predict anyway. =C2=A0Any arguments against t=
his setting and rate of growth that aren=E2=80=99t exclusively focused on=
 the computer science side of the debate are misguided at best, and corru=
pted by competing incentives at worst. =C2=A0This is because it=E2=80=99s=
 not possible to predict the future any better than using an extrapolatio=
n of the past, which is exactly what 8MB + 40% represents.

So TLDR=3F =C2=A0Go with 8MB + 40% annually and we will cross any (likely=
 imaginary) bridges when we come to them down the road.

Will

=46rom:=C2=A0Pieter Wuille via bitcoin-dev <bitcoin-dev=40lists.linuxfoun=
dation.org>
Reply:=C2=A0Pieter Wuille <pieter.wuille=40gmail.com>>
Date:=C2=A0August 6, 2015 at 5:32:20 PM
To:=C2=A0Dave Scotese <dscotese=40litmocracy.com>>
Cc:=C2=A0Bitcoin Dev <bitcoin-dev=40lists.linuxfoundation.org>>
Subject:=C2=A0 Re: =5Bbitcoin-dev=5D Wrapping up the block size debate wi=
th voting =20

On =46ri, Aug 7, 2015 at 1:26 AM, Dave Scotese via bitcoin-dev <bitcoin-d=
ev=40lists.linuxfoundation.org> wrote:

=22Miners can do this unilaterally=22 maybe, if they are a closed group, =
based on the 51% rule. But aren't they using full nodes for propagation=3F=
=C2=A0 In this sense, anyone can vote by coding.

They don't need to use full nodes for propagation. Miners don't care when=
 other full nodes hear about their blocks, only whether they (eventually)=
 accept them.

And yes, full nodes can change what blocks they accept. That's called a h=
ard fork :)

--
Pieter
=C2=A0

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20
bitcoin-dev mailing list =20
bitcoin-dev=40lists.linuxfoundation.org =20
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =20

--55c3fdbc_4727356_180e
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html><head><style>body=7Bfont-family:Helvetica,Arial;font-size:13px=7D</=
style></head><body style=3D=22word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;=22><div id=3D=22bloop=5Fcust=
omfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color: r=
gba(0,0,0,1.0); margin: 0px; line-height: auto;=22>I think the key is com=
ity and humility in terms of being honest about our inability to predict =
future trends in a meaningful way while passing through scrutiny coming f=
rom divergent perspectives. &nbsp;8MB + 40% annually (at whatever increas=
e frequency is preferred, at coinbase halvings seems most ideal) is the p=
roposal to use.</div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-f=
amily:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px=
; line-height: auto;=22><br></div><div id=3D=22bloop=5Fcustomfont=22 styl=
e=3D=22font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0)=
; margin: 0px; line-height: auto;=22><b>What if 40% is too fast=3F &nbsp;=
&nbsp;</b></div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-family=
:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; lin=
e-height: auto;=22>If 40% turns out to be excessive, miners have a built =
in incentive to cap their blocks at a lower amount that meets the supply =
/ demand equilibrium vs. the price of bitcoin trading on the free market.=
 &nbsp; The key here is to understand =E2=80=9Cprice of bitcoin on the fr=
ee market=E2=80=9D. &nbsp;Most developers don=E2=80=99t understand free m=
arket economics beyond gambling, which is a good bit of the problem here.=
 &nbsp;</div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-family:He=
lvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-h=
eight: auto;=22><br></div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22f=
ont-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin=
: 0px; line-height: auto;=22>Bottom line is, miners directly benefit from=
 higher bitcoin prices when denominated in other currencies. &nbsp;This f=
act will naturally limit excessive growth of blk*.dat. size, because if t=
he storage requirements for bitcoin grow out of reach of amateurs, it wil=
l lead to excessive centralization and capture by powerful interests, whi=
ch would threaten to convert bitcoin to a form of sovereign currency and =
kill free demand for bitcoin (and tank the price). &nbsp;Miners don=E2=80=
=99t want that without some other body paying them to make econonically d=
istorted decisions. &nbsp;They will limit the size themselves if they see=
 this as an emerging threat. &nbsp;It=E2=80=99s in their best interests a=
nd will keep them in business longer.</div><div id=3D=22bloop=5Fcustomfon=
t=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color: rgba(0=
,0,0,1.0); margin: 0px; line-height: auto;=22><br></div><div id=3D=22bloo=
p=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; =
color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22>Now, is there =
a risk that some excessively well funded entity could artificially inflat=
e the price of bitcoin while this bribing miners to let blk*.dat size gro=
w out of hand (distorting miner economics) in some sort of =E2=80=9Csubsi=
dies for increased liquidity=E2=80=9D corruption scheme=3F &nbsp;No there=
 isn=E2=80=99t, because we are going to have a cap on the size that is re=
asonable enough that we know it won=E2=80=99t force out any amateurs for =
at least 5 years, and likely longer.</div><div id=3D=22bloop=5Fcustomfont=
=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color: rgba(0,=
0,0,1.0); margin: 0px; line-height: auto;=22><br></div><div id=3D=22bloop=
=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; c=
olor: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22><b>What if 40% =
is too slow=3F</b></div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22fon=
t-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: =
0px; line-height: auto;=22>That=E2=80=99s a problem anyone who actually o=
wns bitcoin would like to have. &nbsp;We=E2=80=99ll gladly support an inc=
rease in the rate if demand supports it later with a subsequent change. &=
nbsp;We=E2=80=99ll have to do this eventually anyway when SHA256 and RIPE=
MD160 exhibit collisions, or some other non-self imposed existential thre=
at rears its head.</div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22fon=
t-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: =
0px; line-height: auto;=22><br></div><div id=3D=22bloop=5Fcustomfont=22 s=
tyle=3D=22font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1=
.0); margin: 0px; line-height: auto;=22><b>Long game</b></div><div id=3D=22=
bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13=
px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22>Now, this =
entire scheme is predicated on the price going higher over the extended t=
erm. &nbsp;I would argue that if we are doing a good job, the price shoul=
d go higher. &nbsp;Isn=E2=80=99t that the best barometer of performance=3F=
 &nbsp;Demand for the scarce units inside the protocol denominated in oth=
er currencies=3F</div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-=
family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0p=
x; line-height: auto;=22><br></div><div id=3D=22bloop=5Fcustomfont=22 sty=
le=3D=22font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0=
); margin: 0px; line-height: auto;=22>8MB is 1MB + 40% a year from Januar=
y 2009 to today. &nbsp;40% a year is as good as we are going to get in te=
rms of our extrapolated estimation of future ability to host full nodes. =
&nbsp;Anything else is overengineering something we can=E2=80=99t predict=
 anyway. &nbsp;Any arguments against this setting and rate of growth that=
 aren=E2=80=99t exclusively focused on the computer science side of the d=
ebate are misguided at best, and corrupted by competing incentives at wor=
st. &nbsp;This is because it=E2=80=99s not possible to predict the future=
 any better than using an extrapolation of the past, which is exactly wha=
t 8MB + 40% represents.</div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22=
font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margi=
n: 0px; line-height: auto;=22><br></div><div id=3D=22bloop=5Fcustomfont=22=
 style=3D=22font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0=
,1.0); margin: 0px; line-height: auto;=22>So TLDR=3F &nbsp;Go with 8MB + =
40% annually and we will cross any (likely imaginary) bridges when we com=
e to them down the road.</div><div id=3D=22bloop=5Fcustomfont=22 style=3D=
=22font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); ma=
rgin: 0px; line-height: auto;=22><br></div><div id=3D=22bloop=5Fcustomfon=
t=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color: rgba(0=
,0,0,1.0); margin: 0px; line-height: auto;=22>Will</div> <div class=3D=22=
airmail=5Fext=5Fon=22 style=3D=22color:black=22><br>=46rom:&nbsp;<span st=
yle=3D=22color:black=22>Pieter Wuille via bitcoin-dev</span> <a href=3D=22=
mailto:bitcoin-dev=40lists.linuxfoundation.org=22>&lt;bitcoin-dev=40lists=
.linuxfoundation.org&gt;</a><br>Reply:&nbsp;<span style=3D=22color:black=22=
>Pieter Wuille</span> <a href=3D=22mailto:pieter.wuille=40gmail.com=22>&l=
t;pieter.wuille=40gmail.com&gt;&gt;</a><br>Date:&nbsp;<span style=3D=22co=
lor:black=22>August 6, 2015 at 5:32:20 PM</span><br>To:&nbsp;<span style=3D=
=22color:black=22>Dave Scotese</span> <a href=3D=22mailto:dscotese=40litm=
ocracy.com=22>&lt;dscotese=40litmocracy.com&gt;&gt;</a><br>Cc:&nbsp;<span=
 style=3D=22color:black=22>Bitcoin Dev</span> <a href=3D=22mailto:bitcoin=
-dev=40lists.linuxfoundation.org=22>&lt;bitcoin-dev=40lists.linuxfoundati=
on.org&gt;&gt;</a><br>Subject:&nbsp;<span style=3D=22color:black=22> Re: =
=5Bbitcoin-dev=5D Wrapping up the block size debate with voting <br></spa=
n></div><br> <blockquote type=3D=22cite=22 class=3D=22clean=5Fbq=22><span=
><div><div></div><div>



<title></title>


<div dir=3D=22ltr=22>On =46ri, Aug 7, 2015 at 1:26 AM, Dave Scotese via
bitcoin-dev <span dir=3D=22ltr=22>&lt;<a href=3D=22mailto:bitcoin-dev=40l=
ists.linuxfoundation.org=22 target=3D=22=5Fblank=22>bitcoin-dev=40lists.l=
inuxfoundation.org</a>&gt;</span>
wrote:<br>
<div class=3D=22gmail=5Fextra=22>
<div class=3D=22gmail=5Fquote=22><br>
<blockquote class=3D=22gmail=5Fquote=22 style=3D=22margin:0 0 0 .8ex;bord=
er-left:1px =23ccc solid;padding-left:1ex=22>
=22Miners can do this unilaterally=22 maybe, if they are a closed
group, based on the 51% rule. But aren't they using full nodes for
propagation=3F&nbsp; In this sense, anyone can vote by
coding.<br></blockquote>
<div><br></div>
<div>They don't need to use full nodes for propagation. Miners
don't care when other full nodes hear about their blocks, only
whether they (eventually) accept them.<br>
<br></div>
<div>And yes, full nodes can change what blocks they accept. That's
called a hard fork :)<br>
<br>
--<br></div>
<div>Pieter<br>
&nbsp;<br></div>
</div>
<br></div>
</div>


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
<br>bitcoin-dev mailing list
<br>bitcoin-dev=40lists.linuxfoundation.org
<br>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<br></div></div></span></blockquote></body></html>
--55c3fdbc_4727356_180e--