summaryrefslogtreecommitdiff
path: root/ba/b055ae536e6b1136077d341d9f72ff9270c353
blob: 6b1727b306dd5a105e3c8824e3070992da78d213 (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
Return-Path: <andrew.johnson83@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2C694C0A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 16:41:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f180.google.com (mail-qt0-f180.google.com
	[209.85.216.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AA1DE19F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 16:41:40 +0000 (UTC)
Received: by mail-qt0-f180.google.com with SMTP id n21so17609165qta.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 09:41:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=p9Lj9V2T4OyOPQgmJwywrr6koEfn0eGhpAFrj2RoaUs=;
	b=jhiFsGOhpCYiKANJmCPfA1kH8XDl4qMBajXPDmMwWjF9SUly2q21Pldp7nKtVgAA/V
	NBhH+wUDhY+qq875OAopqW9ir6Sh0vzM35d40CysUOxKuStIT4sZ5cvlYD8qiTFXYryV
	4+cR+mDPwnzuniWtRFaJSq6ED5trf+xr+xMF1T6jdmWLVybIaVj/dFOZSPYMFBmjA5bT
	a0Yh5O2YrPYgEtSoVQFms3hbCbFNgckEJwXVjOkAIWVT9YaTaJR6BEx7vfKqxDCCrkJA
	I3UA7e1l8aVmh0rO1QpefhdPRrFF1M8+uJiEcZCH9/EUF2z0Xio8Hdlg58P1Rc5SWopC
	M6Ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc;
	bh=p9Lj9V2T4OyOPQgmJwywrr6koEfn0eGhpAFrj2RoaUs=;
	b=EYr0dGYKuo2qlFH7sWoch6mAeiXwqsQuRvMFvKIo8pydoEwnLQ3ZI8PnXH18lxVMJl
	5XWD2sjBmOmHuJfk2JkriIumCLUZTRU2ZrlYpR1yzS3GTp7NYULT94F/zl28slnNXD4S
	Nl5h9ejmreC+gdaLcfCWqOFDk7BpINguS15JzdlHAU1PPIAkRsUIVP/+qjMrV06psogL
	J7qtQg3XMJxs4JPqQVc6u5HoMuxVIqVdEotqEKbgJ6Eh2W9jQX6Y8H75gZ5NjhgNEMQM
	GEybaRyFnCEJ1cVzuPCqZSCX14fEGPV064PvB8X6x471yxJCCG5vF9/qciaDtymPMtML
	b5jg==
X-Gm-Message-State: AFeK/H0VNY371CPeKfjIBdWU1LenDG91gxp4tcRQWIRy320eQIcEIhnPDFW/xdv55TqeWMeZVJtnR/bCFprpMg==
X-Received: by 10.200.34.38 with SMTP id o35mr1549116qto.226.1490805699807;
	Wed, 29 Mar 2017 09:41:39 -0700 (PDT)
MIME-Version: 1.0
References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
	<CAB-xxiPV9oN1r2hV5a=U1pcYuiZ_qmth-AM-H+1Cjgc2uw-0xA@mail.gmail.com>
	<CAFVRnyr=cYf34X80+dLHwYEPHdqA7mMtYZ_gD6j09C+aM31gQQ@mail.gmail.com>
	<f61153c3-9afb-5cee-2c6b-70d67208f015@gmail.com>
	<CAFVRnyo1XGNbq_F8UfqqJWHCVH14iMCUMU-R5bOh+h3mtwSUJg@mail.gmail.com>
	<CAFVRnyqxQhu0c-ACfzR5=Z=C1SbR70jrfCaCeEdfSJASSnzpqw@mail.gmail.com>
	<CAAy62_J+huc_d5r-gyYCMGh6AjfJH4YiEVov9eBmwbKbWTe0Sw@mail.gmail.com>
	<CAFVRnyrpfRUVNWjR19+ou7PxQuLbaoY8yta+BAAK3zbMrdsOhw@mail.gmail.com>
In-Reply-To: <CAFVRnyrpfRUVNWjR19+ou7PxQuLbaoY8yta+BAAK3zbMrdsOhw@mail.gmail.com>
From: Andrew Johnson <andrew.johnson83@gmail.com>
Date: Wed, 29 Mar 2017 16:41:29 +0000
Message-ID: <CAAy62_+JtoAuM-RsrAAp5eiGiO+OHLDjzqgbnF2De7TUU7TyYg@mail.gmail.com>
To: David Vorick <david.vorick@gmail.com>
Content-Type: multipart/alternative; boundary=001a11403c682a916e054be14059
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE, RCVD_IN_DNSWL_LOW,
	RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 29 Mar 2017 16:45:31 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
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: Wed, 29 Mar 2017 16:41:41 -0000

--001a11403c682a916e054be14059
Content-Type: text/plain; charset=UTF-8

I believe that as we continue to add users to the system by scaling
capacity that we will see more new nodes appear, but I'm at a bit of a loss
as to how to empirically prove it.

I do see your point on increasing load on archival nodes, but the majority
of that load is going to come from new nodes coming online, they're the
only ones going after very old blocks.   I could see that as a potential
attack vector, overwhelm the archival nodes by spinning up new nodes
constantly, therefore making it difficult for a "real" new node to get up
to speed in a reasonable amount of time.

Perhaps the answer there would be a way to pay an archival node a small
amount of bitcoin in order to retrieve blocks older than a certain cutoff?
Include an IP address for the node asking for the data as metadata in the
transaction...  Archival nodes could set and publish their own policy, let
the market decide what those older blocks are worth.  Would also help to
incentivize running archival node, which we do need.  Of course, this isn't
very user friendly.

We can take this to bitcoin-discuss, if we're getting too far off topic.


On Wed, Mar 29, 2017 at 11:25 AM David Vorick <david.vorick@gmail.com>
wrote:

>
> On Mar 29, 2017 12:20 PM, "Andrew Johnson" <andrew.johnson83@gmail.com>
> wrote:
>
> What's stopping these users from running a pruned node?  Not every node
> needs to store a complete copy of the blockchain.
>
>
> Pruned nodes are not the default configuration, if it was the default
> configuration then I think you would see far more users running a pruned
> node.
>
> But that would also substantially increase the burden on archive nodes.
>
>
> Further discussion about disk space requirements should be taken to
> another thread.
>
>
> --
Andrew Johnson

--001a11403c682a916e054be14059
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>I believe that as we continue to add users to the system by scaling ca=
pacity that we will see more new nodes appear, but I&#39;m at a bit of a lo=
ss as to how to empirically prove it.=C2=A0</div><div><br></div><div>I do s=
ee your point on increasing load on archival nodes, but the majority of tha=
t load is going to come from new nodes coming online, they&#39;re the only =
ones going after very old blocks. =C2=A0 I could see that as a potential at=
tack vector, overwhelm the archival nodes by spinning up new nodes constant=
ly, therefore making it difficult for a &quot;real&quot; new node to get up=
 to speed in a reasonable amount of time.=C2=A0</div><div><br></div><div>Pe=
rhaps the answer there would be a way to pay an archival node a small amoun=
t of bitcoin in order to retrieve blocks older than a certain cutoff?=C2=A0=
 Include an IP address for the node asking for the data as metadata in the =
transaction...=C2=A0 Archival nodes could set and publish their own policy,=
 let the market decide what those older blocks are worth.=C2=A0 Would also =
help to incentivize running archival node, which we do need.=C2=A0 Of cours=
e, this isn&#39;t very user friendly.=C2=A0</div><div><br></div><div>We can=
 take this to bitcoin-discuss, if we&#39;re getting too far off topic.</div=
><div><br></div><div><br><div class=3D"gmail_quote"><div>On Wed, Mar 29, 20=
17 at 11:25 AM David Vorick &lt;<a href=3D"mailto:david.vorick@gmail.com">d=
avid.vorick@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div class=3D"gmail_msg"><div class=3D"gmail_msg"><div class=3D"gmail_msg=
"><br class=3D"gmail_msg"></div><div class=3D"gmail_extra gmail_msg"><div c=
lass=3D"gmail_quote gmail_msg">On Mar 29, 2017 12:20 PM, &quot;Andrew Johns=
on&quot; &lt;<a href=3D"mailto:andrew.johnson83@gmail.com" class=3D"gmail_m=
sg" target=3D"_blank">andrew.johnson83@gmail.com</a>&gt; wrote:<br type=3D"=
attribution" class=3D"gmail_msg"><blockquote class=3D"m_-804048863704614493=
3quote gmail_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div class=3D"gmail_msg">What&#39;s stopping these users fro=
m running a pruned node?=C2=A0 Not every node needs to store a complete cop=
y of the blockchain.=C2=A0</div></blockquote></div></div></div><div class=
=3D"gmail_msg"><br class=3D"gmail_msg"></div><div class=3D"gmail_msg"><div =
class=3D"gmail_extra gmail_msg"><div class=3D"gmail_quote gmail_msg"><block=
quote class=3D"m_-8040488637046144933quote gmail_msg" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_msg"=
></div></blockquote></div></div></div></div><div class=3D"gmail_msg"><div c=
lass=3D"gmail_msg"><span style=3D"font-family:sans-serif" class=3D"gmail_ms=
g">Pruned nodes are not the default configuration, if it was the default co=
nfiguration then I think you would see far more users running a pruned node=
.</span><div style=3D"font-family:sans-serif" class=3D"gmail_msg"><br class=
=3D"gmail_msg"></div><div style=3D"font-family:sans-serif" class=3D"gmail_m=
sg">But that would also substantially increase the burden on archive nodes.=
</div><br class=3D"gmail_msg"></div><div class=3D"gmail_msg"><br class=3D"g=
mail_msg"><span style=3D"font-family:sans-serif" class=3D"gmail_msg">Furthe=
r discussion about disk space requirements should be taken to another threa=
d.</span><br class=3D"gmail_msg"></div><div class=3D"gmail_msg"><div class=
=3D"gmail_extra gmail_msg"><div class=3D"gmail_quote gmail_msg"><blockquote=
 class=3D"m_-8040488637046144933quote gmail_msg" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div></blockquote></div></div></div></div>
</blockquote></div></div><div dir=3D"ltr">-- <br></div><div data-smartmail=
=3D"gmail_signature">Andrew Johnson<br><div><br></div></div>

--001a11403c682a916e054be14059--