path: root/2b/b7b80ae7adbf49c397348e6d1d87712bca6b29

Return-Path: <rryananizer@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6121E8E6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  7 Aug 2015 20:17:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com
	[209.85.218.53])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E1E0113B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  7 Aug 2015 20:17:29 +0000 (UTC)
Received: by oihn130 with SMTP id n130so62012050oih.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 07 Aug 2015 13:17:29 -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=BEt+R0m5dkOaza5QkFnUuWrq/w20TqEqLOPxCHJRv4w=;
	b=Id3ZQu3ew/3bG9iDI1gjU14VGWyquVlYD0RpJ0R696MeWiSMrvGRIK7jOkrHu1g1Jt
	EK85Xr3WZSNH0adjKKOy0ctpImMjBQCyA3H+rW+ztGQQcfPKlJt5waxtA8CCyj7zdCzW
	u3LoFLvsBiloGay7ZR9KEzp9Lhy142LqZ+obF4vMVLwIars5rns94dm5K3nBLUutwUOL
	8LnaJluC/oDSAk6eWl08RhB7dKYc2RrWIx/KNPmyQqsqHlQgrHX/z3wqmLqDx3nUi9XC
	BzrUcElW6EUoJYatNAr6c27OEBasmNSdAXmaTYYZ4yo/aBCjnG+lTrMrNVB5U/PkKl/X
	lTEw==
MIME-Version: 1.0
X-Received: by 10.202.51.66 with SMTP id z63mr8111709oiz.89.1438978649308;
	Fri, 07 Aug 2015 13:17:29 -0700 (PDT)
Received: by 10.202.220.6 with HTTP; Fri, 7 Aug 2015 13:17:29 -0700 (PDT)
Received: by 10.202.220.6 with HTTP; Fri, 7 Aug 2015 13:17:29 -0700 (PDT)
In-Reply-To: <CAOG=w-s6x57Ab6=Q47abD4aYaUb18OUnoNqGaX4s3Awb7tNQoA@mail.gmail.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
	<CAPg+sBgOt=qhQVZv5P-4mcD75=L4PKgOfRqhyB6FZdSYQajrwQ@mail.gmail.com>
	<CABsx9T10y6-=c7Qg6jysnf38wRX3NA3wWozxGfE+mEYJvPeqWA@mail.gmail.com>
	<CAPg+sBiaT-2sjedA1mLOQo+q7=DjJ2yRuy7E4Gb3Wn8R-DzRTQ@mail.gmail.com>
	<CAF_2MyUtrBUnR6EN-mOOnDa+Xh9=2coo9GaUcaeHCREqfP7jxA@mail.gmail.com>
	<CAOG=w-uOxD0qntS4zWibV-khUYfKkjbsf84DbFR9WGV=FqQYxQ@mail.gmail.com>
	<CAF_2MyVoL7_7jPZX-aftfcjV59nCP1q5bOK-Xyn8JoqyqysXLg@mail.gmail.com>
	<CAF_2MyUqf3Qf7aj6DXy81AycD7EoyZTMsHKih1yfvAmy1BS+wA@mail.gmail.com>
	<CAOG=w-s6x57Ab6=Q47abD4aYaUb18OUnoNqGaX4s3Awb7tNQoA@mail.gmail.com>
Date: Fri, 7 Aug 2015 15:17:29 -0500
Message-ID: <CAF_2MyXumMsx2nzpoxkGZjXarj6tbAsm+37RwPs-nsi+zaUdGw@mail.gmail.com>
From: Ryan Butler <rryananizer@gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=001a113ce1b43b4327051cbe5356
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] Fees and the block-finding process
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 20:17:31 -0000

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

Peter's proposal undercuts matching blocksize growth to technological
progress not limiting centralization pressure.  They are somewhat related,
but I want to be clear on what I originally stated.  I would also point out
that Peter's proposal lacks this technical criteria as well.

That being said, I think designing any growth rates on theoretical
centralization pressure is not sensible and Peter's proposal rightly
excludes it and attempts instead for a very gradual increase over time
attempting to match blocksize growth that is consistent with technological
bandwidth growth.  The problem is that it ignores the last 6 years (we are
already "behind") and underestimates bandwidth and storage growth. (See
Nielsen's law which states 50% and has held for 30 years).

Peter seems to be of the belief that since bitcoin will never be able to
handle all the world's transactions we should instead "...decrease the need
for trust required in off-chain systems...".  This is akin to basing all
the world's transactions on a small settlement layer, much like balancing a
pyramid upside down it will topple.

I'm of the belief that the "reasonable node" test is a simple enough test
to maintain decentralization.

A raspberry pie 2 node on reasonable Internet connection with a reasonable
hard drive can run a node with 8 or 20mb blocks easily.

As Peter's proposal indicates, "If over time, this growth factor is beyond
what the actual technology offers, the intention should be to soft fork a
tighter limit."  I wholeheartedly agree, which is why we should plan to be
ahead of the curve...not behind it.
On Aug 7, 2015 2:15 PM, "Mark Friedenbach" <mark@friedenbach.org> wrote:

> Surely you have some sort of empirical measurement demonstrating the
> validity of that statement? That is to say you've established some
> technical criteria by which to determine how much centralization pressure
> is too much, and shown that Pieter's proposal undercuts expected progress
> in that area?
>
> On Fri, Aug 7, 2015 at 12:07 PM, Ryan Butler <rryananizer@gmail.com>
> wrote:
>
>> Clarification...
>>
>> These are not mutually exclusive.  We can design an increase to blocksize
>> that increases available space on chain AND follow technological
>> evolution.  Peter's latest proposal is way too conservative on that front.
>>
>> And given Peter's assertion that demand is infinite there will still be a
>> an ocean of off chain transactions for the likes of blockstream to address.
>> On Aug 7, 2015 1:57 PM, "Ryan Butler" <rryananizer@gmail.com> wrote:
>>
>>> Who said anything about scaling bitcoin to visa levels now?  We're
>>> talking about an increase now that scales into the future at a rate that is
>>> consistent with technological progress.
>>>
>>> Peter himself said "So, I think the block size should follow
>>> technological evolution...".
>>>
>>> The blocksize increase proposals have been modeled around this very
>>> thing.  It's reasonable to increase the blocksize to a point that a
>>> reasonable person, with reasonable equipment and internet access can run a
>>> node or even a miner with acceptable orphan rates.  Most miners are spv
>>> mining anyways.  The 8 or even 20 MB limits are within those parameters.
>>>
>>> These are not mutually exclusive.  We can design an increase to
>>> blocksize that addresses both demand exceeding the available space AND
>>> follow technological evolution.  Peter's latest proposal is way too
>>> conservative on that front.
>>> On Aug 7, 2015 1:25 PM, "Mark Friedenbach" <mark@friedenbach.org> wrote:
>>>
>>>> Please don't put words into Pieter's mouth. I guarantee you everyone
>>>> working on Bitcoin in their heart of hearts would prefer everyone in the
>>>> world being able to use the Bitcoin ledger for whatever purpose, if there
>>>> were no cost.
>>>>
>>>> But like any real world engineering issue, this is a matter of
>>>> tradeoffs. At the extreme it is simply impossible to scale Bitcoin to the
>>>> terrabyte sized blocks that would be necessary to service the entire
>>>> world's financial transactions. Not without sacrificing entirely the
>>>> protection of policy neutrality achieved through decentralization. And as
>>>> that is Bitcoin's only advantage over traditional consensus systems, you
>>>> would have to wonder what the point of such an endeavor would be.
>>>>
>>>> So *somewhere* you have to draw the line, and transactions below that
>>>> level are simply pushed into higher level or off-chain protocols.
>>>>
>>>> The issue, as Pieter and Jorge have been pointing out, is that
>>>> technical discussion over where that line should be has been missing from
>>>> this debate.
>>>>
>>>> On Fri, Aug 7, 2015 at 10:47 AM, Ryan Butler via bitcoin-dev <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>>> Interesting position there Peter...you fear more people actually using
>>>>> bitcoin.  The less on chain transactions the lower the velocity and the
>>>>> lower the value of the network.  I would be careful what you ask for
>>>>> because you end up having nothing left to even root the security of these
>>>>> off chain transactions with and then neither will exist.
>>>>>
>>>>> Nobody ever said you wouldn't run out of capacity at any size.  It's
>>>>> quite the fallacy to draw the conclusion from that statement that block
>>>>> size should remain far below a capacity it can easily maintain which would
>>>>> bring more users/velocity/value to the system.  The outcomes of both of
>>>>> those scenarios are asymmetric.  A higher block size can support more users
>>>>> and volume.
>>>>>
>>>>> Raising the blocksize isn't out of fear.  It's the realization that we
>>>>> are at a point where we can raise it and support more users and
>>>>> transactions while keeping the downsides to a minimum (centralization etc).
>>>>> On Aug 7, 2015 11:28 AM, "Pieter Wuille via bitcoin-dev" <
>>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>>
>>>>>> On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen <
>>>>>> gavinandresen@gmail.com> wrote:
>>>>>>
>>>>>>> On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille <
>>>>>>> pieter.wuille@gmail.com> wrote:
>>>>>>>
>>>>>>>> I guess my question (and perhaps that's what Jorge is after): do
>>>>>>>> you feel that blocks should be increased in response to (or for fear of)
>>>>>>>> such a scenario.
>>>>>>>>
>>>>>>>
>>>>>>> I think there are multiple reasons to raise the maximum block size,
>>>>>>> and yes, fear of Bad Things Happening as we run up against the 1MB limit is
>>>>>>> one of the reasons.
>>>>>>>
>>>>>>> I take the opinion of smart engineers who actually do resource
>>>>>>> planning and have seen what happens when networks run out of capacity very
>>>>>>> seriously.
>>>>>>>
>>>>>>
>>>>>> This is a fundamental disagreement then. I believe that the demand is
>>>>>> infinite if you don't set a fee minimum (and I don't think we should), and
>>>>>> it just takes time for the market to find a way to fill whatever is
>>>>>> available - the rest goes into off-chain systems anyway. You will run out
>>>>>> of capacity at any size, and acting out of fear of that reality does not
>>>>>> improve the system. Whatever size blocks are actually produced, I believe
>>>>>> the result will either be something people consider too small to be
>>>>>> competitive ("you mean Bitcoin can only do 24 transactions per second?"
>>>>>> sounds almost the same as "you mean Bitcoin can only do 3 transactions per
>>>>>> second?"), or something that is very centralized in practice, and likely
>>>>>> both.
>>>>>>
>>>>>>
>>>>>>> And if so, if that is a reason for increase now, won't it be a
>>>>>>>> reason for an increase later as well? It is my impression that your answer
>>>>>>>> is yes, that this is why you want to increase the block size quickly and
>>>>>>>> significantly, but correct me if I'm wrong.
>>>>>>>>
>>>>>>>
>>>>>>> Sure, it might be a reason for an increase later. Here's my message
>>>>>>> to in-the-future Bitcoin engineers:  you should consider raising the
>>>>>>> maximum block size if needed and you think the benefits of doing so (like
>>>>>>> increased adoption or lower transaction fees or increased reliability)
>>>>>>> outweigh the costs (like higher operating costs for full-nodes or the
>>>>>>> disruption caused by ANY consensus rule change).
>>>>>>>
>>>>>>
>>>>>> In general that sounds reasonable, but it's a dangerous precedent to
>>>>>> make technical decisions based on a fear of change of economics...
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>
>>>>>
>>>>
>

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

<p dir=3D"ltr">Peter&#39;s proposal undercuts matching blocksize growth to =
technological progress not limiting centralization pressure.=C2=A0 They are=
 somewhat related, but I want to be clear on what I originally stated.=C2=
=A0 I would also point out that Peter&#39;s proposal lacks this technical c=
riteria as well.</p>
<p dir=3D"ltr">That being said, I think designing any growth rates on theor=
etical centralization pressure is not sensible and Peter&#39;s proposal rig=
htly excludes it and attempts instead for a very gradual increase over time=
 attempting to match blocksize growth that is consistent with technological=
 bandwidth growth.=C2=A0 The problem is that it ignores the last 6 years (w=
e are already &quot;behind&quot;) and underestimates bandwidth and storage =
growth. (See Nielsen&#39;s law which states 50% and has held for 30 years).=
</p>
<p dir=3D"ltr">Peter seems to be of the belief that since bitcoin will neve=
r be able to handle all the world&#39;s transactions we should instead &quo=
t;...decrease the need for trust required in off-chain systems...&quot;.=C2=
=A0 This is akin to basing all the world&#39;s transactions on a small sett=
lement layer, much like balancing a pyramid upside down it will topple. </p=
>
<p dir=3D"ltr">I&#39;m of the belief that the &quot;reasonable node&quot; t=
est is a simple enough test to maintain decentralization.</p>
<p dir=3D"ltr">A raspberry pie 2 node on reasonable Internet connection wit=
h a reasonable hard drive can run a node with 8 or 20mb blocks easily.</p>
<p dir=3D"ltr">As Peter&#39;s proposal indicates, &quot;If over time, this =
growth factor is beyond what the actual technology offers, the intention sh=
ould be to soft fork a tighter limit.&quot;=C2=A0 I wholeheartedly agree, w=
hich is why we should plan to be ahead of the curve...not behind it.</p>
<div class=3D"gmail_quote">On Aug 7, 2015 2:15 PM, &quot;Mark Friedenbach&q=
uot; &lt;<a href=3D"mailto:mark@friedenbach.org">mark@friedenbach.org</a>&g=
t; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">Surely you have some sort of empirical measurement demonstrating t=
he validity of that statement? That is to say you&#39;ve established some t=
echnical criteria by which to determine how much centralization pressure is=
 too much, and shown that Pieter&#39;s proposal undercuts expected progress=
 in that area?<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Fri, Aug 7, 2015 at 12:07 PM, Ryan Butler <span dir=3D"ltr">&lt;<=
a href=3D"mailto:rryananizer@gmail.com" target=3D"_blank">rryananizer@gmail=
.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr"=
>Clarification...</p>
<p dir=3D"ltr">These are not mutually exclusive.=C2=A0 We can design an inc=
rease to blocksize that increases available space on chain AND follow techn=
ological evolution.=C2=A0 Peter&#39;s latest proposal is way too conservati=
ve on that front.</p>
<p dir=3D"ltr">And given Peter&#39;s assertion that demand is infinite ther=
e will still be a an ocean of off chain transactions for the likes of block=
stream to address.<br>
</p><div><div>
<div class=3D"gmail_quote">On Aug 7, 2015 1:57 PM, &quot;Ryan Butler&quot; =
&lt;<a href=3D"mailto:rryananizer@gmail.com" target=3D"_blank">rryananizer@=
gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><p dir=3D"ltr">Who said anything about scaling bitcoin to visa levels =
now?=C2=A0 We&#39;re talking about an increase now that scales into the fut=
ure at a rate that is consistent with technological progress.</p>
<p dir=3D"ltr">Peter himself said &quot;So, I think the block size should f=
ollow technological evolution...&quot;.</p>
<p dir=3D"ltr">The blocksize increase proposals have been modeled around th=
is very thing.=C2=A0 It&#39;s reasonable to increase the blocksize to a poi=
nt that a reasonable person, with reasonable equipment and internet access =
can run a node or even a miner with acceptable orphan rates.=C2=A0 Most min=
ers are spv mining anyways.=C2=A0 The 8 or even 20 MB limits are within tho=
se parameters.</p>
<p dir=3D"ltr">These are not mutually exclusive.=C2=A0 We can design an inc=
rease to blocksize that addresses both demand exceeding the available space=
 AND follow technological evolution.=C2=A0 Peter&#39;s latest proposal is w=
ay too conservative on that front.</p>
<div class=3D"gmail_quote">On Aug 7, 2015 1:25 PM, &quot;Mark Friedenbach&q=
uot; &lt;<a href=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@fri=
edenbach.org</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><div><div>Please don&#39;t put words into Pie=
ter&#39;s mouth. I guarantee you everyone working on Bitcoin in their heart=
 of hearts would prefer everyone in the world being able to use the Bitcoin=
 ledger for whatever purpose, if there were no cost.<br><br></div>But like =
any real world engineering issue, this is a matter of tradeoffs. At the ext=
reme it is simply impossible to scale Bitcoin to the terrabyte sized blocks=
 that would be necessary to service the entire world&#39;s financial transa=
ctions. Not without sacrificing entirely the protection of policy neutralit=
y achieved through decentralization. And as that is Bitcoin&#39;s only adva=
ntage over traditional consensus systems, you would have to wonder what the=
 point of such an endeavor would be.<br><br></div>So *somewhere* you have t=
o draw the line, and transactions below that level are simply pushed into h=
igher level or off-chain protocols.<br><br></div>The issue, as Pieter and J=
orge have been pointing out, is that technical discussion over where that l=
ine should be has been missing from this debate.<br></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Fri, Aug 7, 2015 at 10:47 AM, R=
yan Butler via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-=
dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfou=
ndation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=
=3D"ltr">Interesting position there Peter...you fear more people actually u=
sing bitcoin.=C2=A0 The less on chain transactions the lower the velocity a=
nd the lower the value of the network.=C2=A0 I would be careful what you as=
k for because you end up having nothing left to even root the security of t=
hese off chain transactions with and then neither will exist.</p>
<p dir=3D"ltr">Nobody ever said you wouldn&#39;t run out of capacity at any=
 size.=C2=A0 It&#39;s quite the fallacy to draw the conclusion from that st=
atement that block size should remain far below a capacity it can easily ma=
intain which would bring more users/velocity/value to the system.=C2=A0 The=
 outcomes of both of those scenarios are asymmetric.=C2=A0 A higher block s=
ize can support more users and volume.</p>
<p dir=3D"ltr">Raising the blocksize isn&#39;t out of fear.=C2=A0 It&#39;s =
the realization that we are at a point where we can raise it and support mo=
re users and transactions while keeping the downsides to a minimum (central=
ization etc).</p>
<div class=3D"gmail_quote"><div><div>On Aug 7, 2015 11:28 AM, &quot;Pieter =
Wuille via bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&=
gt; wrote:<br type=3D"attribution"></div></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div><div><div dir=3D"ltr">On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andrese=
n <span dir=3D"ltr">&lt;<a href=3D"mailto:gavinandresen@gmail.com" target=
=3D"_blank">gavinandresen@gmail.com</a>&gt;</span> wrote:<br><div class=3D"=
gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span>On=
 Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille <span dir=3D"ltr">&lt;<a href=
=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.c=
om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>I guess my ques=
tion (and perhaps that&#39;s what Jorge is after): do you feel that blocks =
should be increased in response to (or for fear of) such a scenario. </div>=
</div></div></div></blockquote><div><br></div></span><div>I think there are=
 multiple reasons to raise the maximum block size, and yes, fear of Bad Thi=
ngs Happening as we run up against the 1MB limit is one of the reasons.</di=
v><div><br></div><div>I take the opinion of smart engineers who actually do=
 resource planning and have seen what happens when networks run out of capa=
city very seriously.</div></div></div></div></blockquote><div><br></div><di=
v>This is a fundamental disagreement then. I believe that the demand is inf=
inite if you don&#39;t set a fee minimum (and I don&#39;t think we should),=
 and it just takes time for the market to find a way to fill whatever is av=
ailable - the rest goes into off-chain systems anyway. You will run out of =
capacity at any size, and acting out of fear of that reality does not impro=
ve the system. Whatever size blocks are actually produced, I believe the re=
sult will either be something people consider too small to be competitive (=
&quot;you mean Bitcoin can only do 24 transactions per second?&quot; sounds=
 almost the same as &quot;you mean Bitcoin can only do 3 transactions per s=
econd?&quot;), or something that is very centralized in practice, and likel=
y both.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote"><span><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><div>And if so, if that is a reason for increase now, =
won&#39;t it be a reason for an increase later as well? It is my impression=
 that your answer is yes, that this is why you want to increase the block s=
ize quickly and significantly, but correct me if I&#39;m wrong. <br></div><=
/div></div></div></blockquote><div><br></div></span><div>Sure, it might be =
a reason for an increase later. Here&#39;s my message to in-the-future Bitc=
oin engineers: =C2=A0you should consider raising the maximum block size if =
needed and you think the benefits of doing so (like increased adoption or l=
ower transaction fees or increased reliability) outweigh the costs (like hi=
gher operating costs for full-nodes or the disruption caused by ANY consens=
us rule change).</div></div></div></div></blockquote><br></div><div class=
=3D"gmail_quote">In general that sounds reasonable, but it&#39;s a dangerou=
s precedent to make technical decisions based on a fear of change of econom=
ics...<br><br>-- <br></div><div class=3D"gmail_quote">Pieter<br><br></div><=
/div></div>
<br></div></div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>
<br></blockquote></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>
<br></blockquote></div><br></div>
</blockquote></div>
</blockquote></div>
</div></div></blockquote></div><br></div>
</blockquote></div>

--001a113ce1b43b4327051cbe5356--