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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YWY03-0000s8-UB
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Mar 2015 22:24:11 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.174 as permitted sender)
client-ip=209.85.223.174; envelope-from=mh.in.england@gmail.com;
helo=mail-ie0-f174.google.com;
Received: from mail-ie0-f174.google.com ([209.85.223.174])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YWY02-0001I5-P4
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Mar 2015 22:24:11 +0000
Received: by iegc3 with SMTP id c3so133156042ieg.3
for <bitcoin-development@lists.sourceforge.net>;
Fri, 13 Mar 2015 15:24:05 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.79.230 with SMTP id m6mr87478704igx.33.1426285445499;
Fri, 13 Mar 2015 15:24:05 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.36.54.147 with HTTP; Fri, 13 Mar 2015 15:24:05 -0700 (PDT)
In-Reply-To: <550361CC.7080401@localhost.local>
References: <55034205.4030607@localhost.local>
<CANEZrP2OM6BrEsgqe5j23qaZp7wypOFJOZf+cNuMMe12WBv8LA@mail.gmail.com>
<55035EAC.80201@localhost.local>
<CANEZrP0c04KrpjNTsANPhrK_NchQ+aP=yOtRV+5GMBsKWKREkQ@mail.gmail.com>
<550361CC.7080401@localhost.local>
Date: Fri, 13 Mar 2015 15:24:05 -0700
X-Google-Sender-Auth: IZ8MK8Ee00IjimYhxSwwWiQKHis
Message-ID: <CANEZrP1UyyL9=UnCeeq27h4W2GiSRtVeJ63s_FT66tOE2rXY+Q@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Justus Ranvier <justusranvier@riseup.net>
Content-Type: multipart/alternative; boundary=089e01229aaa53f4a6051132f56f
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: 1YWY02-0001I5-P4
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Criminal complaints against "network
disruption as a service" startups
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: Fri, 13 Mar 2015 22:24:12 -0000
--089e01229aaa53f4a6051132f56f
Content-Type: text/plain; charset=UTF-8
>
> Don't SPV clients announce their intentions by the act of uploading a
> filter?
>
Well they don't set NODE_NETWORK, so they don't claim to be providing
network services. But then I guess the Chainalysis nodes could easily just
clear that bit flag too.
> What I'd actually like to see is for network users to pay for the node
> resources that they consume
It's not quite pay-as-you-go, but I just posted a scheme for funding of
network resources using crowdfunding contracts here:
https://github.com/bitcoin/bitcoin/issues/5783#issuecomment-79460064
That comment doesn't have any kind of provision for access control, but
group signatures could be extended in both directions: the server proves it
was a part of the group that was funded by the contract, and the client
proves it was in group that funded the contract, but it's done in a
(relatively) anonymous way. Then any client can use any node it funded, or
at least, buy priority access.
But it's rather complicated. I'd hope that nodes can be like email
accounts: yes they have a cost but in practice people everyone gets one for
free because of random commercial cross-subsidisation, self hosting and
other things.
--089e01229aaa53f4a6051132f56f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">Don't SPV clients announce their intentions by the act of =
uploading a<br>
filter?<br></blockquote><div><br></div><div>Well they don't set NODE_NE=
TWORK, so they don't claim to be providing network services. But then I=
guess the Chainalysis nodes could easily just clear that bit flag too.=C2=
=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex">What I'd actually like to se=
e is for network users to pay for the node<br>
resources that they consume</blockquote><div><br></div><div>It's not qu=
ite pay-as-you-go, but I just posted a scheme for funding of network resour=
ces using crowdfunding contracts here:</div><div><br></div><div><a href=3D"=
https://github.com/bitcoin/bitcoin/issues/5783#issuecomment-79460064">https=
://github.com/bitcoin/bitcoin/issues/5783#issuecomment-79460064</a></div><d=
iv><br></div><div>That comment doesn't have any kind of provision for a=
ccess control, but group signatures could be extended in both directions: t=
he server proves it was a part of the group that was funded by the contract=
, and the client proves it was in group that funded the contract, but it=
9;s done in a (relatively) anonymous way. Then any client can use any node =
it funded, or at least, buy priority access.</div><div><br></div><div>But i=
t's rather complicated. I'd hope that nodes can be like email accou=
nts: yes they have a cost but in practice people everyone gets one for free=
because of random commercial cross-subsidisation, self hosting and other t=
hings.</div></div></div></div>
--089e01229aaa53f4a6051132f56f--
|
