diff options
| author | Jan Møller <jan.moller@gmail.com> | 2015-03-16 09:44:33 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-03-16 08:44:42 +0000 |
| commit | 65cbe47a2a891d02fecaf88255bea9b66d364ff7 (patch) | |
| tree | 1d7875aecbad1190effa14beddf994c97dd2b9ff | |
| parent | 2810fe1d56028b82367c1fd79269fcb6e09f6c1a (diff) | |
| download | pi-bitcoindev-65cbe47a2a891d02fecaf88255bea9b66d364ff7.tar.gz pi-bitcoindev-65cbe47a2a891d02fecaf88255bea9b66d364ff7.zip | |
Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups
| -rw-r--r-- | 34/52c35a7645ce939cfc98c2e608d25f58bbc10f | 240 |
1 files changed, 240 insertions, 0 deletions
diff --git a/34/52c35a7645ce939cfc98c2e608d25f58bbc10f b/34/52c35a7645ce939cfc98c2e608d25f58bbc10f new file mode 100644 index 000000000..dee95e20a --- /dev/null +++ b/34/52c35a7645ce939cfc98c2e608d25f58bbc10f @@ -0,0 +1,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-- + + |