path: root/54/416a41274ea2f76bf705d9d00d01c0145c47b8

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 <voisine@gmail.com>) id 1YXalH-0001Vn-13
	for bitcoin-development@lists.sourceforge.net;
	Mon, 16 Mar 2015 19:33:15 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.179 as permitted sender)
	client-ip=209.85.212.179; envelope-from=voisine@gmail.com;
	helo=mail-wi0-f179.google.com; 
Received: from mail-wi0-f179.google.com ([209.85.212.179])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YXalF-00057y-2i
	for bitcoin-development@lists.sourceforge.net;
	Mon, 16 Mar 2015 19:33:14 +0000
Received: by wixw10 with SMTP id w10so35474699wix.0
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 16 Mar 2015 12:33:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.93.5 with SMTP id cq5mr15301084wib.18.1426534387027;
	Mon, 16 Mar 2015 12:33:07 -0700 (PDT)
Received: by 10.27.76.193 with HTTP; Mon, 16 Mar 2015 12:33:06 -0700 (PDT)
In-Reply-To: <CABh=4qNwRqb3f+AM-PKB0F+Kaw02tAq2DsqLmeO87XxXZvTd4Q@mail.gmail.com>
References: <55034205.4030607@localhost.local>
	<CANEZrP2OM6BrEsgqe5j23qaZp7wypOFJOZf+cNuMMe12WBv8LA@mail.gmail.com>
	<CABh=4qNwRqb3f+AM-PKB0F+Kaw02tAq2DsqLmeO87XxXZvTd4Q@mail.gmail.com>
Date: Mon, 16 Mar 2015 12:33:06 -0700
Message-ID: <CACq0ZD6LmGR+KCbWTBbbe0FDh5c8QvHkd1KqW2g0XWVh-a0pOw@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: jan.moller@gmail.com
Content-Type: multipart/alternative; boundary=f46d043c806a66164b05116cebc7
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
	(voisine[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: 1YXalF-00057y-2i
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
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 19:33:15 -0000

--f46d043c806a66164b05116cebc7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks Jan, we added several additional checks for non-standard protocol
responses, and also made the client revert to DNS seeding more quickly if
it runs into trouble, so it's now more robust against sybil/DOS attack. I
mentioned in the coindesk article that I didn't think what your nodes were
doing was intended to be malicious with respect to network disruption. It's
our job to better handle non-standard or even malicious behavior from
random p2p nodes.


Aaron Voisine
co-founder and CEO
breadwallet.com

On Mon, Mar 16, 2015 at 1:44 AM, Jan M=C3=B8ller <jan.moller@gmail.com> wro=
te:

> 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 ou=
r
> 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 lot=
s
> 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
>> specs better and became just regular nodes that happen to keep logs, wou=
ld
>> 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 h=
ow
>> 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 t=
ime. 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
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs 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
>>
>>
>
>
> -------------------------------------------------------------------------=
-----
> 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
>
>

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

<div dir=3D"ltr">Thanks Jan, we added several additional checks for non-sta=
ndard protocol responses, and also made the client revert to DNS seeding mo=
re quickly if it runs into trouble, so it&#39;s now more robust against syb=
il/DOS attack. I mentioned in the coindesk article that I didn&#39;t think =
what your nodes were doing was intended to be malicious with respect to net=
work disruption. It&#39;s our job to better handle non-standard or even mal=
icious behavior from random p2p nodes.</div><div class=3D"gmail_extra"><br =
clear=3D"all"><div><div class=3D"gmail_signature"><div dir=3D"ltr"><div><di=
v dir=3D"ltr"><div><br>Aaron Voisine</div><div>co-founder and CEO<br><a hre=
f=3D"http://breadwallet.com" target=3D"_blank">breadwallet.com</a></div></d=
iv></div></div></div></div>
<br><div class=3D"gmail_quote">On Mon, Mar 16, 2015 at 1:44 AM, Jan M=C3=B8=
ller <span dir=3D"ltr">&lt;<a href=3D"mailto:jan.moller@gmail.com" target=
=3D"_blank">jan.moller@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">What we were trying to achieve was determini=
ng the flow of funds between countries by figuring out which country a tran=
saction originates from.=C2=A0<div>To do that with a certain accuracy you n=
eed many nodes. We chose a class C IP range as we knew that bitcoin core an=
d others only connect to one node in any class C IP range. We were not awar=
e that breadwallet didn&#39;t follow this practice. Breadwallet risked gett=
ing 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-bloc=
ks and allowed everyone connecting to track the blockchain. We did however =
not relay transactions. The &#39;service&#39; bit in the version message is=
 not meant for telling whether or how the node relays transactions, it tell=
s whether you can ask for block headers only or full blocks.</div><div><br>=
</div><div>Many implementations enforce non standard rules for handling tra=
nsactions; some nodes ignore transactions with address reuse, some nodes ha=
ppily forward double spends, and some nodes forward neither blocks not tran=
sactions. We did blocks but not transactions.</div><div><br></div><div>In h=
indsight we should have done two things:</div><div>1. relay transactions</d=
iv><div>2. advertise address from &#39;foreign&#39; nodes</div><div><br></d=
iv><div>Both would have fixed the problems that breadwallet experienced. My=
 understanding is that breadwallet now has the same &#39;class C&#39; rule =
as bitcoind, which 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 go=
od as mine. I don&#39;t think it is illegal to log incoming connections and=
 make statistical analysis on it. That would more or less incriminate anyon=
e who runs a web-server and looks into the access log.</div><div>At lease o=
ne Bitcoin service has been collecting IP addresses for years and given the=
m 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.<br></div><div><br></div><div>On a side note=
: When you make many connections to the network you see lots of strange nod=
es and suspicious patterns. You can be certain that we were not the only on=
es connected to many nodes.<br></div><div><br></div><div>My takeaway from t=
his: If nodes that do not relay transactions is a problem then there is stu=
ff to fix.</div><div><br></div><div>/Jan</div></div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Fri, Mar=
 13, 2015 at 10:48 PM, Mike Hearn <span dir=3D"ltr">&lt;<a href=3D"mailto:m=
ike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</span> wrote:<br>=
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=
=3D"ltr"><div class=3D"gmail_extra">That would be rather new and tricky leg=
al 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 defi=
nitional issues.</div><div class=3D"gmail_extra"><br></div><div class=3D"gm=
ail_extra">For instance if the Chainalysis nodes started following the prot=
ocol specs better and became just regular nodes that happen to keep logs, w=
ould that still be a violation? If so, what about <a href=3D"http://blockch=
ain.info" target=3D"_blank">blockchain.info</a>? It&#39;d be shooting ourse=
lves in the foot to try and forbid block explorers given how useful they ar=
e.</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, and m=
akes full system backups every night, and keeps those backups for years, ar=
e 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&#39;s a bit ea=
rly to think about these things right now. Michael Gr=C3=B8nager and Jan M=
=C3=B8ller have been Bitcoin hackers for a long time. I&#39;d be interested=
 to know their thoughts on all of this.</div></div>
<br></div></div>-----------------------------------------------------------=
-------------------<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" target=3D"_bla=
nk">Bitcoin-development@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>
<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>

--f46d043c806a66164b05116cebc7--