MIME-Version: 1.0
Sender: marek@palatinus.cz
In-Reply-To: <554A91BE.6060105@bluematt.me>
References: <554A91BE.6060105@bluematt.me>
From: slush <slush@centrum.cz>
Date: Thu, 7 May 2015 00:30:12 +0200
Message-ID: <CAJna-HjDHC=cHaUPKMB0c0Myg6EH4EX+aN4qECyq7L8p37VG=w@mail.gmail.com>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: multipart/alternative; boundary=001a113967be6eca8d051571589c
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
Precedence: list

--001a113967be6eca8d051571589c
Content-Type: text/plain; charset=ISO-8859-1

I don't have strong opinion @ block size topic.

But if there'll be a fork, PLEASE, include SIGHASH_WITHINPUTVALUE (
https://bitcointalk.org/index.php?topic=181734.0) or its alternative. All
developers of lightweight (blockchain-less) clients will adore you!

slush

On Thu, May 7, 2015 at 12:12 AM, Matt Corallo <bitcoin-list@bluematt.me>
wrote:

> Recently there has been a flurry of posts by Gavin at
> http://gavinandresen.svbtle.com/ which advocate strongly for increasing
> the maximum block size. However, there hasnt been any discussion on this
> mailing list in several years as far as I can tell.
>
> Block size is a question to which there is no answer, but which
> certainly has a LOT of technical tradeoffs to consider. I know a lot of
> people here have varying levels of strong or very strong opinions about
> this, and the fact that it is not being discussed in a technical
> community publicly anywhere is rather disappointing.
>
> So, at the risk of starting a flamewar, I'll provide a little bait to
> get some responses and hope the discussion opens up into an honest
> comparison of the tradeoffs here. Certainly a consensus in this kind of
> technical community should be a basic requirement for any serious
> commitment to blocksize increase.
>
> Personally, I'm rather strongly against any commitment to a block size
> increase in the near future. Long-term incentive compatibility requires
> that there be some fee pressure, and that blocks be relatively
> consistently full or very nearly full. What we see today are
> transactions enjoying next-block confirmations with nearly zero pressure
> to include any fee at all (though many do because it makes wallet code
> simpler).
>
> This allows the well-funded Bitcoin ecosystem to continue building
> systems which rely on transactions moving quickly into blocks while
> pretending these systems scale. Thus, instead of working on technologies
> which bring Bitcoin's trustlessness to systems which scale beyond a
> blockchain's necessarily slow and (compared to updating numbers in a
> database) expensive settlement, the ecosystem as a whole continues to
> focus on building centralized platforms and advocate for changes to
> Bitcoin which allow them to maintain the status quo[1].
>
> Matt
>
> [1] https://twitter.com/coinbase/status/595741967759335426
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--001a113967be6eca8d051571589c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I don&#39;t have strong opinion @ block size topic.<div><b=
r></div><div>But if there&#39;ll be a fork, PLEASE, include=A0SIGHASH_WITHI=
NPUTVALUE (<a href=3D"https://bitcointalk.org/index.php?topic=3D181734.0">h=
ttps://bitcointalk.org/index.php?topic=3D181734.0</a>) or its alternative. =
All developers of lightweight (blockchain-less) clients will adore you!</di=
v><div><br></div><div>slush</div></div><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">On Thu, May 7, 2015 at 12:12 AM, Matt Corallo <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-list@bluematt.me" target=3D"_blank=
">bitcoin-list@bluematt.me</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">Recently there has been a flurry of posts by Gavin at<br>
<a href=3D"http://gavinandresen.svbtle.com/" target=3D"_blank">http://gavin=
andresen.svbtle.com/</a> which advocate strongly for increasing<br>
the maximum block size. However, there hasnt been any discussion on this<br=
>
mailing list in several years as far as I can tell.<br>
<br>
Block size is a question to which there is no answer, but which<br>
certainly has a LOT of technical tradeoffs to consider. I know a lot of<br>
people here have varying levels of strong or very strong opinions about<br>
this, and the fact that it is not being discussed in a technical<br>
community publicly anywhere is rather disappointing.<br>
<br>
So, at the risk of starting a flamewar, I&#39;ll provide a little bait to<b=
r>
get some responses and hope the discussion opens up into an honest<br>
comparison of the tradeoffs here. Certainly a consensus in this kind of<br>
technical community should be a basic requirement for any serious<br>
commitment to blocksize increase.<br>
<br>
Personally, I&#39;m rather strongly against any commitment to a block size<=
br>
increase in the near future. Long-term incentive compatibility requires<br>
that there be some fee pressure, and that blocks be relatively<br>
consistently full or very nearly full. What we see today are<br>
transactions enjoying next-block confirmations with nearly zero pressure<br=
>
to include any fee at all (though many do because it makes wallet code<br>
simpler).<br>
<br>
This allows the well-funded Bitcoin ecosystem to continue building<br>
systems which rely on transactions moving quickly into blocks while<br>
pretending these systems scale. Thus, instead of working on technologies<br=
>
which bring Bitcoin&#39;s trustlessness to systems which scale beyond a<br>
blockchain&#39;s necessarily slow and (compared to updating numbers in a<br=
>
database) expensive settlement, the ecosystem as a whole continues to<br>
focus on building centralized platforms and advocate for changes to<br>
Bitcoin which allow them to maintain the status quo[1].<br>
<br>
Matt<br>
<br>
[1] <a href=3D"https://twitter.com/coinbase/status/595741967759335426" targ=
et=3D"_blank">https://twitter.com/coinbase/status/595741967759335426</a><br=
>
<br>
---------------------------------------------------------------------------=
---<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div>

--001a113967be6eca8d051571589c--