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
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <kgreenek@gmail.com>) id 1Z4hai-0000aQ-ED
for bitcoin-development@lists.sourceforge.net;
Tue, 16 Jun 2015 03:31:12 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.50 as permitted sender)
client-ip=74.125.82.50; envelope-from=kgreenek@gmail.com;
helo=mail-wg0-f50.google.com;
Received: from mail-wg0-f50.google.com ([74.125.82.50])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z4hag-0004wQ-G1
for bitcoin-development@lists.sourceforge.net;
Tue, 16 Jun 2015 03:31:12 +0000
Received: by wgbhy7 with SMTP id hy7so2753888wgb.2
for <bitcoin-development@lists.sourceforge.net>;
Mon, 15 Jun 2015 20:31:04 -0700 (PDT)
X-Received: by 10.180.188.109 with SMTP id fz13mr1786985wic.74.1434425464469;
Mon, 15 Jun 2015 20:31:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.20.1 with HTTP; Mon, 15 Jun 2015 20:30:44 -0700 (PDT)
In-Reply-To: <CA+c4Zoy6U9RXH3Qw15sXXnaeYL-9PFbnTp=VLAJsvpC_zoAK_A@mail.gmail.com>
References: <CALqxMTHrnSS9MGgKO-5+=fVhiOOvk12Recs11S0PcSUxQT1wdQ@mail.gmail.com>
<CANEZrP1nx9rNf1q-nubP77U8RMABuLtmEB_P7UpY2zyFf-Ns-w@mail.gmail.com>
<CALqxMTENbj+E7ypJASrM1r04eW3kYe+afwy+Rt3i9ubeT-=2mA@mail.gmail.com>
<CANEZrP0Z_EOmVgbvVmYDvegm6jfd1cKB52acXHocjRuM-qGEog@mail.gmail.com>
<CAPg+sBgc0i-XsN=g0V4Y0bko-Xb1AT5x=UWDa+opL3eFbBmJfA@mail.gmail.com>
<CANEZrP0eGDTafK+ZUBNcQBOe2JU_PqZVXMt0Ds-b8Ley7kbGrA@mail.gmail.com>
<CAPg+sBiPhhrBh8f3QxJLtoysfywtVFSo2RH0WXVR+vpX9z6+HQ@mail.gmail.com>
<CANEZrP10gn+969d-oe-8Em9ipe4DOP9q0WkNtL6u-6V5aphkPQ@mail.gmail.com>
<CAFBxzAAExA-aE+8o-+HGQtnuwWuWpkt8Lbgxvh7hT64XkMKOPg@mail.gmail.com>
<COL131-DS5331AE0C03A2BF6E0553ECDB80@phx.gbl>
<CALqxMTF2T0Wgt15bmjkpMK199vhwH+ufYw+LJU7AEzx4X7dykQ@mail.gmail.com>
<COL131-DS1BD3015F98131D224B0D6CDB80@phx.gbl>
<CA+c4ZoyjmfFO+3+Zqvjabk1KuezuV42pvPNa57JPzJCAePJ5hw@mail.gmail.com>
<COL131-DS97146D8FC6E7EC7D3F5D9CDB80@phx.gbl>
<CA+c4Zoy6U9RXH3Qw15sXXnaeYL-9PFbnTp=VLAJsvpC_zoAK_A@mail.gmail.com>
From: Kevin Greene <kgreenek@gmail.com>
Date: Mon, 15 Jun 2015 20:30:44 -0700
Message-ID: <CAEY8wq41ftFA1ObyUWiRGOgebwqDCAw_j+hU6_wfcXv5GSZaJw@mail.gmail.com>
To: "sickpig@gmail.com" <sickpig@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c25f68443d4605189a34ac
X-Spam-Score: 0.4 (/)
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
(kgreenek[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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
1.0 FREEMAIL_REPLY From and body contain different freemails
X-Headers-End: 1Z4hag-0004wQ-G1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] The Bitcoin Node Market
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, 16 Jun 2015 03:31:12 -0000
--001a11c25f68443d4605189a34ac
Content-Type: text/plain; charset=UTF-8
Would SPV wallets have to pay to connect to the network too? From the
user's perspective, it would be somewhat upsetting (and confusing) to see
your balance slowly draining every time you open your wallet app. It would
also tie up outputs every time you open up your wallet. You may go to pay
for something in a coffee shop, only to find that you can't spend your
bitcoin because the wallet had to create a transaction to pay to sync with
the network.
Also, users of centralized wallet services like Coinbase would not have to
pay that fee; but users of native wallets like breadwallet would have no
such option. This incentivizes users to use centralized wallets.
So this is kind of imposing a worse user experience on users who want to
use bitcoin the "right" way. That doesn't seem like a good thing to me :/
On Mon, Jun 15, 2015 at 1:12 PM, sickpig@gmail.com <sickpig@gmail.com>
wrote:
> Hi Raystonn
>
> On Mon, Jun 15, 2015 at 9:36 PM, Raystonn . <raystonn@hotmail.com> wrote:
> >
> > I am only partially through the content at the below link, and I am very
> impressed. Has Justus Ranvier began work on implementation of the ideas
> contained therein?
>
> I don't know if he or someone else has begun writing code to implement
> what was described in the liked post, but I'm sure he will reply to
> you since he's subscribed to this mailing list.
>
>
> >
> >
> >
> > From: sickpig@gmail.com
> > Sent: Monday, June 15, 2015 12:18 PM
> > To: Raystonn .
> > Cc: Bitcoin Dev
> > Subject: Re: [Bitcoin-development] The Bitcoin Node Market
> >
> >
> > Sorry for top posting and the brevity but I'm typing from my phone
> >
> > You shoud be interested in this post by Justus Ranvier then:
> >
> >
> https://bitcoinism.liberty.me/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/
> >
> > On Jun 15, 2015 8:57 PM, "Raystonn ." <raystonn@hotmail.com> wrote:
> >>
> >> I have been toying with an idea and figured I'd run it by everyone here
> >> before investing further time in it. The goal here is to make it
> >> sustainable, and perhaps profitable, to run full nodes on the Bitcoin
> >> Network in the long term.
> >>
> >> - Nodes can participate in a market wherein they are paid by nodes,
> wallets,
> >> and other services to supply Bitcoin Network data. Payment should be
> based
> >> on the cost imposed on the Node to do the work and send the data, but
> can be
> >> set in any way the node operator desires. It's a free market.
> >> - Nodes that are mostly leeching data from the Bitcoin Network, such as
> >> those that do not receive inbound connections to port 8333, will send
> >> payments to the nodes they connect to, but will likely receive no
> payments
> >> from other nodes, wallets, and other services.
> >> - Nodes that are providing balanced full service to the Bitcoin Network
> will
> >> tend to have a balance of payments coming in and going out with regards
> to
> >> other balanced full service nodes, leaving them revenue neutral there.
> But
> >> they will receive payments from leech nodes, wallets, and other
> services.
> >>
> >> The net effect here is that the cost to run nodes will be shared by
> those
> >> who are using the Bitcoin network but not contributing by running a full
> >> node. A market will develop for fees to connect to the Bitcoin Network
> >> which should help cover the cost of running the Network. It's still
> >> possible to continue offering access to your node for free as there is
> >> nothing forcing you to charge a fee. But this isn't very sustainable
> >> long-run. Market efficiencies should eventually mean nodes take in only
> >> what is required to keep the Network operational.
> >>
> >> Raystonn
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--001a11c25f68443d4605189a34ac
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"color:#336666">Would=
SPV wallets have to pay to connect to the network too? From the user's=
perspective, it would be somewhat upsetting (and confusing) to see your ba=
lance slowly draining every time you open your wallet app. It would also ti=
e up outputs every time you open up your wallet. You may go to pay for some=
thing in a coffee shop, only to find that you can't spend your bitcoin =
because the wallet had to create a transaction to pay to sync with the netw=
ork.</div><div class=3D"gmail_default" style=3D"color:#336666"><br></div><d=
iv class=3D"gmail_default" style=3D"color:#336666">Also, users of centraliz=
ed wallet services like Coinbase would not have to pay that fee; but users =
of native wallets like breadwallet would have no such option. This incentiv=
izes users to use centralized wallets.</div><div class=3D"gmail_default" st=
yle=3D"color:#336666"><br></div><div class=3D"gmail_default" style=3D"color=
:#336666">So this is kind of imposing a worse user experience on users who =
want to use bitcoin the "right" way. That doesn't seem like a=
good thing to me :/</div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Mon, Jun 15, 2015 at 1:12 PM, <a href=3D"mailto:sickpig=
@gmail.com">sickpig@gmail.com</a> <span dir=3D"ltr"><<a href=3D"mailto:s=
ickpig@gmail.com" target=3D"_blank">sickpig@gmail.com</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">Hi Raystonn<br>
<span class=3D""><br>
On Mon, Jun 15, 2015 at 9:36 PM, Raystonn . <<a href=3D"mailto:raystonn@=
hotmail.com">raystonn@hotmail.com</a>> wrote:<br>
><br>
> I am only partially through the content at the below link, and I am ve=
ry impressed.=C2=A0 Has Justus Ranvier began work on implementation of the =
ideas contained therein?<br>
<br>
</span>I don't know if he or someone else has begun writing code to imp=
lement<br>
what was described in the liked post, but I'm sure he will reply to<br>
you since he's subscribed to this mailing list.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
><br>
><br>
><br>
> From: <a href=3D"mailto:sickpig@gmail.com">sickpig@gmail.com</a><br>
> Sent: Monday, June 15, 2015 12:18 PM<br>
> To: Raystonn .<br>
> Cc: Bitcoin Dev<br>
> Subject: Re: [Bitcoin-development] The Bitcoin Node Market<br>
><br>
><br>
> Sorry for top posting and the brevity but I'm typing from my phone=
<br>
><br>
> You shoud be interested in this post by Justus Ranvier then:<br>
><br>
> <a href=3D"https://bitcoinism.liberty.me/economic-fallacies-and-the-bl=
ock-size-limit-part-2-price-discovery/" rel=3D"noreferrer" target=3D"_blank=
">https://bitcoinism.liberty.me/economic-fallacies-and-the-block-size-limit=
-part-2-price-discovery/</a><br>
><br>
> On Jun 15, 2015 8:57 PM, "Raystonn ." <<a href=3D"mailto:=
raystonn@hotmail.com">raystonn@hotmail.com</a>> wrote:<br>
>><br>
>> I have been toying with an idea and figured I'd run it by ever=
yone here<br>
>> before investing further time in it.=C2=A0 The goal here is to mak=
e it<br>
>> sustainable, and perhaps profitable, to run full nodes on the Bitc=
oin<br>
>> Network in the long term.<br>
>><br>
>> - Nodes can participate in a market wherein they are paid by nodes=
, wallets,<br>
>> and other services to supply Bitcoin Network data.=C2=A0 Payment s=
hould be based<br>
>> on the cost imposed on the Node to do the work and send the data, =
but can be<br>
>> set in any way the node operator desires.=C2=A0 It's a free ma=
rket.<br>
>> - Nodes that are mostly leeching data from the Bitcoin Network, su=
ch as<br>
>> those that do not receive inbound connections to port 8333, will s=
end<br>
>> payments to the nodes they connect to, but will likely receive no =
payments<br>
>> from other nodes, wallets, and other services.<br>
>> - Nodes that are providing balanced full service to the Bitcoin Ne=
twork will<br>
>> tend to have a balance of payments coming in and going out with re=
gards to<br>
>> other balanced full service nodes, leaving them revenue neutral th=
ere.=C2=A0 But<br>
>> they will receive payments from leech nodes, wallets, and other se=
rvices.<br>
>><br>
>> The net effect here is that the cost to run nodes will be shared b=
y those<br>
>> who are using the Bitcoin network but not contributing by running =
a full<br>
>> node.=C2=A0 A market will develop for fees to connect to the Bitco=
in Network<br>
>> which should help cover the cost of running the Network.=C2=A0 It&=
#39;s still<br>
>> possible to continue offering access to your node for free as ther=
e is<br>
>> nothing forcing you to charge a fee.=C2=A0 But this isn't very=
sustainable<br>
>> long-run.=C2=A0 Market efficiencies should eventually mean nodes t=
ake in only<br>
>> what is required to keep the Network operational.<br>
>><br>
>> Raystonn<br>
>><br>
>><br>
>> ------------------------------------------------------------------=
------------<br>
>> _______________________________________________<br>
>> Bitcoin-development mailing list<br>
>> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitco=
in-development@lists.sourceforge.net</a><br>
>> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.n=
et/lists/listinfo/bitcoin-development</a><br>
<br>
---------------------------------------------------------------------------=
---<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=
" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/=
listinfo/bitcoin-development</a><br>
</div></div></blockquote></div><br></div>
--001a11c25f68443d4605189a34ac--
|