path: root/0f/dceaece7c450ce42f084ec6a8d700a94cd5b22

Return-Path: <jameson.lopp@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E6418282
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 16:23:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com
	[209.85.212.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A407A15B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 16:23:18 +0000 (UTC)
Received: by wibxm9 with SMTP id xm9so251882119wib.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 09:23:17 -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=+eC3r3oqcBrAgiPRvVPmzmBuGQ3bay3Ts+MyOWNUIq4=;
	b=fIQpwiigeGl1FQu1v+L/LHHdLvgXBpzRpyPpPhIQG23a4WAaGLK3AJod2cTmLWt89h
	ZN0eiB3CJfxy7O27wQBQtFiUrP2/VdrXP/U362cPy7c/xjS67QVUYLFlqLYH2ridK0GP
	V2UyOY8SKHuTKfWPtC9Zm0CXHTvvYK2AlTrKW64jwIoqrFa/Ol4WwvGUVd4B5icTTbLd
	1lCp09Kx88G40hyI7Mv58OvILE0hkNhaWrzROSB0Gepleu9KB4MzZBTdpOt9BuA1G4FM
	gXEiwVtKjboVnN9FlbVQ3BVgFg483mxw3dXqJA2zD9CecQS7gSMCVbTwZmXz2f4CMb+o
	03eQ==
MIME-Version: 1.0
X-Received: by 10.180.218.195 with SMTP id pi3mr7707619wic.71.1438273397380;
	Thu, 30 Jul 2015 09:23:17 -0700 (PDT)
Received: by 10.27.171.138 with HTTP; Thu, 30 Jul 2015 09:23:17 -0700 (PDT)
In-Reply-To: <CABm2gDrHjfkC+whh3Vh2LZNdSR1WSAXpNitR-jEdxtbKj7J25g@mail.gmail.com>
References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
	<CABm2gDrHjfkC+whh3Vh2LZNdSR1WSAXpNitR-jEdxtbKj7J25g@mail.gmail.com>
Date: Thu, 30 Jul 2015 12:23:17 -0400
Message-ID: <CADL_X_f5nVFCmwNTAtJ6xTdB62wKc+FJdWCHVza9ran2NzaTmw@mail.gmail.com>
From: Jameson Lopp <jameson.lopp@gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=001a1134ce04f0dda5051c1a1e52
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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size following technological growth
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: Thu, 30 Jul 2015 16:23:20 -0000

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

I find it to be an admirable goal to try to keep node operation costs low
and accessible to the average user. On the other hand, if we are able to
keep the resource requirements of nodes at the level of, say, whatever the
latest Raspberry Pi model on a residential Internet connection can handle,
I'm not sure how helpful it will be if the demand for inclusion in blocks
results in transaction fees prices out more users. Stated differently, if
the cost or contention of using the network rises to the point of excluding
the average user from making transactions, then they probably aren't going
to care that they can run a node at trivial cost.

If we're approaching the block size from a resource usage standpoint, it
seems to me that someone is going to be excluded one way or another. Not
raising the block size will exclude some users from sending transactions
while raising the block size will exclude some users from running nodes.
The latter seems preferable to me because more users will grow the
ecosystem, which should increase the value of the ecosystem, which should
increase the cost that entities are willing to pay to run nodes.

I see two primary points of view / objectives clashing in this debate:

1) Decentralization and stability even if it retards growth of the ecosyste=
m
2) Push the system's load as far as we are comfortable in order to
accommodate the growth it is experiencing

It's clear to me that Core developers have a responsibility to maintain a
stable platform for the ecosystem. I think it's less clear that they have a
responsibility to grow it or ask node operators to expend more resources in
order to support more users. As an operator of several nodes, I can
anecdotally state that I find their resource usage to be trivial and I
welcome more load.

- Jameson

On Thu, Jul 30, 2015 at 11:12 AM, Jorge Tim=C3=B3n <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 1) Unlike previous blocksize hardfork proposals, this uses median time
> instead of block.nTime for activation. I like that more but my
> preference is still using height for everything. But that discussion
> is not specific to this proposal, so it's better if we discuss that
> for all of them here:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.h=
tml
>
> 2) I think uncontroversial hardforks should also take miner
> confirmation into account, just like uncontroversial softforks do. We
> cannot make sure other users have upgraded before activating the
> chain, but we can know whether miners have upgraded or not. Having
> that tool available, why not use it. Of course other hardforks may not
> care about miners' upgrade state. For example "anti-miner hardforks,
> see
> https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#asic-reset-ha=
rdfork
> But again, this is common to all uncontroversial hardforks, so it
> would probably better to discussed it in
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.h=
tml
> (gmaxwell assigned to bip99 to my bip draft).
>
> 3) As commented to you privately, I don't like to make any assumptions
> about technological advancements (much less on economical growth). I
> don't expect many people to agree with me here (I guess I've seen too
> many "peak oil" [or more generally, peak energy production] plus I've
> read Nietzsche's "On the utility and liability of history for life"
> [1]; so considering morals, technology or economics as "monotonic
> functions" in history is simply a ridiculous notion to me), but it's
> undeniable that internet connections have improved overall around the
> world in the last 6 years. I think we should wait for the
> technological improvements to happen and then adapt the blocksize
> accordingly. I know, that's not a "definitive solution", we will need
> to change it from time to time and this is somewhat ugly.
> But even if I'm the only one that considers a "technological
> de-growth" possible, I don't think is wise to rely on pseudo-laws like
> Moore's or Nielsen=E2=80=99s so-called "laws".
> Stealing a quote from another thread:
>
> "Prediction is difficult, especially about the future." - Niels Bohr
>
> So I would prefer a more limited solution like bip102 (even though I
> would prefer to have some simulations leading to  a concrete value
> (even if it's bigger) rather than using 2MB's arbitrary number.
>
> Those are my 3 cents.
>
> [1]
> https://philohist.files.wordpress.com/2008/01/nietzsche-uses-history.pdf
>
> On Thu, Jul 30, 2015 at 4:25 PM, Pieter Wuille via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Hello all,
> >
> > here is a proposal for long-term scalability I've been working on:
> > https://gist.github.com/sipa/c65665fc360ca7a176a6
> >
> > Some things are not included yet, such as a testnet whose size runs
> ahead of
> > the main chain, and the inclusion of Gavin's more accurate sigop checki=
ng
> > after the hard fork.
> >
> > Comments?
> >
> > --
> > Pieter
> >
> >
> > _______________________________________________
> > 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
>

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

<div dir=3D"ltr">I find it to be an admirable goal to try to keep node oper=
ation costs low and accessible to the average user. On the other hand, if w=
e are able to keep the resource requirements of nodes at the level of, say,=
 whatever the latest Raspberry Pi model on a residential Internet connectio=
n can handle, I&#39;m not sure how helpful it will be if the demand for inc=
lusion in blocks results in transaction fees prices out more users. Stated =
differently, if the cost or contention of using the network rises to the po=
int of excluding the average user from making transactions, then they proba=
bly aren&#39;t going to care that they can run a node at trivial cost.<div>=
<br></div><div>If we&#39;re approaching the block size from a resource usag=
e standpoint, it seems to me that someone is going to be excluded one way o=
r another. Not raising the block size will exclude some users from sending =
transactions while raising the block size will exclude some users from runn=
ing nodes. The latter seems preferable to me because more users will grow t=
he ecosystem, which should increase the value of the ecosystem, which shoul=
d increase the cost that entities are willing to pay to run nodes.</div><di=
v><br></div><div>I see two primary points of view / objectives clashing in =
this debate:</div><div><br></div><div>1) Decentralization and stability eve=
n if it retards growth of the ecosystem</div><div>2) Push the system&#39;s =
load as far as we are comfortable in order to accommodate the growth it is =
experiencing</div><div><br></div><div>It&#39;s clear to me that Core develo=
pers have a responsibility to maintain a stable platform for the ecosystem.=
 I think it&#39;s less clear that they have a responsibility to grow it or =
ask node operators to expend more resources in order to support more users.=
 As an operator of several nodes, I can anecdotally state that I find their=
 resource usage to be trivial and I welcome more load.</div><div><br></div>=
<div>- Jameson</div></div><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote">On Thu, Jul 30, 2015 at 11:12 AM, Jorge Tim=C3=B3n <span dir=3D"lt=
r">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">1) Unlike previous blocksize hardfork proposals, =
this uses median time<br>
instead of block.nTime for activation. I like that more but my<br>
preference is still using height for everything. But that discussion<br>
is not specific to this proposal, so it&#39;s better if we discuss that<br>
for all of them here:<br>
<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July=
/009731.html" rel=3D"noreferrer" target=3D"_blank">http://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2015-July/009731.html</a><br>
<br>
2) I think uncontroversial hardforks should also take miner<br>
confirmation into account, just like uncontroversial softforks do. We<br>
cannot make sure other users have upgraded before activating the<br>
chain, but we can know whether miners have upgraded or not. Having<br>
that tool available, why not use it. Of course other hardforks may not<br>
care about miners&#39; upgrade state. For example &quot;anti-miner hardfork=
s,<br>
see <a href=3D"https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#=
asic-reset-hardfork" rel=3D"noreferrer" target=3D"_blank">https://github.co=
m/jtimon/bips/blob/bip-forks/bip-forks.org#asic-reset-hardfork</a><br>
But again, this is common to all uncontroversial hardforks, so it<br>
would probably better to discussed it in<br>
<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June=
/008936.html" rel=3D"noreferrer" target=3D"_blank">http://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2015-June/008936.html</a><br>
(gmaxwell assigned to bip99 to my bip draft).<br>
<br>
3) As commented to you privately, I don&#39;t like to make any assumptions<=
br>
about technological advancements (much less on economical growth). I<br>
don&#39;t expect many people to agree with me here (I guess I&#39;ve seen t=
oo<br>
many &quot;peak oil&quot; [or more generally, peak energy production] plus =
I&#39;ve<br>
read Nietzsche&#39;s &quot;On the utility and liability of history for life=
&quot;<br>
[1]; so considering morals, technology or economics as &quot;monotonic<br>
functions&quot; in history is simply a ridiculous notion to me), but it&#39=
;s<br>
undeniable that internet connections have improved overall around the<br>
world in the last 6 years. I think we should wait for the<br>
technological improvements to happen and then adapt the blocksize<br>
accordingly. I know, that&#39;s not a &quot;definitive solution&quot;, we w=
ill need<br>
to change it from time to time and this is somewhat ugly.<br>
But even if I&#39;m the only one that considers a &quot;technological<br>
de-growth&quot; possible, I don&#39;t think is wise to rely on pseudo-laws =
like<br>
Moore&#39;s or Nielsen=E2=80=99s so-called &quot;laws&quot;.<br>
Stealing a quote from another thread:<br>
<br>
&quot;Prediction is difficult, especially about the future.&quot; - Niels B=
ohr<br>
<br>
So I would prefer a more limited solution like bip102 (even though I<br>
would prefer to have some simulations leading to=C2=A0 a concrete value<br>
(even if it&#39;s bigger) rather than using 2MB&#39;s arbitrary number.<br>
<br>
Those are my 3 cents.<br>
<br>
[1] <a href=3D"https://philohist.files.wordpress.com/2008/01/nietzsche-uses=
-history.pdf" rel=3D"noreferrer" target=3D"_blank">https://philohist.files.=
wordpress.com/2008/01/nietzsche-uses-history.pdf</a><br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Thu, Jul 30, 2015 at 4:25 PM, Pieter Wuille via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>&gt; wrote:<br>
&gt; Hello all,<br>
&gt;<br>
&gt; here is a proposal for long-term scalability I&#39;ve been working on:=
<br>
&gt; <a href=3D"https://gist.github.com/sipa/c65665fc360ca7a176a6" rel=3D"n=
oreferrer" target=3D"_blank">https://gist.github.com/sipa/c65665fc360ca7a17=
6a6</a><br>
&gt;<br>
&gt; Some things are not included yet, such as a testnet whose size runs ah=
ead of<br>
&gt; the main chain, and the inclusion of Gavin&#39;s more accurate sigop c=
hecking<br>
&gt; after the hard fork.<br>
&gt;<br>
&gt; Comments?<br>
&gt;<br>
&gt; --<br>
&gt; Pieter<br>
&gt;<br>
&gt;<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">&gt; __________________=
_____________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>

--001a1134ce04f0dda5051c1a1e52--