summaryrefslogtreecommitdiff
path: root/1d/bcd1e9760fc885ed807f8078adde1c8f3c1bcb
blob: 04c2a47b8363455b9006753851916539bd0deec3 (plain)
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
249
250
251
252
Return-Path: <vitteaymeric@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D4ABA955
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 18 Apr 2017 23:19:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 90376D4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 18 Apr 2017 23:19:04 +0000 (UTC)
Received: by mail-wm0-f48.google.com with SMTP id u2so8911086wmu.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 18 Apr 2017 16:19:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=subject:to:references:from:message-id:date:user-agent:mime-version
	:in-reply-to; bh=q3lO3kiEO9t8d9nXzy49XL93/FYK29O6AIHYjFpnvu0=;
	b=n/Iw6sT2K7Hl9QKHz4Q8y1fImTFXkzSWtgKrV13XPXDS6UTIcv6MWsip6RFj86At13
	7o7x8UiodSU326TuLD+4ThEVWNYFijvZvmn1O+kxePvdprTr4blbDAbwJXwf54aJaGah
	BSsIiDcomBt+fC+YoIi6Nox78b09z9HL6NhWnwXjXoz+mreZAphAA8fQYgR1bmdSUx8t
	mWTXD4xFouB8xqjL/KVG9gIVkMBzCrJ97N9dOeVlImcmANtfb7zNOUIMyGtQdKlC3v5S
	Nj5mgpxDT9LvlR8baHYfRISHqMEVlNijoojioEsaWL/2ps6Af2XH8ir7QTBjk7cITsu+
	I/GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:subject:to:references:from:message-id:date
	:user-agent:mime-version:in-reply-to;
	bh=q3lO3kiEO9t8d9nXzy49XL93/FYK29O6AIHYjFpnvu0=;
	b=MiPTMnviKuJ7CkUeml2/rkv6/uIqderWBCpq4yFWsMk64l62V2cPEnE3boRHdvYWcg
	WUvKlMRwycKjVIgPe7hEZCU5Mbxqmon43UbHxuVNDlFj8wqxsFztL2bmIRc5nSPGhQdg
	+OhB3/0+AOPCSe19pX4h/EySTus9ImU13RgFL0/51lVqD/Vf9v68YvQrhcoTkSanHpDO
	m1lAZDKHNdqSifXLlT5XlzVaesftmoxdM+ZS/4ysVr920bcswB+62kj5LKaNwvb0aQRI
	So9TKTXdMEl7UCZd3eT9F4XVl30QqyfWXEA1XkiCwtTybOEr2DXDX70EpPhKKdAyjl1i
	4xBQ==
X-Gm-Message-State: AN3rC/6f8WQpYKvaPAltsJcFITqz8OiIUGYjLSJBiiiSpdDqBqSkONcE
	yp9KLf0SahInFLPs
X-Received: by 10.28.178.17 with SMTP id b17mr255068wmf.23.1492557542881;
	Tue, 18 Apr 2017 16:19:02 -0700 (PDT)
Received: from [192.168.1.10] (ANice-654-1-153-20.w86-205.abo.wanadoo.fr.
	[86.205.80.20]) by smtp.googlemail.com with ESMTPSA id
	r29sm749444wrr.45.2017.04.18.16.19.01
	for <bitcoin-dev@lists.linuxfoundation.org>
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Apr 2017 16:19:02 -0700 (PDT)
To: bitcoin-dev@lists.linuxfoundation.org
References: <CAFVRnypbQQ-vsSLqv48cYaqTCty4R1DmFRqfAvxe4mAqyQNXxQ@mail.gmail.com>
	<2226058.Q8lHjYE4Pt@strawberry>
	<CAE-z3OVXLKqyBb3R5yzOYdnRALot4KUhJ53r9y2jXkf6Yt=KnA@mail.gmail.com>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <ccb96920-4387-ed91-e03e-15f4b2772aa3@gmail.com>
Date: Wed, 19 Apr 2017 01:19:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:45.0) Gecko/20100101
	Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAE-z3OVXLKqyBb3R5yzOYdnRALot4KUhJ53r9y2jXkf6Yt=KnA@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------1514DC795F898B236CF0BF5D"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.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: Tue, 18 Apr 2017 23:19:05 -0000

This is a multi-part message in MIME format.
--------------1514DC795F898B236CF0BF5D
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

From the initial post " The situation would likely become problematic
quickly if bitcoin-core were to ship with the defaults set to a pruned
node."

Sorry to be straight, I read the (painful) thread below, and most of
what is in there is inept, wrong, obsolete... or biased, cf the first
sentence above, if the idea is to invent a workaround to the fact that
pruning might/will become the default or might/will be set by the users
as the default so full nodes might/will disappear then just say it
clearly instead of proposing this kind of non-solution as a solution to
secure the blockchain

I can't believe this is serious, people now are supposed to prune but
will be forced to host a part of the blockchain, how do you expect this
to work, why people would do this? Knowing that to start pruning they
need a full node, then since we are there, why not continuing with a
full node... but indeed, why should they continue with a full node, and
therefore why should they accept to host a part of the blockchain if
they decline the first proposal?

This is absurd, you are not addressing the first priority given the
context which is to quickly increase the full nodes and which obviously
includes an incentive for people to run them

It gives also the feeling that bitcoin wants to reinvent everything not
capitalizing on/knowing what exists, sorry again but the concepts of the
proposal and others like archival nodes are just funny


Le 18/04/2017 à 15:07, Tier Nolan via bitcoin-dev a écrit :
> This has been discussed before.
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008101.html
>
> including a list of nice to have features by Maxwell
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008110.html
>
> You meet most of these rules, though you do have to download blocks
> from multiple peers.
>
> The suggestion in that thread were for a way to compactly indicate
> which blocks a node has.  Each node would then store a sub-set of all
> the blocks.  You just download the blocks you want from the node that
> has them.
>
> Each node would be recommended to store the last few days worth anyway.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms


--------------1514DC795F898B236CF0BF5D
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>From the initial post " The situation would likely become
      problematic quickly if bitcoin-core were to ship with the defaults
      set to a pruned node."</p>
    <p>Sorry to be straight, I read the (painful) thread below, and most
      of what is in there is inept, wrong, obsolete... or biased, cf the
      first sentence above, if the idea is to invent a workaround to the
      fact that pruning might/will become the default or might/will be
      set by the users as the default so full nodes might/will disappear
      then just say it clearly instead of proposing this kind of
      non-solution as a solution to secure the blockchain<br>
    </p>
    <p>I can't believe this is serious, people now are supposed to prune
      but will be forced to host a part of the blockchain, how do you
      expect this to work, why people would do this? Knowing that to
      start pruning they need a full node, then since we are there, why
      not continuing with a full node... but indeed, why should they
      continue with a full node, and therefore why should they accept to
      host a part of the blockchain if they decline the first proposal?<br>
    </p>
    This is absurd, you are not addressing the first priority given the
    context which is to quickly increase the full nodes and which
    obviously includes an incentive for people to run them<br>
    <br>
    It gives also the feeling that bitcoin wants to reinvent everything
    not capitalizing on/knowing what exists, sorry again but the
    concepts of the proposal and others like archival nodes are just
    funny<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Le 18/04/2017 à 15:07, Tier Nolan via
      bitcoin-dev a écrit :<br>
    </div>
    <blockquote
cite="mid:CAE-z3OVXLKqyBb3R5yzOYdnRALot4KUhJ53r9y2jXkf6Yt=KnA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>
                  <div>
                    <div>This has been discussed before.<br>
                      <br>
                      <a moz-do-not-send="true"
href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008101.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008101.html</a><br>
                      <br>
                    </div>
                    including a list of nice to have features by Maxwell<br>
                    <br>
                    <a moz-do-not-send="true"
href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008110.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008110.html</a><br>
                    <br>
                  </div>
                </div>
              </div>
            </div>
            You meet most of these rules, though you do have to download
            blocks from multiple peers.<br>
            <br>
          </div>
          The suggestion in that thread were for a way to compactly
          indicate which blocks a node has.  Each node would then store
          a sub-set of all the blocks.  You just download the blocks you
          want from the node that has them.<br>
          <br>
        </div>
        Each node would be recommended to store the last few days worth
        anyway.<br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Zcash wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/zcash-wallets">https://github.com/Ayms/zcash-wallets</a>
Bitcoin wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-wallets">https://github.com/Ayms/bitcoin-wallets</a>
Get the torrent dynamic blocklist: <a class="moz-txt-link-freetext" href="http://peersm.com/getblocklist">http://peersm.com/getblocklist</a>
Check the 10 M passwords list: <a class="moz-txt-link-freetext" href="http://peersm.com/findmyass">http://peersm.com/findmyass</a>
Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.org">http://torrent-live.org</a>
Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a>
torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a>
node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a>
GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a></pre>
  </body>
</html>

--------------1514DC795F898B236CF0BF5D--