summaryrefslogtreecommitdiff
path: root/e9/8656ebe54aa348c44f3eed1d711a0a94a31d7e
blob: c6cd2c777c2c4991811866acc567452b25107a6d (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
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1WwVCT-0006AU-3C
	for Bitcoin-development@lists.sourceforge.net;
	Mon, 16 Jun 2014 11:35:45 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.41 as permitted sender)
	client-ip=209.85.219.41; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f41.google.com; 
Received: from mail-oa0-f41.google.com ([209.85.219.41])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WwVCR-0000AU-7j
	for Bitcoin-development@lists.sourceforge.net;
	Mon, 16 Jun 2014 11:35:45 +0000
Received: by mail-oa0-f41.google.com with SMTP id l6so5674497oag.14
	for <Bitcoin-development@lists.sourceforge.net>;
	Mon, 16 Jun 2014 04:35:33 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.115.199 with SMTP id jq7mr1676101obb.70.1402918533131;
	Mon, 16 Jun 2014 04:35:33 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.162 with HTTP; Mon, 16 Jun 2014 04:35:33 -0700 (PDT)
In-Reply-To: <87aaf81b20e17332175a3fbcd091c317.squirrel@fulvetta.riseup.net>
References: <87aaf81b20e17332175a3fbcd091c317.squirrel@fulvetta.riseup.net>
Date: Mon, 16 Jun 2014 13:35:33 +0200
X-Google-Sender-Auth: is1AYvajKoqmZ4y3nET4Wmmvy5o
Message-ID: <CANEZrP0zsV1FZ4=+OUv7pJ09c3rbw_uuWRh+00E4EkfbXTjMxw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Odinn Cyberguerrilla <odinn.cyberguerrilla@riseup.net>
Content-Type: multipart/alternative; boundary=047d7b678120d0f7a004fbf26ceb
X-Spam-Score: -0.5 (/)
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
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1WwVCR-0000AU-7j
Cc: Bitcoin Dev <Bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Incentivizing the running of full 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: Mon, 16 Jun 2014 11:35:45 -0000

--047d7b678120d0f7a004fbf26ceb
Content-Type: text/plain; charset=UTF-8

Hi Odinn,

I think trying to incentivise nodes with money is tricky: it makes
intuitive sense but right now the market is flooded with supply relative to
demand. Yes, we worry about the falling number of nodes, but that's for
reasons that aren't really economic: the more nodes we have, the bigger and
more grassroots the project seems to the outside world, plus the cheaper it
gets for everyone as the biggest cost (chain upload bandwidth) is spread
over multiple people.

Also there's research showing that when you have people volunteering,
introducing money can ruin the motivation of the volunteers, so the
transition to a pay-for-node-services world could be quite painful and
difficult.

Right now rather than microdonations to all nodes, IMO the lowest hanging
fruit is to move chain upload onto specialised "archival nodes" which can
potentially charge for their services. I prototyped this here

https://github.com/mikehearn/PayFile

but never finished it.


On Mon, Jun 16, 2014 at 10:12 AM, Odinn Cyberguerrilla <
odinn.cyberguerrilla@riseup.net> wrote:

> I have been noticing for some time the problem which Mike H. identified as
> how we are bleeding nodes ~ losing nodes over time.
>
> This link was referenced in the coindesk article of May 9, 2014:
>
>
> http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/CANEZrP2rgiQHpekEpFviJ22QsiV%2Bs-F2pqosaZOA5WrRtJx5pg%40mail.gmail.com/#msg32196023
>
> (coindesk article for reference:
> http://www.coindesk.com/bitcoin-nodes-need/)
>
> The proposed solution is noted here as a portion of an issue at:
>  https://github.com/bitcoin/bitcoin/issues/4079
>
> Essentially that part which has to do with helping reduce
> the loss of nodes is as follows:
>
> "a feature similar to that suggested by @gmaxwell that would process small
> change and tiny txouts to user specified donation targets, in an
> incentivized process. Those running full nodes (Bitcoin Core all the
> time), processing their change and txouts through Core, would be provided
> incentives in the form of a 'decentralizing lottery' such that all
> participants who are running nodes and donating no matter how infrequently
> (and no matter who they donate to) will be entered in the 'decentralizing
> lottery,' the 'award amounts' (which would be distinct from 'block
> rewards' for any mining) would vary from small to large bitcoin amounts
> depending on how many participants are involved in the donations process.
> This would help incentivize individuals to run full nodes as well as
> encouraging giving and microdonations. The option could be expressed in
> the transactions area to contribute to help bitcoin core development for
> those that are setting up change and txouts for donations, regarding the
> microdonation portion (which has also has been expressed conceptually at
> abis.io"
>
> This addresses the issue of how to incentivize more
> interested individuals to run full nodes (Bitcoin Core).  The lottery
> concept (which would be applicable to anyone running the full node
> regardless of whether or not they are mining) is attractive from the point
> of view that it will complement the block reward concept already in place
> which serves those who mine, but more attractive to the individual who
> doesn't feel the urge to mine, but would like to have the chance of being
> compensated for the effort they put into the system.
>
> I hope that this leads to additional development discussion on these
> concepts regarding incentivizing giving. This may also involve a process
> BIP.  I look forward to your remarks.
>
> Respect,
>
> Odinn
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

<div dir=3D"ltr">Hi Odinn,<div><br></div><div><span style=3D"font-family:ar=
ial,sans-serif;font-size:13px">I think trying to incentivise nodes with mon=
ey is tricky: it makes intuitive sense but right now the market is flooded =
with supply relative to demand. Yes, we worry about the falling number of n=
odes, but that&#39;s for reasons that aren&#39;t really economic: the more =
nodes we have, the bigger and more grassroots the project seems to the outs=
ide world, plus the cheaper it gets for everyone as the biggest cost (chain=
 upload bandwidth) is spread over multiple people.</span><br>
</div><div><div style=3D"font-family:arial,sans-serif;font-size:13px"><br><=
/div><div style=3D"font-family:arial,sans-serif;font-size:13px">Also there&=
#39;s research showing that when you have people volunteering, introducing =
money can ruin the motivation of the volunteers, so the transition to a pay=
-for-node-services world could be quite painful and difficult.</div>
<div style=3D"font-family:arial,sans-serif;font-size:13px"><br></div><div s=
tyle=3D"font-family:arial,sans-serif;font-size:13px">Right now rather than =
microdonations to all nodes, IMO the lowest hanging fruit is to move chain =
upload onto specialised &quot;archival nodes&quot; which can potentially ch=
arge for their services. I prototyped this here</div>
<div style=3D"font-family:arial,sans-serif;font-size:13px"><br></div><div s=
tyle=3D"font-family:arial,sans-serif;font-size:13px"><a href=3D"https://git=
hub.com/mikehearn/PayFile" target=3D"_blank">https://github.com/mikehearn/P=
ayFile</a><br>
</div><div style=3D"font-family:arial,sans-serif;font-size:13px"><br></div>=
<div style=3D"font-family:arial,sans-serif;font-size:13px">but never finish=
ed it.</div></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gm=
ail_quote">
On Mon, Jun 16, 2014 at 10:12 AM, Odinn Cyberguerrilla <span dir=3D"ltr">&l=
t;<a href=3D"mailto:odinn.cyberguerrilla@riseup.net" target=3D"_blank">odin=
n.cyberguerrilla@riseup.net</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
I have been noticing for some time the problem which Mike H. identified as<=
br>
how we are bleeding nodes ~ losing nodes over time.<br>
<br>
This link was referenced in the coindesk article of May 9, 2014:<br>
<br>
<a href=3D"http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thr=
ead/CANEZrP2rgiQHpekEpFviJ22QsiV%2Bs-F2pqosaZOA5WrRtJx5pg%40mail.gmail.com/=
#msg32196023" target=3D"_blank">http://sourceforge.net/p/bitcoin/mailman/bi=
tcoin-development/thread/CANEZrP2rgiQHpekEpFviJ22QsiV%2Bs-F2pqosaZOA5WrRtJx=
5pg%40mail.gmail.com/#msg32196023</a><br>

<br>
(coindesk article for reference: <a href=3D"http://www.coindesk.com/bitcoin=
-nodes-need/" target=3D"_blank">http://www.coindesk.com/bitcoin-nodes-need/=
</a>)<br>
<br>
The proposed solution is noted here as a portion of an issue at:<br>
=C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/issues/4079" target=3D"=
_blank">https://github.com/bitcoin/bitcoin/issues/4079</a><br>
<br>
Essentially that part which has to do with helping reduce<br>
the loss of nodes is as follows:<br>
<br>
&quot;a feature similar to that suggested by @gmaxwell that would process s=
mall<br>
change and tiny txouts to user specified donation targets, in an<br>
incentivized process. Those running full nodes (Bitcoin Core all the<br>
time), processing their change and txouts through Core, would be provided<b=
r>
incentives in the form of a &#39;decentralizing lottery&#39; such that all<=
br>
participants who are running nodes and donating no matter how infrequently<=
br>
(and no matter who they donate to) will be entered in the &#39;decentralizi=
ng<br>
lottery,&#39; the &#39;award amounts&#39; (which would be distinct from &#3=
9;block<br>
rewards&#39; for any mining) would vary from small to large bitcoin amounts=
<br>
depending on how many participants are involved in the donations process.<b=
r>
This would help incentivize individuals to run full nodes as well as<br>
encouraging giving and microdonations. The option could be expressed in<br>
the transactions area to contribute to help bitcoin core development for<br=
>
those that are setting up change and txouts for donations, regarding the<br=
>
microdonation portion (which has also has been expressed conceptually at<br=
>
<a href=3D"http://abis.io" target=3D"_blank">abis.io</a>&quot;<br>
<br>
This addresses the issue of how to incentivize more<br>
interested individuals to run full nodes (Bitcoin Core). =C2=A0The lottery<=
br>
concept (which would be applicable to anyone running the full node<br>
regardless of whether or not they are mining) is attractive from the point<=
br>
of view that it will complement the block reward concept already in place<b=
r>
which serves those who mine, but more attractive to the individual who<br>
doesn&#39;t feel the urge to mine, but would like to have the chance of bei=
ng<br>
compensated for the effort they put into the system.<br>
<br>
I hope that this leads to additional development discussion on these<br>
concepts regarding incentivizing giving. This may also involve a process<br=
>
BIP. =C2=A0I look forward to your remarks.<br>
<br>
Respect,<br>
<br>
Odinn<br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions<b=
r>
Find What Matters Most in Your Big Data with HPCC Systems<br>
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.<br>
Leverages Graph Analysis for Fast Processing &amp; Easy Data Exploration<br=
>
<a href=3D"http://p.sf.net/sfu/hpccsystems" target=3D"_blank">http://p.sf.n=
et/sfu/hpccsystems</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@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>
</blockquote></div><br></div>

--047d7b678120d0f7a004fbf26ceb--