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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jan.moller@gmail.com>) id 1YXQde-0007aP-Da
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Mar 2015 08:44:42 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.169 as permitted sender)
client-ip=209.85.216.169; envelope-from=jan.moller@gmail.com;
helo=mail-qc0-f169.google.com;
Received: from mail-qc0-f169.google.com ([209.85.216.169])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YXQdb-0000MX-3I
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Mar 2015 08:44:42 +0000
Received: by qcaz10 with SMTP id z10so37479331qca.1
for <bitcoin-development@lists.sourceforge.net>;
Mon, 16 Mar 2015 01:44:33 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.238.87 with SMTP id j84mr76678356qhc.78.1426495473649;
Mon, 16 Mar 2015 01:44:33 -0700 (PDT)
Received: by 10.140.25.215 with HTTP; Mon, 16 Mar 2015 01:44:33 -0700 (PDT)
In-Reply-To: <CANEZrP2OM6BrEsgqe5j23qaZp7wypOFJOZf+cNuMMe12WBv8LA@mail.gmail.com>
References: <55034205.4030607@localhost.local>
<CANEZrP2OM6BrEsgqe5j23qaZp7wypOFJOZf+cNuMMe12WBv8LA@mail.gmail.com>
Date: Mon, 16 Mar 2015 09:44:33 +0100
Message-ID: <CABh=4qNwRqb3f+AM-PKB0F+Kaw02tAq2DsqLmeO87XxXZvTd4Q@mail.gmail.com>
From: =?UTF-8?Q?Jan_M=C3=B8ller?= <jan.moller@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a1135c8b8fb0cbb051163db75
X-Spam-Score: -0.6 (/)
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
(jan.moller[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
X-Headers-End: 1YXQdb-0000MX-3I
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Justus Ranvier <justusranvier@riseup.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
Reply-To: jan.moller@gmail.com
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 Mar 2015 08:44:42 -0000
--001a1135c8b8fb0cbb051163db75
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
What we were trying to achieve was determining the flow of funds between
countries by figuring out which country a transaction originates from.
To do that with a certain accuracy you need many nodes. We chose a class C
IP range as we knew that bitcoin core and others only connect to one node
in any class C IP range. We were not aware that breadwallet didn't follow
this practice. Breadwallet risked getting tar-pitted, but that was not our
intention and we are sorry about that.
Our nodes DID respond with valid blocks and merkle-blocks and allowed
everyone connecting to track the blockchain. We did however not relay
transactions. The 'service' bit in the version message is not meant for
telling whether or how the node relays transactions, it tells whether you
can ask for block headers only or full blocks.
Many implementations enforce non standard rules for handling transactions;
some nodes ignore transactions with address reuse, some nodes happily
forward double spends, and some nodes forward neither blocks not
transactions. We did blocks but not transactions.
In hindsight we should have done two things:
1. relay transactions
2. advertise address from 'foreign' nodes
Both would have fixed the problems that breadwallet experienced. My
understanding is that breadwallet now has the same 'class C' rule as
bitcoind, which would also fix it.
Getting back on the topic of this thread and whether it is illegal, your
guess is as good as mine. I don't think it is illegal to log incoming
connections and make statistical analysis on it. That would more or less
incriminate anyone who runs a web-server and looks into the access log.
At lease one Bitcoin service has been collecting IP addresses for years and
given them to anyone visiting their web-site (you know who) and I believe
that this practise is very wrong. We have no intention of giving IP
addresses away to anyone, but we believe that you are free to make
statistics on connection logs when nodes connect to you.
On a side note: When you make many connections to the network you see lots
of strange nodes and suspicious patterns. You can be certain that we were
not the only ones connected to many nodes.
My takeaway from this: If nodes that do not relay transactions is a problem
then there is stuff to fix.
/Jan
On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn <mike@plan99.net> wrote:
> That would be rather new and tricky legal territory.
>
> But even putting the legal issues to one side, there are definitional
> issues.
>
> For instance if the Chainalysis nodes started following the protocol spec=
s
> better and became just regular nodes that happen to keep logs, would that
> still be a violation? If so, what about blockchain.info? It'd be shooting
> ourselves in the foot to try and forbid block explorers given how useful
> they are.
>
> If someone non-maliciously runs some nodes with debug logging turned on,
> and makes full system backups every night, and keeps those backups for
> years, are they in violation of whatever pseudo-law is involved?
>
> I think it's a bit early to think about these things right now. Michael
> Gr=C3=B8nager and Jan M=C3=B8ller have been Bitcoin hackers for a long ti=
me. I'd be
> interested to know their thoughts on all of this.
>
>
> -------------------------------------------------------------------------=
-----
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub fo=
r
> all
> things parallel software development, from weekly thought leadership blog=
s
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--001a1135c8b8fb0cbb051163db75
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">What we were trying to achieve was determining the flow of=
funds between countries by figuring out which country a transaction origin=
ates from.=C2=A0<div>To do that with a certain accuracy you need many nodes=
. We chose a class C IP range as we knew that bitcoin core and others only =
connect to one node in any class C IP range. We were not aware that breadwa=
llet didn't follow this practice. Breadwallet risked getting tar-pitted=
, but that was not our intention and we are sorry about that.<div><br></div=
><div>Our nodes DID respond with valid blocks and merkle-blocks and allowed=
everyone connecting to track the blockchain. We did however not relay tran=
sactions. The 'service' bit in the version message is not meant for=
telling whether or how the node relays transactions, it tells whether you =
can ask for block headers only or full blocks.</div><div><br></div><div>Man=
y implementations enforce non standard rules for handling transactions; som=
e nodes ignore transactions with address reuse, some nodes happily forward =
double spends, and some nodes forward neither blocks not transactions. We d=
id blocks but not transactions.</div><div><br></div><div>In hindsight we sh=
ould have done two things:</div><div>1. relay transactions</div><div>2. adv=
ertise address from 'foreign' nodes</div><div><br></div><div>Both w=
ould have fixed the problems that breadwallet experienced. My understanding=
is that breadwallet now has the same 'class C' rule as bitcoind, w=
hich would also fix it.</div><div><br></div><div>Getting back on the topic =
of this thread and whether it is illegal, your guess is as good as mine. I =
don't think it is illegal to log incoming connections and make statisti=
cal analysis on it. That would more or less incriminate anyone who runs a w=
eb-server and looks into the access log.</div><div>At lease one Bitcoin ser=
vice has been collecting IP addresses for years and given them to anyone vi=
siting their web-site (you know who) and I believe that this practise is ve=
ry wrong. We have no intention of giving IP addresses away to anyone, but w=
e believe that you are free to make statistics on connection logs when node=
s connect to you.<br></div><div><br></div><div>On a side note: When you mak=
e many connections to the network you see lots of strange nodes and suspici=
ous patterns. You can be certain that we were not the only ones connected t=
o many nodes.<br></div><div><br></div><div>My takeaway from this: If nodes =
that do not relay transactions is a problem then there is stuff to fix.</di=
v><div><br></div><div>/Jan</div></div></div><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn <sp=
an dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mik=
e@plan99.net</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div class=3D"gmail_extra">That would be rather new and tricky l=
egal territory.=C2=A0</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">But even putting the legal issues to one side, there are d=
efinitional issues.</div><div class=3D"gmail_extra"><br></div><div class=3D=
"gmail_extra">For instance if the Chainalysis nodes started following the p=
rotocol specs better and became just regular nodes that happen to keep logs=
, would that still be a violation? If so, what about <a href=3D"http://bloc=
kchain.info" target=3D"_blank">blockchain.info</a>? It'd be shooting ou=
rselves in the foot to try and forbid block explorers given how useful they=
are.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=
If someone non-maliciously runs some nodes with debug logging turned on, an=
d makes full system backups every night, and keeps those backups for years,=
are they in violation of whatever pseudo-law is involved?</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I think it's a bi=
t early to think about these things right now. Michael Gr=C3=B8nager and Ja=
n M=C3=B8ller have been Bitcoin hackers for a long time. I'd be interes=
ted to know their thoughts on all of this.</div></div>
<br>-----------------------------------------------------------------------=
-------<br>
Dive into the World of Parallel Programming The Go Parallel Website, sponso=
red<br>
by Intel and developed in partnership with Slashdot Media, is your hub for =
all<br>
things parallel software development, from weekly thought leadership blogs =
to<br>
news, videos, case studies, tutorials and more. Take a look and join the<br=
>
conversation now. <a href=3D"http://goparallel.sourceforge.net/" target=3D"=
_blank">http://goparallel.sourceforge.net/</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>
<br></blockquote></div><br></div>
--001a1135c8b8fb0cbb051163db75--
|
