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
189
190
191
192
193
194
195
196
197
198
199
200
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id F0D548C8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Aug 2015 18:10:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f182.google.com (mail-io0-f182.google.com
[209.85.223.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2B2E7213
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Aug 2015 18:10:50 +0000 (UTC)
Received: by ioii16 with SMTP id i16so119336928ioi.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 07 Aug 2015 11:10:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=IluwGD6SxCBUgVx5aFOizG2tPNVuA3GZ77W6iJ7py50=;
b=Mnv+MZekrdSwE7uPBA+ycZ7lIfABAuD6MXxIJ2OFWYS/kFkA2nRu2pUpfveKgxBpI8
UplST+zaQ16qAb6k47WxBMjIDkuOg/2sp0dTPhdgTkhB2yWfd7kRcCJNB/gsU7xfHXm9
+kwFsG884+1FZXCJEseaHs+34xepRU4/EIrfN/ZSt+la5rPpqeKd9GH715wYsI/eEFDx
+h7pGaklAj4CBhOcZ4TZ1bNOMiTdL0kZ2Qqo05ft7BRuxTO/Inkj5Mg2mGjXFh0/A4xU
XrryCau747MAw2n0MRpKeG/aCboNTq52xtSoS5fHLBtiq84Vr3LEgsYCgkvBu1cpvoip
A6FA==
MIME-Version: 1.0
X-Received: by 10.107.37.142 with SMTP id l136mr9850205iol.126.1438971049582;
Fri, 07 Aug 2015 11:10:49 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Fri, 7 Aug 2015 11:10:48 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Fri, 7 Aug 2015 11:10:48 -0700 (PDT)
In-Reply-To: <CABsx9T3kwATCovg2FeamNPdJbhM_ypJEd_6fcwfknYsKCBQkbQ@mail.gmail.com>
References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
<CALgxB7vqA=o1L0aftMtzNYC_OYJcVw6vuqUeB3a2F6d+VuoJkA@mail.gmail.com>
<CAPg+sBj1qCRvtZ2F1v_1JUTqwws6JOmi+8BYKVoCWPRBSs-Y=g@mail.gmail.com>
<1542978.eROxFinZd4@coldstorage>
<CAPg+sBiCH12i6-WEx++zTbovn=2FZqKAKxfnGkruU_Ah-y-_4g@mail.gmail.com>
<CABsx9T3kwATCovg2FeamNPdJbhM_ypJEd_6fcwfknYsKCBQkbQ@mail.gmail.com>
Date: Fri, 7 Aug 2015 20:10:48 +0200
Message-ID: <CAPg+sBhF-jZk2FD8OiiWjW7453ztniBc3KvZyxgvjOVDXq0eqQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a1140269a40b14b051cbc8e17
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fwd: Block size following technological growth
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: Fri, 07 Aug 2015 18:10:51 -0000
--001a1140269a40b14b051cbc8e17
Content-Type: text/plain; charset=UTF-8
On Aug 7, 2015 7:50 PM, "Gavin Andresen" <gavinandresen@gmail.com> wrote:
>
>
> On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> If the incentives for running a node don't weight up against the
cost/difficulty using a full node yourself for a majority of people in the
ecosystem, I would argue that there is a problem. As Bitcoin's fundamental
improvement over other systems is the lack of need for trust, I believe
that with increased adoption should also come an increased (in absolute
terms) incentive for people to use a full node. I'm seeing the opposite
trend, and that is worrying IMHO.
>
>
> Are you saying that unless the majority of people in the ecosystem decide
to trust nothing but the genesis block hash (decide to run a full node)
there is a problem?
I shouldn't have said majority, sorry. But I do believe that as the odds at
stake in the system go up, so should those who take an interest in
verifying. That doesn't seem to be the case, and is a problem, where that
is a result of the block chain size or not.
> If so, then we do have a fundamental difference of opinion, but I've
misunderstood how you think about trust/centralization/convenience
tradeoffs in the past.
>
> I believe people in the Bitcoin ecosystem will choose different
tradeoffs, and I believe that is OK-- people should be free to make those
tradeoffs.
I agree. Though I believe that the blockchain itself cannot offer many
tradeoffs, and by trying to make it scale we hurt the whole system. The
place to introduce tradeoffs is in layers on top - there you can build
systems with various levels of trust without hurting others.
> And given that the majority of people in the ecosystem were deciding that
using a centralized service or an SPV-level-security wallet was better even
two or three years ago when blocks were tiny (I'd have to go back and dig
up number-of-full-nodes and number-of-active-wallets at the big web-wallet
providers, but I bet there were an order of magnitude more people using
centralized services than running full nodes even back then).
That's inevitable, I'm sure.
> I firmly believe that block size has very little to do with the decision
to run a full node or not.
Within certain limits, maybe not. Within certain limits, maybe it also does
not incentivize trusted miner setups like SPV mining (which hurt the
security of SPV nodes tremendously).
But if the reason for increasing is because you fear a change of economics,
then it means you prefer not dealing with that change. I believe you prefer
not dealing with it ever, and would rather have a system where as much as
possible happens on-chain, even when we unknowingly go beyond those limits.
I think we don't do the ecosystem a service by promising that such a future
is possible without compromises.
So, I think the block size should follow technological evolution, and not
reenforce the belief that the block size should follow demand. There will
always be demand, and we should learn to deal with it.
--
Pieter
--001a1140269a40b14b051cbc8e17
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Aug 7, 2015 7:50 PM, "Gavin Andresen" <<a href=3D"mailto:ga=
vinandresen@gmail.com">gavinandresen@gmail.com</a>> wrote:<br>
><br>
><br>
> On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev <<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.lin=
uxfoundation.org</a>> wrote:<br>
>><br>
>> If the incentives for running a node don't weight up against t=
he cost/difficulty using a full node yourself for a majority of people in t=
he ecosystem, I would argue that there is a problem. As Bitcoin's funda=
mental improvement over other systems is the lack of need for trust, I beli=
eve that with increased adoption should also come an increased (in absolute=
terms) incentive for people to use a full node. I'm seeing the opposit=
e trend, and that is worrying IMHO.<br>
><br>
><br>
> Are you saying that unless the majority of people in the ecosystem dec=
ide to trust nothing but the genesis block hash (decide to run a full node)=
there is a problem?</p>
<p dir=3D"ltr">I shouldn't have said majority, sorry. But I do believe =
that as the odds at stake in the system go up, so should those who take an =
interest in verifying. That doesn't seem to be the case, and is a probl=
em, where that is a result of the block chain size or not.</p>
<p dir=3D"ltr">> If so, then we do have a fundamental difference of opin=
ion, but I've misunderstood how you think about trust/centralization/co=
nvenience tradeoffs in the past.<br>
><br>
> I believe people in the Bitcoin ecosystem will choose different tradeo=
ffs, and I believe that is OK-- people should be free to make those tradeof=
fs.</p>
<p dir=3D"ltr">I agree. Though I believe that the blockchain itself cannot =
offer many tradeoffs, and by trying to make it scale we hurt the whole syst=
em. The place to introduce tradeoffs is in layers on top - there you can bu=
ild systems with various levels of trust without hurting others.</p>
<p dir=3D"ltr">> And given that the majority of people in the ecosystem =
were deciding that using a centralized service or an SPV-level-security wal=
let was better even two or three years ago when blocks were tiny (I'd h=
ave to go back and dig up number-of-full-nodes and number-of-active-wallets=
at the big web-wallet providers, but I bet there were an order of magnitud=
e more people using centralized services than running full nodes even back =
then).</p>
<p dir=3D"ltr">That's inevitable, I'm sure.</p>
<p dir=3D"ltr">> I firmly believe that block size has very little to do =
with the decision to run a full node or not.</p>
<p dir=3D"ltr">Within certain limits, maybe not. Within certain limits, may=
be it also does not incentivize trusted miner setups like SPV mining (which=
hurt the security of SPV nodes tremendously).</p>
<p dir=3D"ltr">But if the reason for increasing is because you fear a chang=
e of economics, then it means you prefer not dealing with that change. I be=
lieve you prefer not dealing with it ever, and would rather have a system w=
here as much as possible happens on-chain, even when we unknowingly go beyo=
nd those limits. I think we don't do the ecosystem a service by promisi=
ng that such a future is possible without compromises.</p>
<p dir=3D"ltr">So, I think the block size should follow technological evolu=
tion, and not reenforce the belief that the block size should follow demand=
. There will always be demand, and we should learn to deal with it.</p>
<p dir=3D"ltr">-- <br>
Pieter<br>
</p>
--001a1140269a40b14b051cbc8e17--
|
