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 ) 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 ; 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: References: <55034205.4030607@localhost.local> Date: Mon, 16 Mar 2015 12:33:06 -0700 Message-ID: From: Aaron Voisine 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 , Justus Ranvier 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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
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's now more robust against syb= il/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 net= work disruption. It's our job to better handle non-standard or even mal= icious 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=B8= ller <jan.moller@gmail.com> wrote:
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
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't follow this practice. Breadwallet risked gett= ing tar-pitted, but that was not our intention and we are sorry about that.=

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 'service' 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.

=
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.

In h= indsight 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 go= od 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 anyon= e who runs a web-server and looks into the access log.
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.

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.

My takeaway from t= his: If nodes that do not relay transactions is a problem then there is stu= ff 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 leg= al territory.=C2=A0

But even putting the legal issues to one side, there are defi= nitional issues.

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 blockchain.info? It'd be shooting ourse= lves in the foot to try and forbid block explorers given how useful they ar= e.

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?

I think it'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'd be interested= to know their thoughts on all of this.

-----------------------------------------------------------= -------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponso= red
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-de= velopment



-----------------------------------------------------------------------= -------
Dive into the World of Parallel Programming The Go Parallel Website, sponso= red
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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--f46d043c806a66164b05116cebc7--