path: root/f3/d833c0e452e5ec5bcb75a864213327f2a48aa5

Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 27D5D847
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 20:52:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com
	[209.85.192.175])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 498C91D7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 20:52:31 +0000 (UTC)
Received: by pdbbh15 with SMTP id bh15so1839977pdb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 13:52:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:message-id:references:to;
	bh=AlsTa3a6Cb0fEqtYvGt8FXCyGVO2BH5q2Dbc0z8JMbc=;
	b=1HmfGhxJdN98ktgnGdSsjgpHbamexDRUIh1e8eI4+HtRTkMFDaU/auOH4FUrVpXeDm
	Tv7VuEmLPzUoeXwFL0Try7DnM7RCHqU0pmgNnIB9SBWAe6SmuMbkxuq1jBJXJcmkz/6M
	QSe1XA4iUROwPEyILDr1K0QHCHXs5FftSosYT0z4jRXKcpiRCtb0I1r3JaNObGhligHj
	1vzZB1hKRPqW8yjzLQPH3hag6Bq/m1+xi9F8HD/GUr3wW9VNvLfnQaPa5qUo/JgA8kjh
	yWynKY3aJXVweoIT1perajg/NzwjK6Z1WKqadgKI6athuI8QkK1lUQ0JwwcpJnAhaZiI
	WitQ==
X-Received: by 10.66.185.199 with SMTP id fe7mr22893387pac.48.1437684750737;
	Thu, 23 Jul 2015 13:52:30 -0700 (PDT)
Received: from [192.168.1.107] (cpe-76-167-237-202.san.res.rr.com.
	[76.167.237.202]) by smtp.gmail.com with ESMTPSA id
	k3sm10595069pde.18.2015.07.23.13.52.28
	(version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 23 Jul 2015 13:52:29 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_9532C849-0228-4D0F-9173-88B1A25818EC";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CABm2gDqFe+_g5Mk=tXCD94x74pu6SiL+XHhMM-T3bBw78m3Mow@mail.gmail.com>
Date: Thu, 23 Jul 2015 13:52:26 -0700
Message-Id: <D161F6BB-BFB1-4B9F-B024-D60A170F393C@gmail.com>
References: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
	<CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
	<CADm_WcbnQQGZoQ92twfUvbzqGwu__xLn+BYOkHPZY_YT1pFrbA@mail.gmail.com>
	<CAPWm=eW8RgrG1CMEAMN4GeiMjZecFvNtZB_Y4rZNeofWSD0=Wg@mail.gmail.com>
	<CADm_WcYCUHs9Qe_T6WJOCUSK6stXYD8v6z5JcGHfRMURoOSFTA@mail.gmail.com>
	<CABm2gDq3JyZx0QCRDbcNSLSOBKdpi4h_7VN1XL8N42U38+eBAA@mail.gmail.com>
	<55B113AF.40500@thinlink.com>
	<CABsx9T1MTc-GmuQyFN1vaFK=CDWV_L214Pi9nR6jLMouQQD0fw@mail.gmail.com>
	<C5A70F53-4779-457A-A06A-686877706F89@gmail.com>
	<CADL_X_exckh5T2BfzPEp26fPR3TD69QarwroDEdS_9wtnKbf+g@mail.gmail.com>
	<6F436293-9E2B-461C-B105-FC4CF9EBFC69@gmail.com>
	<CADL_X_fs3-Zj-9nHu5HXCS=kNFUTJkrUR_8SL+d+M4ziwB66Jw@mail.gmail.com>
	<CABm2gDqFe+_g5Mk=tXCD94x74pu6SiL+XHhMM-T3bBw78m3Mow@mail.gmail.com>
To: =?utf-8?Q?Jorge_Tim=C3=B3n?= <jtimon@jtimon.cc>
X-Mailer: Apple Mail (2.2098)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	MIME_QP_LONG_LINE, 
	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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
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, 23 Jul 2015 20:52:32 -0000


--Apple-Mail=_9532C849-0228-4D0F-9173-88B1A25818EC
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FDE81B26-1D41-4BC2-A389-10580F19EF5E"


--Apple-Mail=_FDE81B26-1D41-4BC2-A389-10580F19EF5E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo <elombrozo@gmail.com =
<mailto:elombrozo@gmail.com>> wrote:
> Mainstream usage of cryptocurrency will be enabled primarily by direct =
party-to-party contract negotiation=E2=80=A6with the use of the =
blockchain primarily as a dispute resolution mechanism. The block size =
isn=E2=80=99t about scaling but about supply and demand of finite =
resources. As demand for block space increases, we can address it either =
by increasing computational resources (block size) or by increasing =
fees. But to do the former we need a way to offset the increase in cost =
by making sure that those who contribute said resources have incentive =
to do so.=E2=80=99

I should also point out, improvements in hardware and network =
infrastructure can also reduce costs=E2=80=A6and we could very well have =
a model where resource requirements can be increased as technology =
improves. However, currently, the computational cost of validation is =
clearly growing far more quickly than the cost of computational =
resources is going down. There are 7,000,000,000 people in the world. =
Payment networks in the developed world already regularly handle =
thousands of transactions a second. Even with highly optimized block =
propagation, pruning, and signature validation, we=E2=80=99re still many =
orders shy of being able to satisfy demand. To achieve mainstream =
adoption, we=E2=80=99ll have to pass through a period of =
quasi-exponential growth in userbase (until the market saturates=E2=80=A6o=
r until the network resources run out). Unless we=E2=80=99re able to =
achieve a validation complexity of O(polylog n) or better, it=E2=80=99s =
not a matter of having a negative attitude about the prospects=E2=80=A6it=E2=
=80=99s just math. Whether we have 2MB or 20MB or 100MB blocks (even =
assuming the above mentioned optimizations and that the computational =
resources exist and are willing to handle it) we will not be able to =
satisfy demand if we insist on requiring global validation for all =
transactions.


> On Jul 23, 2015, at 1:26 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> =
wrote:
>=20
> On Thu, Jul 23, 2015 at 9:52 PM, Jameson Lopp via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Running a node certainly has real-world costs that shouldn't be =
ignored.
>> There are plenty of advocates who argue that Bitcoin should strive to =
keep
>> it feasible for the average user to run their own node (as opposed to
>> Satoshi's vision of beefy servers in data centers.) My impression is =
that
>> even most of these advocates agree that it will be acceptable to =
eventually
>> increase block sizes as resources become faster and cheaper because =
it won't
>> be 'pricing out' the average user from running their own node. If =
this is
>> the case, it seems to me that we have a problem given that there is =
no
>> established baseline for the acceptable performance / hardware cost
>> requirements to run a node. I'd really like to see further =
clarification
>> from these advocates around the acceptable cost of running a node and =
how we
>> can measure the global reduction in hardware and bandwidth costs in =
order to
>> establish a baseline that we can use to justify additional resource =
usage by
>> nodes.
>=20
> Although I don't have a concrete proposals myself, I agree that
> without having any common notion of what the "minimal target hardware"
> looks like, it is very difficult to discuss other things that depend
> on that.
> If there's data that shows that a 100 usd raspberry pi with a 1 MB
> connection in say, India (I actually have no idea about internet
> speeds there) size X is a viable full node, then I don't think anybody
> can reasonably oppose to rising the block size to X, and such a
> hardfork can perfectly be uncontroversial.
> I'm exaggerating ultra-low specifications, but it's just an example to
> illustrate your point.
> There was a thread about formalizing such "minimum hardware
> requirements", but I think the discussion simply finished there:
> - Let's do this
> - Yeah, let's do it
> - +1, let's have concrete values, I generally agree.


--Apple-Mail=_FDE81B26-1D41-4BC2-A389-10580F19EF5E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote">On Thu, Jul 23, 2015 at 3:14 PM, Eric =
Lombrozo&nbsp;<span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:elombrozo@gmail.com" target=3D"_blank" =
class=3D"">elombrozo@gmail.com</a>&gt;</span>&nbsp;wrote:<br =
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, =
204); border-left-style: solid; padding-left: 1ex;">Mainstream usage of =
cryptocurrency will be enabled primarily by direct party-to-party =
contract negotiation=E2=80=A6with the use of the blockchain primarily as =
a dispute resolution mechanism. The block size isn=E2=80=99t about =
scaling but about supply and demand of finite resources. As demand for =
block space increases, we can address it either by increasing =
computational resources (block size) or by increasing fees. But to do =
the former we need a way to offset the increase in cost by making sure =
that those who contribute said resources have incentive to do =
so.=E2=80=99</blockquote></div></div></div></div></blockquote><br =
class=3D""></div><div class=3D"">I should also point out, improvements =
in hardware and network infrastructure can also reduce costs=E2=80=A6and =
we could very well have a model where resource requirements can be =
increased as technology improves. However, currently, the computational =
cost of validation is clearly growing far more quickly than the cost of =
computational resources is going down. There are 7,000,000,000 people in =
the world. Payment networks in the developed world already regularly =
handle thousands of transactions a second. Even with highly optimized =
block propagation, pruning, and signature validation, we=E2=80=99re =
still many orders shy of being able to satisfy demand. To achieve =
mainstream adoption, we=E2=80=99ll have to pass through a period of =
quasi-exponential growth in userbase (until the market saturates=E2=80=A6o=
r until the network resources run out). Unless we=E2=80=99re able to =
achieve a validation complexity of O(polylog n) or better, it=E2=80=99s =
not a matter of having a negative attitude about the prospects=E2=80=A6it=E2=
=80=99s just math. Whether we have 2MB or 20MB or 100MB blocks (even =
assuming the above mentioned optimizations and that the computational =
resources exist and are willing to handle it) we will not be able to =
satisfy demand if we insist on requiring global validation for all =
transactions.</div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D""><div><blockquote =
type=3D"cite" class=3D""><div class=3D"">On Jul 23, 2015, at 1:26 PM, =
Jorge Tim=C3=B3n &lt;<a href=3D"mailto:jtimon@jtimon.cc" =
class=3D"">jtimon@jtimon.cc</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D"">On Thu, Jul 23, 2015 =
at 9:52 PM, Jameson Lopp via bitcoin-dev<br class=3D"">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br =
class=3D""><blockquote type=3D"cite" class=3D"">Running a node certainly =
has real-world costs that shouldn't be ignored.<br class=3D"">There are =
plenty of advocates who argue that Bitcoin should strive to keep<br =
class=3D"">it feasible for the average user to run their own node (as =
opposed to<br class=3D"">Satoshi's vision of beefy servers in data =
centers.) My impression is that<br class=3D"">even most of these =
advocates agree that it will be acceptable to eventually<br =
class=3D"">increase block sizes as resources become faster and cheaper =
because it won't<br class=3D"">be 'pricing out' the average user from =
running their own node. If this is<br class=3D"">the case, it seems to =
me that we have a problem given that there is no<br class=3D"">established=
 baseline for the acceptable performance / hardware cost<br =
class=3D"">requirements to run a node. I'd really like to see further =
clarification<br class=3D"">from these advocates around the acceptable =
cost of running a node and how we<br class=3D"">can measure the global =
reduction in hardware and bandwidth costs in order to<br =
class=3D"">establish a baseline that we can use to justify additional =
resource usage by<br class=3D"">nodes.<br class=3D""></blockquote><br =
class=3D"">Although I don't have a concrete proposals myself, I agree =
that<br class=3D"">without having any common notion of what the "minimal =
target hardware"<br class=3D"">looks like, it is very difficult to =
discuss other things that depend<br class=3D"">on that.<br class=3D"">If =
there's data that shows that a 100 usd raspberry pi with a 1 MB<br =
class=3D"">connection in say, India (I actually have no idea about =
internet<br class=3D"">speeds there) size X is a viable full node, then =
I don't think anybody<br class=3D"">can reasonably oppose to rising the =
block size to X, and such a<br class=3D"">hardfork can perfectly be =
uncontroversial.<br class=3D"">I'm exaggerating ultra-low =
specifications, but it's just an example to<br class=3D"">illustrate =
your point.<br class=3D"">There was a thread about formalizing such =
"minimum hardware<br class=3D"">requirements", but I think the =
discussion simply finished there:<br class=3D"">- Let's do this<br =
class=3D"">- Yeah, let's do it<br class=3D"">- +1, let's have concrete =
values, I generally agree.<br class=3D""></div></blockquote></div><br =
class=3D""></div></body></html>=

--Apple-Mail=_FDE81B26-1D41-4BC2-A389-10580F19EF5E--

--Apple-Mail=_9532C849-0228-4D0F-9173-88B1A25818EC
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

iQIcBAEBCgAGBQJVsVQKAAoJEJNAI64YFENU5A0QAJ5F4QqI76QgyaBZlepbLzUt
Y3kfJwDBlgh45i0Ltqs33yBKFi5cv1I+hKgiQtvecXGcRFvoRMTKj+KOfIcGyNq6
mNBWB8FpCsisK3XeKqWsn9I45etOD/VVhw+YI1cUrYTha2kGVeL+1pJbMKUHZmtZ
I1o56HPAhnioE+UV/qBlDLmNtZ8VedBfDAf6d8ECvutC+tpSOB4jdyXzrPA7N3Pn
eDBa4iAYZxvDUHAV/GnO1eFnC0XvQd53mzwLPZmn7AHvl0Y5i0n+qNgwM0pY3Acn
guH+tHt7iHH54EX3lU3KtsmZ4e127hJOBohOkcVFXKmUQDiT2upEb/5vVKHZ4P8P
a9GXsAVZyoNTHIUVDPZhfBGbb9CKldEZ6s1W+O2MJZ9EnSlmEX9ECC3uJbsCJ2Wi
uSG7XgXYSHM+PTTzS42PsMXTv5kZLrzHo7IcZXwG8M59aZ+0bLdmM+AS5WrK5NCi
LKDMvhwsukBAKmt3ML9yzfFSDWk08RYkC8l0nUb9bx5boxhv6sMLlwjeShPDeuSt
3yJegOMZLCBM3S7o4+nnfmVwT2iTiF4yd+47ntp/RQvwVG1IVv75acXtLbtqNJdn
TCb4S3D6jxBs4f2jJ2JxNkxPeebEqa1U8/pPLj7qWTewpRT4veW+N4CP+j93hfyf
LVJsYhG25FEIzS/4sKcQ
=TbZw
-----END PGP SIGNATURE-----

--Apple-Mail=_9532C849-0228-4D0F-9173-88B1A25818EC--