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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gappleto97@gmail.com>) id 1YsDU4-0002ip-Di
for bitcoin-development@lists.sourceforge.net;
Tue, 12 May 2015 16:56:44 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.52 as permitted sender)
client-ip=209.85.220.52; envelope-from=gappleto97@gmail.com;
helo=mail-pa0-f52.google.com;
Received: from mail-pa0-f52.google.com ([209.85.220.52])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YsDU3-0000Co-7K
for bitcoin-development@lists.sourceforge.net;
Tue, 12 May 2015 16:56:44 +0000
Received: by pabtp1 with SMTP id tp1so19061359pab.2
for <bitcoin-development@lists.sourceforge.net>;
Tue, 12 May 2015 09:56:37 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.66.249.198 with SMTP id yw6mr29354867pac.149.1431449797567;
Tue, 12 May 2015 09:56:37 -0700 (PDT)
Received: by 10.66.85.165 with HTTP; Tue, 12 May 2015 09:56:37 -0700 (PDT)
In-Reply-To: <CAJHLa0O5OxaX5g3u=dnCY6Lz_gK3QZgQEPNcWNVRD4JziwAmvg@mail.gmail.com>
References: <CANJO25J1WRHtfQLVXUB2s_sjj39pTPWmixAcXNJ3t-5os8RPmQ@mail.gmail.com>
<CANJO25JTtfmfsOQYOzJeksJn3CoKE3W8iLGsRko-_xd4XhB3ZA@mail.gmail.com>
<CAJHLa0O5OxaX5g3u=dnCY6Lz_gK3QZgQEPNcWNVRD4JziwAmvg@mail.gmail.com>
Date: Tue, 12 May 2015 12:56:37 -0400
Message-ID: <CANJO25KWmUhpFbSycYBZmowrBtLZPwXDs-eoXRgcAoaMuE0Rzg@mail.gmail.com>
From: gabe appleton <gappleto97@gmail.com>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: multipart/alternative; boundary=089e0160c916b2ac560515e5604d
X-Spam-Score: -0.3 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gappleto97[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (gappleto97[at]gmail.com)
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YsDU3-0000Co-7K
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed additional options for pruned
nodes
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2015 16:56:44 -0000
--089e0160c916b2ac560515e5604d
Content-Type: text/plain; charset=UTF-8
Yes, but that just increases the incentive for partially-full nodes. It
would add to the assumed-small number of full nodes.
Or am I misunderstanding?
On Tue, May 12, 2015 at 12:05 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
> A general assumption is that you will have a few archive nodes with the
> full blockchain, and a majority of nodes are pruned, able to serve only the
> tail of the chains.
>
>
> On Tue, May 12, 2015 at 8:26 AM, gabe appleton <gappleto97@gmail.com>
> wrote:
>
>> Hi,
>>
>> There's been a lot of talk in the rest of the community about how the
>> 20MB step would increase storage needs, and that switching to pruned nodes
>> (partially) would reduce network security. I think I may have a solution.
>>
>> There could be a hybrid option in nodes. Selecting this would do the
>> following:
>> Flip the --no-wallet toggle
>> Select a section of the blockchain to store fully (percentage based,
>> possibly on hash % sections?)
>> Begin pruning all sections not included in 2
>> The idea is that you can implement it similar to how a Koorde is done, in
>> that the network will decide which sections it retrieves. So if the user
>> prompts it to store 50% of the blockchain, it would look at its peers, and
>> at their peers (if secure), and choose the least-occurring options from
>> them.
>>
>> This would allow them to continue validating all transactions, and still
>> store a full copy, just distributed among many nodes. It should overall
>> have little impact on security (unless I'm mistaken), and it would
>> significantly reduce storage needs on a node.
>>
>> It would also allow for a retroactive --max-size flag, where it will
>> prune until it is at the specified size, and continue to prune over time,
>> while keeping to the sections defined by the network.
>>
>> What sort of side effects or network vulnerabilities would this
>> introduce? I know some said it wouldn't be Sybil resistant, but how would
>> this be less so than a fully pruned node?
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
--089e0160c916b2ac560515e5604d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yes, but that just increases the incentive for partially-f=
ull nodes. It would add to the assumed-small number of full nodes.<div><br>=
</div><div>Or am I misunderstanding?</div></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Tue, May 12, 2015 at 12:05 PM, Jeff Garzi=
k <span dir=3D"ltr"><<a href=3D"mailto:jgarzik@bitpay.com" target=3D"_bl=
ank">jgarzik@bitpay.com</a>></span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">A general assumption is that you will have a few arch=
ive nodes with the full blockchain, and a majority of nodes are pruned, abl=
e to serve only the tail of the chains.<div><br></div></div><div class=3D"g=
mail_extra"><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Tue, M=
ay 12, 2015 at 8:26 AM, gabe appleton <span dir=3D"ltr"><<a href=3D"mail=
to:gappleto97@gmail.com" target=3D"_blank">gappleto97@gmail.com</a>></sp=
an> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D=
"h5"><p dir=3D"ltr">Hi,</p>
<p dir=3D"ltr">There's been a lot of talk in the rest of the community =
about how the 20MB step would increase storage needs, and that switching to=
pruned nodes (partially) would reduce network security. I think I may have=
a solution.</p>
<p dir=3D"ltr">There could be a hybrid option in nodes. Selecting this woul=
d do the following:<br>
Flip the --no-wallet toggle<br>
Select a section of the blockchain to store fully (percentage based, possib=
ly on hash % sections?)<br>
Begin pruning all sections not included in 2<br>
The idea is that you can implement it similar to how a Koorde is done, in t=
hat the network will decide which sections it retrieves. So if the user pro=
mpts it to store 50% of the blockchain, it would look at its peers, and at =
their peers (if secure), and choose the least-occurring options from them.<=
/p>
<p dir=3D"ltr">This would allow them to continue validating all transaction=
s, and still store a full copy, just distributed among many nodes. It shoul=
d overall have little impact on security (unless I'm mistaken), and it =
would significantly reduce storage needs on a node.</p>
<p dir=3D"ltr">It would also allow for a retroactive --max-size flag, where=
it will prune until it is at the specified size, and continue to prune ove=
r time, while keeping to the sections defined by the network. </p>
<p dir=3D"ltr">What sort of side effects or network vulnerabilities would t=
his introduce? I know some said it wouldn't be Sybil resistant, but how=
would this be less so than a fully pruned node? </p>
<br></div></div>-----------------------------------------------------------=
-------------------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><span class=3D"HOEnZb"><font color=3D"#888888"><br><=
br clear=3D"all"><div><br></div>-- <br><div>Jeff Garzik<br>Bitcoin core dev=
eloper and open source evangelist<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a hr=
ef=3D"https://bitpay.com/" target=3D"_blank">https://bitpay.com/</a></div>
</font></span></div>
</blockquote></div><br></div>
--089e0160c916b2ac560515e5604d--
|
