From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 27D5D847 for ; 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 ; Thu, 23 Jul 2015 20:52:31 +0000 (UTC) Received: by pdbbh15 with SMTP id bh15so1839977pdb.1 for ; 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 In-Reply-To: Date: Thu, 23 Jul 2015 13:52:26 -0700 Message-Id: References: <55B113AF.40500@thinlink.com> <6F436293-9E2B-461C-B105-FC4CF9EBFC69@gmail.com> To: =?utf-8?Q?Jorge_Tim=C3=B3n?= 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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 = wrote: >=20 > On Thu, Jul 23, 2015 at 9:52 PM, Jameson Lopp via bitcoin-dev > 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
On Thu, Jul 23, 2015 at 3:14 PM, Eric = Lombrozo <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:

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.

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