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
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
|
Return-Path: <lescoutinhovr@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DF420B63
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Apr 2017 15:58:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com
[209.85.220.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3D2DAFF
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Apr 2017 15:58:45 +0000 (UTC)
Received: by mail-qk0-f177.google.com with SMTP id y63so45102988qkd.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Apr 2017 08:58:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=2NBPHM3s/lbDNvEGz6bBc9waKltON/7gsIG+jwRnWvM=;
b=smmxyC/KekrRcI0YGLJ+LtS4Viprai6oreKacWFhGX12EWjCNHprE0xCs+8usJzq5L
fBDy+Riljj1FRFxahjrkyZerpaD8sQiRVt/rHXfEG54BH4KyBermOmhAVit9tZDXhJhZ
wxBmpD8Xqg/o/cIrjC7wJFCkvN235zTdkjhDWqvRjhh1cNkkDHqvMrSvCeFsjXduqwPK
TkElEFigDMoh8j1jQTW41TP+JHrNGG5JnuZvVHZWqt5XihdgSJgCGS2qf7DQxeZxs2n7
8HjftPU50YkdJ7KpJ4vr3/KJVs26A3ixZjsIQGxwGxWAb1H2gv6VdB84RUP30Kw8h67V
iLuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=2NBPHM3s/lbDNvEGz6bBc9waKltON/7gsIG+jwRnWvM=;
b=cc0nVid0lm9XxWGjDI/84ea52z1cO5mQVZE0SRbVD6WtE4BG1G2BPZMTyO33TsMEgE
rNU7shC8/asFQKuM4FRhYkfi+TTB6dqguH9ThVWaR28w2XP+heb2xJMu5hfy6frvh768
81SJ7YF2txJz0P1CsI+XvCjD8Vkd/ayvWAZ0Us7MGPvXS8kh/61Qm07LWehq4B8otzok
z7bPffqWi01RxgznRN/Xd2ohqrVpD2ENnuyZVMzRDRAtO0a/HGMBy8cO7n3SIgRKa0E5
ps+Y5dk2O+RKmAq0IfOc565FY8SArgR7VisNmGqlAwvokF9PnaokiNXjpKuZzGvvrxrU
34NA==
X-Gm-Message-State: AN3rC/4LEzKr7azzQ56wXxuwvce+GfCKDRCEKnTo9+apQsCDYkQymR8f
MGP31LoiNy0UjZHM0/vqiDajiL1U9w==
X-Received: by 10.55.170.209 with SMTP id t200mr14749260qke.176.1492790324394;
Fri, 21 Apr 2017 08:58:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.38.9 with HTTP; Fri, 21 Apr 2017 08:58:43 -0700 (PDT)
In-Reply-To: <CA+voGJT7tfHS-6bEqjhnOTz=jVidg7AAEXSis_GvqVvBZdRy0w@mail.gmail.com>
References: <CAFVRnypbQQ-vsSLqv48cYaqTCty4R1DmFRqfAvxe4mAqyQNXxQ@mail.gmail.com>
<CAJN5wHW=p+q+DT9R=uheLxOjKBX=xcB+fOZR2KACgJO9SdXypw@mail.gmail.com>
<CA+voGJT7tfHS-6bEqjhnOTz=jVidg7AAEXSis_GvqVvBZdRy0w@mail.gmail.com>
From: Leandro Coutinho <lescoutinhovr@gmail.com>
Date: Fri, 21 Apr 2017 12:58:43 -0300
Message-ID: <CAN6UTaw0N8g+Kk0AYENa9WnXP7tH6H7rikkZ+9N4zesdodrJXw@mail.gmail.com>
To: David Kaufman <david@gigawatt.com>
Content-Type: multipart/alternative; boundary=94eb2c06e8ae02deef054daf5575
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 21 Apr 2017 16:02:01 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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, 21 Apr 2017 15:58:47 -0000
--94eb2c06e8ae02deef054daf5575
Content-Type: text/plain; charset=UTF-8
Maybe it already exists ...
#9484 <https://github.com/bitcoin/bitcoin/pull/9484> 812714f
<https://github.com/bitcoin/bitcoin/commit/812714f> Introduce assumevalid
setting to skip validation presumed valid scripts (gmaxwell)
https://github.com/bitcoin/bitcoin/pull/9484
..., but ...
It would be very interesting if a new node could decide to be a pruned node:
- it would need to trust one or more peers for the initial blockchain
download, because the blocks downloaded would not be validated
- it would decide a time from when to get the blocks, like a week before
- once a day a routine would run that would prune blocks older than the
chosen time
"
*The unspent transaction outputs (which is the only essential piece ofdata
necessary for validation) are already kept in a separate database,so
technically removing old blocks is perfectly possible.*" Pieter Wuille
https://bitcoin.stackexchange.com/questions/11170/why-is-pruning-not-considered-already-at-the-moment
On Fri, Apr 21, 2017 at 10:35 AM, David Kaufman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Danny,
>
> On Mon, Apr 17, 2017 at 3:11 AM, Danny Thorpe wrote:
> >
> > 1TB HDD is now available for under $40 USD. How is the 100GB storage
> > requirement preventing anyone from setting up full nodes?
>
> Yeah, but that's because most people (well, using myself as the
> "target market" anyway) are upgrading to SSD's for the faster boot and
> response times. Modern consumer OS's run incredibly slow on
> non-ssd drives! And since the vast majority of consumer laptops sold
> today fall into the $400 to $700 range, a 200 - 500gb SSD is about the
> most storage upgrade people can afford.
>
> And so I think David's premise, that having to devote only 30GB to
> running a full node instead of 100, would remove a major obstacle that
> prevents many more people running full bitcoin nodes.
>
> My only suggestion is, does it scale? I mean, if the bitcoin network
> volume grows exponentially and in 2 years the blockchain is 500GB, can
> the "small node" be adjusted down from one fifth of the blockchain to
> just one-tenth, or one twentieth? Can different smalInesses
> interoperate? Can I choose to store a small node with 20 - 30% of the
> blockchain, while others chose to share just 5% or 10% of it? Can I run
> "less small" node today that's 50GB?
>
> Can the default install be a "small node" that requires about 30GB of
> storage (if that is indeed the sweet spot for enticing many more users to
> bringing nodes online), but allow the user at install time, to choose *how*
> small? To, say, drag a slider anywhere up and down the range from
> 10GB to 100GB?
>
> If not, then it will have to be revisited constantly as the blockchain
> grows, and disk storage prices drop. I suspect the blockchain will
> grow in size, at some point in the not too distant future, much faster
> than storage prices drop, so making small, smaller and smallest nodes
> that can be configured to store more or less of it will be necessary
> to motivate most users to run nodes at all. But when that happens,
> there is likely to be exponentially *more* people using bitcoin, too!
> So an exponentially growing number of users running (smaller and
> smaller) nodes would take up the slack.
>
> Then, the blockchain would begin to look a lot more like a bittorrent,
> right? ;-) but -- happily -- one that you never need to download fully.
>
> -dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--94eb2c06e8ae02deef054daf5575
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Maybe it already exists ...<br><br><a href=3D"https:/=
/github.com/bitcoin/bitcoin/pull/9484">#9484</a> <a href=3D"https://github.=
com/bitcoin/bitcoin/commit/812714f"><code class=3D"gmail-highlighter-rouge"=
>812714f</code></a> Introduce assumevalid setting to skip validation presum=
ed valid scripts (gmaxwell)<br><a href=3D"https://github.com/bitcoin/bitcoi=
n/pull/9484">https://github.com/bitcoin/bitcoin/pull/9484</a><br><br>..., b=
ut ...<br>It would be very interesting if a new node could decide to be a p=
runed node:<br>=C2=A0 - it would need to trust one or more peers for the in=
itial blockchain download, because the blocks downloaded would not be valid=
ated</div><div>=C2=A0 - it would decide a time from when to get the blocks,=
like a week before</div><div>=C2=A0 - once a day a routine would run that =
would prune blocks older than the chosen time<br><br>"<i>The unspent t=
ransaction outputs=20
(which is the only essential piece of<br>data necessary for validation) are
already kept in a separate database,<br>so technically removing old blocks
is perfectly possible.</i>" Pieter Wuille<br><a href=3D"https://bitco=
in.stackexchange.com/questions/11170/why-is-pruning-not-considered-already-=
at-the-moment">https://bitcoin.stackexchange.com/questions/11170/why-is-pru=
ning-not-considered-already-at-the-moment</a><br><br></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Apr 21, 2017 at 10:=
35 AM, David Kaufman via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@list=
s.linuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">Hi Danny,<br>
<br>
On Mon, Apr 17, 2017 at 3:11 AM, Danny Thorpe wrote:<br>
><br>
> 1TB HDD is now available for under $40 USD.=C2=A0 How is the 100GB sto=
rage<br>
> requirement preventing anyone from setting up full nodes?<br>
<br>
Yeah, but that's because most people (well, using myself as the<br>
"target market" anyway) are upgrading to SSD's for the faster=
boot and<br>
response times.=C2=A0 Modern consumer OS's run incredibly slow on<br>
non-ssd drives!=C2=A0 And since the vast majority of consumer laptops sold<=
br>
today fall into the $400 to $700 range, a 200 - 500gb SSD is about the<br>
most storage upgrade people can afford.<br>
<br>
And so I think David's premise, that having to devote only 30GB to<br>
running a full node instead of 100, would remove a major obstacle that<br>
prevents many more people running full bitcoin nodes.<br>
<br>
My only suggestion is, does it scale?=C2=A0 I mean, if the bitcoin network<=
br>
volume grows exponentially and in 2 years the blockchain is 500GB, can<br>
the "small node" be adjusted down from one fifth of the blockchai=
n to<br>
just one-tenth, or one twentieth?=C2=A0 Can different smalInesses<br>
interoperate? Can I choose to store a small node with 20 - 30% of the<br>
blockchain, while others chose to share just 5% or 10% of it? Can I run<br>
"less small" node today that's 50GB?<br>
<br>
Can the default install be a "small node" that requires about 30G=
B of<br>
storage (if that is indeed the sweet spot for enticing many more users to<b=
r>
bringing nodes online), but allow the user at install time, to choose *how*=
<br>
small? To, say, drag a slider anywhere up and down the range from<br>
10GB to 100GB?<br>
<br>
If not, then it will have to be revisited constantly as the blockchain<br>
grows, and disk storage prices drop.=C2=A0 I suspect the blockchain will<br=
>
grow in size, at some point in the not too distant future, much faster<br>
than storage prices drop, so making small, smaller and smallest nodes<br>
that can be configured to store more or less of it will be necessary<br>
to motivate most users to run nodes at all.=C2=A0 But when that happens,<br=
>
there is likely to be exponentially *more* people using bitcoin, too!<br>
So an exponentially growing number of users running (smaller and<br>
smaller) nodes would take up the slack.<br>
<br>
Then, the blockchain would begin to look a lot more like a bittorrent,<br>
right? ;-) but -- happily -- one that you never need to download fully.<br>
<br>
-dave<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div><br></div>
--94eb2c06e8ae02deef054daf5575--
|
