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
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>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
Precedence: list


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