1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
|
Return-Path: <bencxr@fragnetics.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 612A242A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 23:42:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com
[209.85.212.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3D82C1CE
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 23:42:43 +0000 (UTC)
Received: by wibud3 with SMTP id ud3so44449163wib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 16:42:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=w7rgPlJdvfpRMuKlW+7Q0p3jrvLMkJjejeR2FDEkcSU=;
b=aq/dDo/BDvFHVs643UFEMpTicGjncy8J77kmvyEvOVNIdWuhULyKXoGzX3E+0sj2Sj
/b5eVi4svhQXL4AxTLo3RYSVUFOYYoG8YNInpP2WKjgzR6H9MJEd3XyHN7Iv/9njF+zA
UCT0esrPpJIATo3j3xjZqup5+dq18s/22iAJW0ACw4KrWYjdEU6LW1PEdkjENhsZ2MPR
gVFWVha48on6T9CzxH9xL9ZMxlS3Q+yLNm8DjfsQemsdxJyJ2yMLILwblDfVFJrmkmXk
Z+Jdh+35sx/Ig1FsQQAxSeMcATDpR+G7pg8J0ytyF0NOp/yZNJv4qQLC44X/vNCj7IHX
fDCg==
X-Gm-Message-State: ALoCoQnCvRu0ACfynQbKItYOuAanVYmEIkVwF4HN+554mxKLwmpYHEFjhUrayF3NqUWGJ5ZlnE9m
MIME-Version: 1.0
X-Received: by 10.180.84.230 with SMTP id c6mr1430465wiz.32.1437694962798;
Thu, 23 Jul 2015 16:42:42 -0700 (PDT)
Received: by 10.194.136.209 with HTTP; Thu, 23 Jul 2015 16:42:42 -0700 (PDT)
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
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 23:42:45 -0000
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
>
|
