path: root/1a/d9cc3e788aeb3a3cd3bc2d1f5320b3fad84f33

Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 76DB18D7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  7 Aug 2015 18:26:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f170.google.com (mail-io0-f170.google.com
	[209.85.223.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5CC6B233
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  7 Aug 2015 18:25:59 +0000 (UTC)
Received: by ioeg141 with SMTP id g141so119617002ioe.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 07 Aug 2015 11:25:58 -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:content-type;
	bh=QMEhOy25D2wmOCwOuTtY7D0IjtDMb6/lMlCu7x00cs8=;
	b=Dv8dM9P9YPFWsI+5BH1YXkzZxFHbK27dve0rGhcwGw8K4eN9GjFak4/EocNFU92h74
	IMIdfXvFM/O39NI0lPjjrTYT3TlkfXIJkcGPRXyzmnheDwwZTFUHsVeX0J9Lhnd9kQDa
	PWVGnaVBxEZAppbBKR8QzdRV40rm7NJ3ytoNm0uNGLAH2BUg5xR7aJpBMcIZpIYzkyBT
	n0tbF4R51TJXFElANrq3esWPAG0EZ8qCC89j1L5KmzeylEzJV6cNtFi5TlAWYUtKSDUX
	KIB0o8Vanqs/FoGNCj7wf/RiNmv9YLFxBFCC/yQWgyy7s9yts1bDmlaUSKbtAWviHXur
	g38Q==
X-Gm-Message-State: ALoCoQkfw6TgYP2K0kfAPBcJeadvDVJahXkjWntiCQJkZxCUWU35f6D1+CTojC/3Ya+OfUmKB3d3
X-Received: by 10.107.130.166 with SMTP id m38mr11306374ioi.77.1438971958780; 
	Fri, 07 Aug 2015 11:25:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.158.140 with HTTP; Fri, 7 Aug 2015 11:25:39 -0700 (PDT)
X-Originating-IP: [172.56.16.232]
In-Reply-To: <CAF_2MyUtrBUnR6EN-mOOnDa+Xh9=2coo9GaUcaeHCREqfP7jxA@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>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Fri, 7 Aug 2015 11:25:39 -0700
Message-ID: <CAOG=w-uOxD0qntS4zWibV-khUYfKkjbsf84DbFR9WGV=FqQYxQ@mail.gmail.com>
To: Ryan Butler <rryananizer@gmail.com>, 
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113eb9c87202b4051cbcc402
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
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 18:26:00 -0000

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

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

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

<div dir=3D"ltr"><div><div><div>Please don&#39;t put words into Pieter&#39;=
s mouth. I guarantee you everyone working on Bitcoin in their heart of hear=
ts 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 extreme it =
is simply impossible to scale Bitcoin to the terrabyte sized blocks that wo=
uld be necessary to service the entire world&#39;s financial transactions. =
Not without sacrificing entirely the protection of policy neutrality achiev=
ed through decentralization. And as that is Bitcoin&#39;s only advantage ov=
er traditional consensus systems, you would have to wonder what the point o=
f such an endeavor would be.<br><br></div>So *somewhere* you have to draw t=
he line, and transactions below that level are simply pushed into higher le=
vel or off-chain protocols.<br><br></div>The issue, as Pieter and Jorge hav=
e been pointing out, is that technical discussion over where that line shou=
ld be has been missing from this debate.<br></div><div class=3D"gmail_extra=
"><br><div class=3D"gmail_quote">On Fri, Aug 7, 2015 at 10:47 AM, Ryan Butl=
er via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.=
org</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"><p dir=3D"ltr">=
Interesting position there Peter...you fear more people actually using bitc=
oin.=C2=A0 The less on chain transactions the lower the velocity and the lo=
wer the value of the network.=C2=A0 I would be careful what you ask for bec=
ause you end up having nothing left to even root the security of these 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 class=3D"h5">On Aug 7, 2015 11:28 AM, =
&quot;Pieter Wuille via bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
tion.org</a>&gt; wrote:<br type=3D"attribution"></div></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr">On Fri, Aug 7, 2015=
 at 5:55 PM, Gavin Andresen <span dir=3D"ltr">&lt;<a href=3D"mailto:gavinan=
dresen@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" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;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"_blan=
k">pieter.wuille@gmail.com</a>&gt;</span> wrote:<br><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 class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><div>I guess my question (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></spa=
n><div>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.</div><div><br></div><div>I take the opinion of smart e=
ngineers who actually do resource planning and have seen what happens when =
networks run out of capacity very seriously.</div></div></div></div></block=
quote><div><br></div><div>This is a fundamental disagreement then. I believ=
e that the demand is infinite 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 wa=
y to fill whatever is available - the rest goes into off-chain systems anyw=
ay. You will run out of capacity at any size, and acting out of fear of tha=
t reality does not improve the system. Whatever size blocks are actually pr=
oduced, I believe the result will either be something people consider too s=
mall 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 second?&quot;), or something that is very centralize=
d in practice, and likely both.<br><br></div><blockquote class=3D"gmail_quo=
te" 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 class=3D"gmail_quote"><sp=
an><div><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 clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div>And if so, if that is a r=
eason for increase now, won&#39;t it be a reason for an increase later as w=
ell? 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&=
#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 messa=
ge to in-the-future Bitcoin engineers: =C2=A0you should consider raising th=
e maximum block size if needed and you think the benefits of doing so (like=
 increased adoption or lower transaction fees or increased reliability) out=
weigh the costs (like higher operating costs for full-nodes or the disrupti=
on caused by ANY consensus rule change).</div></div></div></div></blockquot=
e><br></div><div class=3D"gmail_quote">In general that sounds reasonable, b=
ut it&#39;s a dangerous precedent to make technical decisions based on a fe=
ar of change of economics...<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">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>

--001a113eb9c87202b4051cbcc402--