MIME-Version: 1.0
In-Reply-To: <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>
	<D161F6BB-BFB1-4B9F-B024-D60A170F393C@gmail.com>
Date: Thu, 23 Jul 2015 16:42:42 -0700
Message-ID: <CALqmWPC8PdSPS3chhnjBaTixrvvg0VrEaXzd3OvbXifkMs0DUw@mail.gmail.com>
From: Benedict Chan <bencxr@fragnetics.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
Precedence: list

On Thu, Jul 23, 2015 at 1:52 PM, Eric Lombrozo via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo <elombrozo@gmail.com> wrot=
e:
>>
>> Mainstream usage of cryptocurrency will be enabled primarily by direct
>> party-to-party contract negotiation=E2=80=A6with the use of the blockcha=
in primarily
>> as a dispute resolution mechanism. The block size isn=E2=80=99t about sc=
aling but
>> about supply and demand of finite resources. As demand for block space
>> increases, we can address it either by increasing computational resource=
s
>> (block size) or by increasing fees. But to do the former we need a way t=
o
>> offset the increase in cost by making sure that those who contribute sai=
d
>> resources have incentive to do so.=E2=80=99
>
>
> I should also point out, improvements in hardware and network infrastruct=
ure
> can also reduce costs=E2=80=A6and we could very well have a model where r=
esource
> 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 worl=
d
> 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 mainstr=
eam
> adoption, we=E2=80=99ll have to pass through a period of quasi-exponentia=
l growth in
> userbase (until the market saturates=E2=80=A6or until the network resourc=
es run
> out). Unless we=E2=80=99re able to achieve a validation complexity of O(p=
olylog 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 sati=
sfy
> demand if we insist on requiring global validation for all transactions.
>

Scaling the network will come in the form of a combination of many
optimizations. Just because we do not know for sure how to eventually
serve 7 billion people does not mean we should make decisions on
global validation that impact our ability to serve the current set of
users.

Also, blocking a change because it's "more important to address issues
such as..." other improvements will further slow down the discussion.
I believe an increase will not prevent the development of other
improvements that we need - in contrast, the sooner we can get over
the limit (which, as you agree, needs to be changed at some point),
the sooner we can get back to work.

>
> 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 kee=
p
> 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 eventual=
ly
> increase block sizes as resources become faster and cheaper because it wo=
n'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.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>