Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.171 as permitted sender)
	client-ip=209.85.192.171; envelope-from=elombrozo@gmail.com;
	helo=mail-pd0-f171.google.com; 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_74CBEB40-D60B-4837-B32F-8AF89A46794E";
	protocol="application/pgp-signature"; micalg=pgp-sha512
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CAJna-HjDHC=cHaUPKMB0c0Myg6EH4EX+aN4qECyq7L8p37VG=w@mail.gmail.com>
Date: Wed, 6 May 2015 16:06:00 -0700
Message-Id: <0F6580B4-8BB5-4287-94DE-5F625AC1BBA3@gmail.com>
References: <554A91BE.6060105@bluematt.me>
	<CAJna-HjDHC=cHaUPKMB0c0Myg6EH4EX+aN4qECyq7L8p37VG=w@mail.gmail.com>
To: slush <slush@centrum.cz>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
Precedence: list


--Apple-Mail=_74CBEB40-D60B-4837-B32F-8AF89A46794E
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_DBE70104-695C-402C-9D5B-D4F063AE4045"


--Apple-Mail=_DBE70104-695C-402C-9D5B-D4F063AE4045
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I don=92t really have a strong opinion on block size either=85but if =
we=92re going to do a hard fork, let=92s use this as an opportunity to =
create a good process for hard forks (which we=92ll inevitably need to =
do again in the future). The change in block size is a very simple =
change that still allows us to explore all the complexities involved =
with deployment of hard forks. Let=92s not just do a one-off ad-hoc =
thing.

- Eric Lombrozo

> On May 6, 2015, at 3:30 PM, slush <slush@centrum.cz> wrote:
>=20
> I don't have strong opinion @ block size topic.
>=20
> But if there'll be a fork, PLEASE, include SIGHASH_WITHINPUTVALUE =
(https://bitcointalk.org/index.php?topic=3D181734.0 =
<https://bitcointalk.org/index.php?topic=3D181734.0>) or its =
alternative. All developers of lightweight (blockchain-less) clients =
will adore you!
>=20
> slush
>=20
> On Thu, May 7, 2015 at 12:12 AM, Matt Corallo =
<bitcoin-list@bluematt.me <mailto:bitcoin-list@bluematt.me>> wrote:
> Recently there has been a flurry of posts by Gavin at
> http://gavinandresen.svbtle.com/ <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.
>=20
> 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.
>=20
> 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.
>=20
> 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).
>=20
> 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].
>=20
> Matt
>=20
> [1] https://twitter.com/coinbase/status/595741967759335426 =
<https://twitter.com/coinbase/status/595741967759335426>
>=20
> =
--------------------------------------------------------------------------=
----
> 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 =
<http://ad.doubleclick.net/ddm/clk/290420510;117567292;y>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net =
<mailto:Bitcoin-development@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development =
<https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>=20
> =
--------------------------------------------------------------------------=
----
> 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


--Apple-Mail=_DBE70104-695C-402C-9D5B-D4F063AE4045
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">I don=92t really have a strong opinion on block size =
either=85but if we=92re going to do a hard fork, let=92s use this as an =
opportunity to create a good process for hard forks (which we=92ll =
inevitably need to do again in the future). The change in block size is =
a very simple change that still allows us to explore all the =
complexities involved with deployment of hard forks. Let=92s not just do =
a one-off ad-hoc thing.<div class=3D""><br class=3D""></div><div =
class=3D"">- Eric Lombrozo</div><div class=3D""><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
May 6, 2015, at 3:30 PM, slush &lt;<a href=3D"mailto:slush@centrum.cz" =
class=3D"">slush@centrum.cz</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D"">I don't have strong opinion @ block size topic.<div =
class=3D""><br class=3D""></div><div class=3D"">But if there'll be a =
fork, PLEASE, include&nbsp;SIGHASH_WITHINPUTVALUE (<a =
href=3D"https://bitcointalk.org/index.php?topic=3D181734.0" =
class=3D"">https://bitcointalk.org/index.php?topic=3D181734.0</a>) or =
its alternative. All developers of lightweight (blockchain-less) clients =
will adore you!</div><div class=3D""><br class=3D""></div><div =
class=3D"">slush</div></div><div class=3D"gmail_extra"><br class=3D""><div=
 class=3D"gmail_quote">On Thu, May 7, 2015 at 12:12 AM, Matt Corallo =
<span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:bitcoin-list@bluematt.me" target=3D"_blank" =
class=3D"">bitcoin-list@bluematt.me</a>&gt;</span> wrote:<br =
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">Recently there has =
been a flurry of posts by Gavin at<br class=3D"">
<a href=3D"http://gavinandresen.svbtle.com/" target=3D"_blank" =
class=3D"">http://gavinandresen.svbtle.com/</a> which advocate strongly =
for increasing<br class=3D"">
the maximum block size. However, there hasnt been any discussion on =
this<br class=3D"">
mailing list in several years as far as I can tell.<br class=3D"">
<br class=3D"">
Block size is a question to which there is no answer, but which<br =
class=3D"">
certainly has a LOT of technical tradeoffs to consider. I know a lot =
of<br class=3D"">
people here have varying levels of strong or very strong opinions =
about<br class=3D"">
this, and the fact that it is not being discussed in a technical<br =
class=3D"">
community publicly anywhere is rather disappointing.<br class=3D"">
<br class=3D"">
So, at the risk of starting a flamewar, I'll provide a little bait to<br =
class=3D"">
get some responses and hope the discussion opens up into an honest<br =
class=3D"">
comparison of the tradeoffs here. Certainly a consensus in this kind =
of<br class=3D"">
technical community should be a basic requirement for any serious<br =
class=3D"">
commitment to blocksize increase.<br class=3D"">
<br class=3D"">
Personally, I'm rather strongly against any commitment to a block =
size<br class=3D"">
increase in the near future. Long-term incentive compatibility =
requires<br class=3D"">
that there be some fee pressure, and that blocks be relatively<br =
class=3D"">
consistently full or very nearly full. What we see today are<br =
class=3D"">
transactions enjoying next-block confirmations with nearly zero =
pressure<br class=3D"">
to include any fee at all (though many do because it makes wallet =
code<br class=3D"">
simpler).<br class=3D"">
<br class=3D"">
This allows the well-funded Bitcoin ecosystem to continue building<br =
class=3D"">
systems which rely on transactions moving quickly into blocks while<br =
class=3D"">
pretending these systems scale. Thus, instead of working on =
technologies<br class=3D"">
which bring Bitcoin's trustlessness to systems which scale beyond a<br =
class=3D"">
blockchain's necessarily slow and (compared to updating numbers in a<br =
class=3D"">
database) expensive settlement, the ecosystem as a whole continues to<br =
class=3D"">
focus on building centralized platforms and advocate for changes to<br =
class=3D"">
Bitcoin which allow them to maintain the status quo[1].<br class=3D"">
<br class=3D"">
Matt<br class=3D"">
<br class=3D"">
[1] <a href=3D"https://twitter.com/coinbase/status/595741967759335426" =
target=3D"_blank" =
class=3D"">https://twitter.com/coinbase/status/595741967759335426</a><br =
class=3D"">
<br class=3D"">
=
--------------------------------------------------------------------------=
----<br class=3D"">
One dashboard for servers and applications across =
Physical-Virtual-Cloud<br class=3D"">
Widest out-of-the-box monitoring support with 50+ applications<br =
class=3D"">
Performance metrics, stats and reports that give you Actionable =
Insights<br class=3D"">
Deep dive visibility with transaction tracing using APM Insight.<br =
class=3D"">
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" =
target=3D"_blank" =
class=3D"">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br =
class=3D"">
_______________________________________________<br class=3D"">
Bitcoin-development mailing list<br class=3D"">
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" =
class=3D"">Bitcoin-development@lists.sourceforge.net</a><br class=3D"">
<a =
href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development" =
target=3D"_blank" =
class=3D"">https://lists.sourceforge.net/lists/listinfo/bitcoin-developmen=
t</a><br class=3D"">
</blockquote></div><br class=3D""></div>
=
--------------------------------------------------------------------------=
----<br class=3D"">One dashboard for servers and applications across =
Physical-Virtual-Cloud <br class=3D"">Widest out-of-the-box monitoring =
support with 50+ applications<br class=3D"">Performance metrics, stats =
and reports that give you Actionable Insights<br class=3D"">Deep dive =
visibility with transaction tracing using APM Insight.<br class=3D""><a =
href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___________=
____________________________________" =
class=3D"">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y________=
_______________________________________</a><br =
class=3D"">Bitcoin-development mailing list<br =
class=3D"">Bitcoin-development@lists.sourceforge.net<br =
class=3D"">https://lists.sourceforge.net/lists/listinfo/bitcoin-developmen=
t<br class=3D""></div></blockquote></div><br =
class=3D""></div></body></html>=

--Apple-Mail=_DBE70104-695C-402C-9D5B-D4F063AE4045--

--Apple-Mail=_74CBEB40-D60B-4837-B32F-8AF89A46794E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVSp5YAAoJEJNAI64YFENUhUgQAKiDsn5VU/60D8xyGxQ6G+bM
AG8Z5Qkyp8kfoz6UM6Em0MkXeEaaawt4QH1hWZo6x0B/yCKzD1oR8Yhq2Uw9plOZ
qeEesjsLjWaZUULWdNhtJidGXw2ntsyg8OGsETEzOMRx64+52Gx+1yz9IRzhVey5
21JvGKYBzbTmCX2nWmptjqjY5aAOZrhidTWDMkD/d60XsHktWz8DDHlpxVp1/1j7
/tzNb3hVfNQg9dAOhQQSyMCavaQ0IlqC/7oV2Pr/tQIUN0gTKMYZKFhk53tPxcqK
8KteGQ5WqGYhXZr2mMXV1stNV0eEctYgTAdHo1mjfhJIJUOnVupIpQTM3V+0RH0+
Bi7Jd8MgbZVlVQk2Xu9IFag1EPQGfBWEPyy3vWswnSa5woZB9fZNDjGDAHbyg5M4
lRXy31JHaseDsiJf1L5rglUl8LKoXgYKAiCReEtApcPVsgfMDvYRxSDUDDVbtGbn
aAPRBPGu00fn8tnfjjF55YVsU1rMf/LchzoiXO/RWwJUuxPJ39KyyzcPVmtGNc6t
9eWApSqa96Qp1T2g41lfLxYWSM91zk1dbc1R+oI0ROGYK4mobOK3H49jmrvdMHCv
DQ36Yy1w+wTC9fO37Yw9uVXLjpR7MfEua+Dkv9IWl/0nsWIm75TIC5k7SlShHTC1
1A+df3+5zdgeTnUq1DPg
=Kfjc
-----END PGP SIGNATURE-----

--Apple-Mail=_74CBEB40-D60B-4837-B32F-8AF89A46794E--