From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) id 1Qovbc-0001kU-F2 for bitcoin-development@lists.sourceforge.net; Thu, 04 Aug 2011 10:56:48 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.175 as permitted sender) client-ip=209.85.160.175; envelope-from=witchspace81@gmail.com; helo=mail-gy0-f175.google.com; Received: from mail-gy0-f175.google.com ([209.85.160.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1Qovbb-0001Es-IL for bitcoin-development@lists.sourceforge.net; Thu, 04 Aug 2011 10:56:48 +0000 Received: by gyg4 with SMTP id 4so880738gyg.34 for ; Thu, 04 Aug 2011 03:56:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.114.2 with SMTP id m2mr1853626ybc.3.1312455402039; Thu, 04 Aug 2011 03:56:42 -0700 (PDT) Received: by 10.150.52.5 with HTTP; Thu, 4 Aug 2011 03:56:42 -0700 (PDT) Date: Thu, 4 Aug 2011 10:56:42 +0000 Message-ID: From: John Smith To: Bitcoin Dev Content-Type: multipart/alternative; boundary=000e0cd48bc605a92c04a9abd6bc 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 (witchspace81[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (witchspace81[at]gmail.com) 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: 1Qovbb-0001Es-IL Subject: [Bitcoin-development] Blitcoin? (Black Hat 2011) 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: Thu, 04 Aug 2011 10:56:48 -0000 --000e0cd48bc605a92c04a9abd6bc Content-Type: text/plain; charset=ISO-8859-1 L.S. Some bitcoin "security vulnerabilities" have been discussed by Dan Kaminsky at BH 2011, there is one article about this dated yesterday: http://searchsecurity.techtarget.com/news/2240039221/Black-Hat-2011-Dan-Kaminsky-reveals-network-security-research-topics The article is very unspecific though. They talk about a tool called "blitcoin" that "unmasks" both sides of a bitcoin transaction. A google search also turned up nothing, except some misspellings. Does anyone have more information? JS --000e0cd48bc605a92c04a9abd6bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable L.S.

Some bitcoin "security vulnerabilities" have been dis= cussed by Dan Kaminsky at BH 2011, there is one article about this dated ye= sterday:

= http://searchsecurity.techtarget.com/news/2240039221/Black-Hat-2011-Dan-Kam= insky-reveals-network-security-research-topics

The article is very unspecific though. They talk about a tool called &q= uot;blitcoin" that "unmasks" both sides of a bitcoin transac= tion. A google search also turned up nothing, except some misspellings.
Does anyone have more information?

JS
--000e0cd48bc605a92c04a9abd6bc-- From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) id 1Qoz3l-0003pH-4J for bitcoin-development@lists.sourceforge.net; Thu, 04 Aug 2011 14:38:05 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bluematt.me designates 173.246.101.161 as permitted sender) client-ip=173.246.101.161; envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me; Received: from vps.bluematt.me ([173.246.101.161] helo=mail.bluematt.me) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Qoz3k-0001Kv-9L for bitcoin-development@lists.sourceforge.net; Thu, 04 Aug 2011 14:38:05 +0000 Received: from [IPv6:2001:470:9ff2:1:ee55:f9ff:fec6:e666] (unknown [IPv6:2001:470:9ff2:1:ee55:f9ff:fec6:e666]) by mail.bluematt.me (Postfix) with ESMTPSA id 873822CCD for ; Thu, 4 Aug 2011 16:19:31 +0200 (CEST) From: Matt Corallo To: bitcoin-development@lists.sourceforge.net In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-/cbPSTWQxysTlT6BLCwu" Date: Thu, 04 Aug 2011 16:14:54 +0200 Message-ID: <1312467294.9762.4.camel@BMThinkPad.lan.bluematt.me> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 X-Spam-Score: -2.3 (--) 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 SPF_PASS SPF: sender matches SPF record -0.8 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1Qoz3k-0001Kv-9L Subject: Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 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: Thu, 04 Aug 2011 14:38:05 -0000 --=-/cbPSTWQxysTlT6BLCwu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sounds like Dan wrote a tool which attempts to connect inputs/outputs and make a map of a person on the network, or at least thats my blind guess. Something people have been saying was easily possible for some time, but for some reason people insist on refusing their precious Bitcoin isnt anonymous. Matt On Thu, 2011-08-04 at 10:56 +0000, John Smith wrote: > L.S. >=20 > Some bitcoin "security vulnerabilities" have been discussed by Dan > Kaminsky at BH 2011, there is one article about this dated yesterday: >=20 > http://searchsecurity.techtarget.com/news/2240039221/Black-Hat-2011-Dan-K= aminsky-reveals-network-security-research-topics >=20 > The article is very unspecific though. They talk about a tool called > "blitcoin" that "unmasks" both sides of a bitcoin transaction. A > google search also turned up nothing, except some misspellings.=20 >=20 > Does anyone have more information? >=20 > JS --=-/cbPSTWQxysTlT6BLCwu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABAgAGBQJOOqlcAAoJEBrh01BD4I5UIeMQAKlaltFmRx8eVpvH63nzfnqn u5zV2wVtbUCGijLmYPfHcvmHf1Le4SWx668FyZw0b/kcj80eAzJoUtH+sVCW4mxY M82pGUY2ur4sX0df8BV6Wan6YXhwVNcnOY7KKY2nmYWB0h756S5hnmqQBu1JiolT dT59qsit+WPu61sNWuLYmPam2ExrLSoVlB0ir9zTBMKI5JDCLEmP6Au3XnaZ03eh bA0hePDqTnJIFULqUWtwYAZDvJXaw1t3plQfePQJxiTHkRRZ6JX70SSY5dKUy2IR ub9KSbF4YeZxVtAyt0BOL2btW23pfX3+ZbfZ4UlMV8uGw6JkO0vnyr8YQW0kRNCj U4X6eipNvQpQ2TuA8El5AdcKYAz7C2S/09W259TUkUi33YoF9GI+tKxXum28Gkge RD5q5SKZCJ5WLr7tafVOn5Tpria0f49BEGo5BCkR6qcM9AsV122lS+5jMaHQnEJ4 JF2L+xeHdBxPdifYqx0qzVfxpAAvF5n4pZTZG6+0/Kc335pxOHnMuQGItxHhZ4cv iRnbQfYnyUafXRz8RvAxXwy/Fz3NmyYu/9G0d4IkKXy1DqqZ7sN0eZXMJ1hAOWK9 KmWWGws50tFqkyaebSJEdYXJI3qFRct/7HIVvyzcjYIIGczvKAgJzyCYgFzXpZL3 8cNpxL0CU9DpXX2PZ+Wg =9ebt -----END PGP SIGNATURE----- --=-/cbPSTWQxysTlT6BLCwu-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Qoz4k-0003rk-HR for bitcoin-development@lists.sourceforge.net; Thu, 04 Aug 2011 14:39:06 +0000 X-ACL-Warn: Received: from zinan.dashjr.org ([173.242.112.54]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Qoz4f-0005sp-Ml for bitcoin-development@lists.sourceforge.net; Thu, 04 Aug 2011 14:39:06 +0000 Received: from ishibashi.localnet (fl-67-77-87-241.dhcp.embarqhsd.net [67.77.87.241]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id EEB2D3AA050 for ; Thu, 4 Aug 2011 14:38:53 +0000 (UTC) From: "Luke-Jr" To: bitcoin-development@lists.sourceforge.net Date: Thu, 4 Aug 2011 10:38:44 -0400 User-Agent: KMail/1.13.7 (Linux/2.6.39-gentoo; KDE/4.6.4; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: CE5A D56A 36CC 69FA E7D2 3558 665F C11D D53E 9583 X-PGP-Key-ID: 665FC11DD53E9583 X-PGP-Keyserver: x-hkp://subkeys.pgp.net MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201108041038.47396.luke@dashjr.org> X-Spam-Score: -0.8 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.8 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1Qoz4f-0005sp-Ml Subject: Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 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: Thu, 04 Aug 2011 14:39:06 -0000 On Thursday, August 04, 2011 6:56:42 AM John Smith wrote: > L.S. > > Some bitcoin "security vulnerabilities" have been discussed by Dan Kaminsky > at BH 2011, there is one article about this dated yesterday: > > http://searchsecurity.techtarget.com/news/2240039221/Black-Hat-2011-Dan-Kam > insky-reveals-network-security-research-topics > > The article is very unspecific though. They talk about a tool called > "blitcoin" that "unmasks" both sides of a bitcoin transaction. A google > search also turned up nothing, except some misspellings. Well, that certainly doesn't sound like a security vulnerability at all. It's by design that everyone knows about every transaction. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Qp91n-0007Qe-Du for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 01:16:43 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.210.42 as permitted sender) client-ip=209.85.210.42; envelope-from=gavinandresen@gmail.com; helo=mail-pz0-f42.google.com; Received: from mail-pz0-f42.google.com ([209.85.210.42]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1Qp91m-0001kX-8M for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 01:16:43 +0000 Received: by pzk37 with SMTP id 37so2980612pzk.1 for ; Thu, 04 Aug 2011 18:16:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.216.14 with SMTP id o14mr1342285wfg.204.1312506996225; Thu, 04 Aug 2011 18:16:36 -0700 (PDT) Received: by 10.142.212.13 with HTTP; Thu, 4 Aug 2011 18:16:36 -0700 (PDT) In-Reply-To: <201108041038.47396.luke@dashjr.org> References: <201108041038.47396.luke@dashjr.org> Date: Fri, 5 Aug 2011 11:16:36 +1000 Message-ID: From: Gavin Andresen To: Luke-Jr Content-Type: multipart/alternative; boundary=000e0cd22d1046759804a9b7d969 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 (gavinandresen[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: 1Qp91m-0001kX-8M Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 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: Fri, 05 Aug 2011 01:16:43 -0000 --000e0cd22d1046759804a9b7d969 Content-Type: text/plain; charset=ISO-8859-1 Dan gave a brief explanation of "blitcoin" on the forums: https://bitcointalk.org/index.php?topic=34458.0 "As reported, I've got a BitCoin deanonymization mechanism. It's not complicated. Connect to every node in the cloud, discoverable via sweeping/IRC/get_peers messages. The first IP to consistently relay transactions for a given identity, is the given identity. Of course the entire BitCoin cloud doesn't allow inbound connections (although you can do rather evil stuff with UPNP to force that open too). But this isn't a problem -- there's only about 3000 to 8000 IPs that are BitCoin nodes that accept inbound connections. Since everyone else depends on them, you just need to create your own mass cluster of IPs that are a decent chunk of the P2P network. Nodes on average have seven outbound connections, so it should take only a few hundred unique to be one of the first-hop peers even for the outbound-only set." ... so it is a de-anonymize-via IP address not de-anonymize-via Bitcoin address. And might go partway to explaining why we're having trouble with network connectivity... -- -- Gavin Andresen --000e0cd22d1046759804a9b7d969 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dan gave a brief explanation of "blitcoin" on the forums:

"= Of course the entire BitCoin cloud doesn't allow inbound c= onnections (although you can do rather evil stuff with UPNP to force that o= pen too).=A0 But this isn't a problem -- there's only about 3000 to= 8000 IPs that are BitCoin nodes that accept inbound connections.=A0 Since = everyone else depends on them, you just need to create your own mass cluste= r of IPs that are a decent chunk of the P2P network.=A0 Nodes on average ha= ve seven outbound connections, so it should take only a few hundred unique = to be one of the first-hop peers even for the outbound-only set."

=
... so it is a de-ano= nymize-via IP address not de-anonymize-via Bitcoin address. =A0And might go= partway to explaining why we're having trouble with network connectivi= ty...

--
--
Gavin Andresen

--000e0cd22d1046759804a9b7d969-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QpD6T-0000hY-4t for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 05:37:49 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.83.47 as permitted sender) client-ip=74.125.83.47; envelope-from=witchspace81@gmail.com; helo=mail-gw0-f47.google.com; Received: from mail-gw0-f47.google.com ([74.125.83.47]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1QpD6S-000356-Gf for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 05:37:49 +0000 Received: by gwb11 with SMTP id 11so591469gwb.34 for ; Thu, 04 Aug 2011 22:37:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.8.10 with SMTP id 10mr2681080ybh.60.1312522662987; Thu, 04 Aug 2011 22:37:42 -0700 (PDT) Received: by 10.150.52.5 with HTTP; Thu, 4 Aug 2011 22:37:42 -0700 (PDT) In-Reply-To: References: <201108041038.47396.luke@dashjr.org> Date: Fri, 5 Aug 2011 05:37:42 +0000 Message-ID: From: John Smith To: Gavin Andresen Content-Type: multipart/alternative; boundary=000e0cd2537c164a1404a9bb7f94 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 (witchspace81[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (witchspace81[at]gmail.com) 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: 1QpD6S-000356-Gf Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 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: Fri, 05 Aug 2011 05:37:49 -0000 --000e0cd2537c164a1404a9bb7f94 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 5, 2011 at 1:16 AM, Gavin Andresen wrote: > > ... so it is a de-anonymize-via IP address not de-anonymize-via Bitcoin > address. And might go partway to explaining why we're having trouble with > network connectivity... > Well it's good that the bitcoin network is seeing some security testing. So I understand that we have a combination of problems at the moment: 1) A DDoS possibility (if this is really the cause of the network connectivity problems) 2) An attacker can figure out which node first broadcasted a transaction, by connecting to the entire network or having everyone connect to his node(s) 3) The recipient re-broadcasts transactions (is Theymos right here?), allowing both the sender and recipient to be found Drawok's suggestion about using UDP packets with spoofed sender addresses is interesting, as UDP has another advantage; you can open up an "inbound" UDP port on almost any NAT router without any UPNP magic: just send out an UDP packet, the router will wait a certain time for answers (on a mapped port number) and relay these back. It also has some potential issues; the client needs special privileges to spoof sender addresses, and some ISPs might filter out packets with non-matching sender addriess (unsure how common this is). JS --000e0cd2537c164a1404a9bb7f94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 5, 2011 at 1:16 AM, Gavin Andres= en <gavinan= dresen@gmail.com> wrote:

... so it is a de-anonymize-via IP address not de-anonymize-via Bitcoin a= ddress. =A0And might go partway to explaining why we're having trouble = with network connectivity...

Well it's good that the bitcoin network is seeing= some security testing.

So I understand that we have a combination o= f problems at the moment:

1) A DDoS possibility=A0 (if this is reall= y the cause of the network connectivity problems)

2) An attacker can figure out which node first broadcasted a transactio= n, by connecting to the entire network or having everyone connect to his no= de(s)

3) The recipient re-broadcasts transactions (is Theymos right = here?), allowing both the sender and recipient to be found

Drawok's suggestion about using UDP packets with spoofed sender add= resses is interesting, as UDP has another advantage; you can open up an &qu= ot;inbound" UDP port on almost any NAT router without any UPNP magic: = just send out an UDP packet, the router will wait a certain time for answer= s (on a mapped port number) and relay these back.

It also has some potential issues; the client needs special privileges = to spoof sender addresses, and some ISPs might filter out packets with non-= matching sender addriess (unsure how common this is).

JS

--000e0cd2537c164a1404a9bb7f94-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QpDKO-0005VW-4U for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 05:52:12 +0000 X-ACL-Warn: Received: from mail-iy0-f171.google.com ([209.85.210.171]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QpDKN-0003i8-Az for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 05:52:12 +0000 Received: by iyf13 with SMTP id 13so4123316iyf.30 for ; Thu, 04 Aug 2011 22:52:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.166.74 with SMTP id n10mr1753074icy.67.1312523525572; Thu, 04 Aug 2011 22:52:05 -0700 (PDT) Received: by 10.42.19.65 with HTTP; Thu, 4 Aug 2011 22:52:05 -0700 (PDT) X-Originating-IP: [99.173.148.118] In-Reply-To: References: <201108041038.47396.luke@dashjr.org> Date: Fri, 5 Aug 2011 01:52:05 -0400 Message-ID: From: Jeff Garzik To: John Smith Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1QpDKN-0003i8-Az Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 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: Fri, 05 Aug 2011 05:52:12 -0000 On Fri, Aug 5, 2011 at 1:37 AM, John Smith wrote: > Well it's good that the bitcoin network is seeing some security testing. Yep. > 1) A DDoS possibility=A0 (if this is really the cause of the network > connectivity problems) Unfortunately the nodes accepting incoming connections are small enough in number (7000?) that you can shut down a lot by attacking those nodes. This was part of the motivation of turning on upnp by default in the GUI version, but maybe we need to go further than that... > 3) The recipient re-broadcasts transactions (is Theymos right here?), > allowing both the sender and recipient to be found Yes, that is correct. Bitcoin resends wallet transactions with zero confirmations, and both sent and received transactions fall within the "wallet tx" superset. TBH I had forgotten about the resend on the receiver side, though. It, of course, makes plenty of sense in the context of importing transactions from foreign sources, e.g. receiving transactions via a USB flash drive. > Drawok's suggestion about using UDP packets with spoofed sender addresses= is > interesting, as UDP has another advantage; you can open up an "inbound" U= DP > port on almost any NAT router without any UPNP magic: just send out an UD= P > packet, the router will wait a certain time for answers (on a mapped port > number) and relay these back. > > It also has some potential issues; the client needs special privileges to > spoof sender addresses, and some ISPs might filter out packets with > non-matching sender addriess (unsure how common this is). Well, it -is- possible to implement TCP over UDP The TCP connection sequence over UDP helps to work against spoofing, while UDP helps to open an inbound UDP port as you describe. Not that I'm endorsing a bitcoin-internal TCP stack... just sayin' :) --=20 Jeff Garzik exMULTI, Inc. jgarzik@exmulti.com From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) id 1QpDO7-00015f-1s for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 05:56:03 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.47 as permitted sender) client-ip=209.85.213.47; envelope-from=witchspace81@gmail.com; helo=mail-yw0-f47.google.com; Received: from mail-yw0-f47.google.com ([209.85.213.47]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1QpDO6-0007yJ-B5 for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 05:56:03 +0000 Received: by ywe9 with SMTP id 9so2001131ywe.34 for ; Thu, 04 Aug 2011 22:55:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.114.2 with SMTP id m2mr2869519ybc.3.1312523756857; Thu, 04 Aug 2011 22:55:56 -0700 (PDT) Received: by 10.150.52.5 with HTTP; Thu, 4 Aug 2011 22:55:56 -0700 (PDT) In-Reply-To: References: <201108041038.47396.luke@dashjr.org> Date: Fri, 5 Aug 2011 05:55:56 +0000 Message-ID: From: John Smith To: Gavin Andresen Content-Type: multipart/alternative; boundary=000e0cd48bc649697f04a9bbc013 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 (witchspace81[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (witchspace81[at]gmail.com) 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: 1QpDO6-0007yJ-B5 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 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: Fri, 05 Aug 2011 05:56:03 -0000 --000e0cd48bc649697f04a9bbc013 Content-Type: text/plain; charset=ISO-8859-1 > 3) The recipient re-broadcasts transactions (is Theymos right here?), > allowing both the sender and recipient to be found > Hm this would potentially allow getting the IP for any recipient Bitcoin address, given that a client with the private key connects to the network once in a while. Send them a transaction that is guaranteed to not be written into a block by a miner, then monitor who rebroadcasts it over a few days/weeks. I guess this could also be used to find out who has the stolen coins. JS --000e0cd48bc649697f04a9bbc013 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
3) The recipient re-broadcasts transactions (is Theym= os right here?), allowing both the sender and recipient to be found

Hm this would potentially allow getting t= he IP for any recipient Bitcoin address, given that a client with the priva= te key connects to the network once in a while.

Send them a transac= tion that is guaranteed to not be written into a block by a miner, then mon= itor who rebroadcasts it over a few days/weeks.

I guess this could also be used to find out who has the stolen coins.
JS

--000e0cd48bc649697f04a9bbc013-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QpJ64-00077h-99 for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 12:01:48 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.47 as permitted sender) client-ip=209.85.215.47; envelope-from=joel.kaartinen@gmail.com; helo=mail-ew0-f47.google.com; Received: from mail-ew0-f47.google.com ([209.85.215.47]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QpJ63-0004zG-KL for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 12:01:48 +0000 Received: by ewy5 with SMTP id 5so2058101ewy.34 for ; Fri, 05 Aug 2011 05:01:41 -0700 (PDT) Received: by 10.204.128.150 with SMTP id k22mr657522bks.94.1312545701282; Fri, 05 Aug 2011 05:01:41 -0700 (PDT) Received: from [91.153.53.68] (a91-153-53-68.elisa-laajakaista.fi [91.153.53.68]) by mx.google.com with ESMTPS id t19sm838910bku.40.2011.08.05.05.01.39 (version=SSLv3 cipher=OTHER); Fri, 05 Aug 2011 05:01:39 -0700 (PDT) From: Joel Joonatan Kaartinen To: Jeff Garzik In-Reply-To: References: <201108041038.47396.luke@dashjr.org> Content-Type: text/plain; charset="UTF-8" Date: Fri, 05 Aug 2011 15:01:37 +0300 Message-ID: <1312545697.19584.56.camel@mei> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.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 (joel.kaartinen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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: 1QpJ63-0004zG-KL Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 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: Fri, 05 Aug 2011 12:01:48 -0000 On Fri, 2011-08-05 at 01:52 -0400, Jeff Garzik wrote: > Yes, that is correct. Bitcoin resends wallet transactions with zero > confirmations, and both sent and received transactions fall within the > "wallet tx" superset. > > TBH I had forgotten about the resend on the receiver side, though. > It, of course, makes plenty of sense in the context of importing > transactions from foreign sources, e.g. receiving transactions via a > USB flash drive. Could every node do the resends? Alternatively, could we implement a TOR like tunneling system just for the first leg of the transactions (overkill?). Then again, maybe just a TOR gateway if that's desired. > > Drawok's suggestion about using UDP packets with spoofed sender addresses is > > interesting, as UDP has another advantage; you can open up an "inbound" UDP > > port on almost any NAT router without any UPNP magic: just send out an UDP > > packet, the router will wait a certain time for answers (on a mapped port > > number) and relay these back. This is a nice idea but sounds rather unreliable. > Well, it -is- possible to implement TCP over UDP The TCP > connection sequence over UDP helps to work against spoofing, while UDP > helps to open an inbound UDP port as you describe. There's already an implementation of this, called UTP. If we do decide that using UDP is worthwhile, this library is probably better than implementing something ourselves. - Joel From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QpK03-0002V6-Vf for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 12:59:39 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.83.47 as permitted sender) client-ip=74.125.83.47; envelope-from=decker.christian@gmail.com; helo=mail-gw0-f47.google.com; Received: from mail-gw0-f47.google.com ([74.125.83.47]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1QpK03-0002Xi-01 for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 12:59:39 +0000 Received: by gwb11 with SMTP id 11so764281gwb.34 for ; Fri, 05 Aug 2011 05:59:33 -0700 (PDT) Received: by 10.142.247.15 with SMTP id u15mr2021487wfh.307.1312549173257; Fri, 05 Aug 2011 05:59:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.52.98 with HTTP; Fri, 5 Aug 2011 05:58:53 -0700 (PDT) In-Reply-To: <1312545697.19584.56.camel@mei> References: <201108041038.47396.luke@dashjr.org> <1312545697.19584.56.camel@mei> From: Christian Decker Date: Fri, 5 Aug 2011 14:58:53 +0200 Message-ID: To: Bitcoin Development Content-Type: multipart/alternative; boundary=00504502cc3438e69f04a9c1ab69 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 (decker.christian[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: 1QpK03-0002Xi-01 Subject: Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 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: Fri, 05 Aug 2011 12:59:40 -0000 --00504502cc3438e69f04a9c1ab69 Content-Type: text/plain; charset=ISO-8859-1 While I do think that anonymity (or pseudonymity) is a nice feature, I don't think it deserves the full focus of the developers. The core of the protocol is about making transactions in a secure and fast way, not allowing everybody to be anonymous, whether they want to or not. TOR already is a good options for those that want to stay anonymous, and there is no need to pull support into the main client, if only a few will use it. I think very few of the developers actually claimed that Bitcoin is anonymous, and has never been a big advertising point from the "official" side of Bitcoin, network analysis has been always known to break anonymity. I see no need for action from the developer side. -cdecker On Fri, Aug 5, 2011 at 2:01 PM, Joel Joonatan Kaartinen < joel.kaartinen@gmail.com> wrote: > On Fri, 2011-08-05 at 01:52 -0400, Jeff Garzik wrote: > > Yes, that is correct. Bitcoin resends wallet transactions with zero > > confirmations, and both sent and received transactions fall within the > > "wallet tx" superset. > > > > TBH I had forgotten about the resend on the receiver side, though. > > It, of course, makes plenty of sense in the context of importing > > transactions from foreign sources, e.g. receiving transactions via a > > USB flash drive. > > Could every node do the resends? Alternatively, could we implement a TOR > like tunneling system just for the first leg of the transactions > (overkill?). Then again, maybe just a TOR gateway if that's desired. > > > > Drawok's suggestion about using UDP packets with spoofed sender > addresses is > > > interesting, as UDP has another advantage; you can open up an "inbound" > UDP > > > port on almost any NAT router without any UPNP magic: just send out an > UDP > > > packet, the router will wait a certain time for answers (on a mapped > port > > > number) and relay these back. > > This is a nice idea but sounds rather unreliable. > > > Well, it -is- possible to implement TCP over UDP The TCP > > connection sequence over UDP helps to work against spoofing, while UDP > > helps to open an inbound UDP port as you describe. > > There's already an implementation of this, called UTP. If we do decide > that using UDP is worthwhile, this library is probably better than > implementing something ourselves. > > - Joel > > > > > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > The must-attend event for mobile developers. Connect with experts. > Get tools for creating Super Apps. See the latest technologies. > Sessions, hands-on labs, demos & much more. Register early & save! > http://p.sf.net/sfu/rim-blackberry-1 > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --00504502cc3438e69f04a9c1ab69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable While I do think that anonymity (or pseudonymity) is a nice feature, I don&= #39;t think it deserves the full focus of the developers. The core of the p= rotocol is about making transactions in a secure and fast way, not allowing= everybody to be anonymous, whether they want to or not. TOR already is a g= ood options for those that want to stay anonymous, and there is no need to = pull support into the main client, if only a few will use it. I think very = few of the developers actually claimed that Bitcoin is anonymous, and has n= ever been a big advertising point from the "official" side of Bit= coin, network analysis has been always known to break anonymity.

I see no need for action from the developer side.

-cdecker
On Fri, Aug 5, 2011 at 2:01 PM, Joel Joonatan = Kaartinen <joel.kaartinen@gmail.com> wrote:
On Fri, 2011-08-05 at 01:= 52 -0400, Jeff Garzik wrote:
> Yes, that is correct. =A0Bitcoin resends wallet transactions with zero=
> confirmations, and both sent and received transactions fall within the=
> "wallet tx" superset.
>
> TBH I had forgotten about the resend on the receiver side, though.
> It, of course, makes plenty of sense in the context of importing
> transactions from foreign sources, e.g. receiving transactions via a > USB flash drive.

Could every node do the resends? Alternatively, could we implement a = TOR
like tunneling system just for the first leg of the transactions
(overkill?). Then again, maybe just a TOR gateway if that's desired.

> > Drawok's suggestion about using UDP packets with spoofed send= er addresses is
> > interesting, as UDP has another advantage; you can open up an &qu= ot;inbound" UDP
> > port on almost any NAT router without any UPNP magic: just send o= ut an UDP
> > packet, the router will wait a certain time for answers (on a map= ped port
> > number) and relay these back.

This is a nice idea but sounds rather unreliable.

> Well, it -is- possible to implement TCP over UDP <grin> =A0The T= CP
> connection sequence over UDP helps to work against spoofing, while UDP=
> helps to open an inbound UDP port as you describe.

There's already an implementation of this, called UTP. If we do d= ecide
that using UDP is worthwhile, this library is probably better than
implementing something ourselves.

- Joel



---------------------------------------------------------------------------= ---
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!<= br> http://p= .sf.net/sfu/rim-blackberry-1
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--00504502cc3438e69f04a9c1ab69-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QpK7Q-0000JO-LH for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 13:07:16 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.53 as permitted sender) client-ip=74.125.82.53; envelope-from=andyparkins@gmail.com; helo=mail-ww0-f53.google.com; Received: from mail-ww0-f53.google.com ([74.125.82.53]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QpK7Q-0007FX-0e for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 13:07:16 +0000 Received: by wwf25 with SMTP id 25so73900wwf.10 for ; Fri, 05 Aug 2011 06:07:09 -0700 (PDT) Received: by 10.227.19.195 with SMTP id c3mr1814248wbb.98.1312549629825; Fri, 05 Aug 2011 06:07:09 -0700 (PDT) Received: from dvr.localnet (mail.360visiontechnology.com [92.42.121.178]) by mx.google.com with ESMTPS id eo18sm2281152wbb.63.2011.08.05.06.07.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Aug 2011 06:07:08 -0700 (PDT) From: Andy Parkins To: bitcoin-development@lists.sourceforge.net Date: Fri, 5 Aug 2011 14:07:05 +0100 User-Agent: KMail/1.13.6 (Linux/2.6.38-2-686; KDE/4.6.3; i686; ; ) References: <201108041038.47396.luke@dashjr.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5973170.lotD1xUgr4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201108051407.06216.andyparkins@gmail.com> X-Spam-Score: -1.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 (andyparkins[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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 0.0 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service -0.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1QpK7Q-0007FX-0e Subject: Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 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: Fri, 05 Aug 2011 13:07:16 -0000 --nextPart5973170.lotD1xUgr4 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On 2011 August 05 Friday, Gavin Andresen wrote: > "As reported, I've got a BitCoin deanonymization mechanism. It's not > complicated. >=20 > Connect to every node in the cloud, discoverable via sweeping/IRC/get_pee= rs > messages. The first IP to consistently relay transactions for a given > identity, is the given identity. Transaction forwarding could be randomised slightly, by randomising the=20 outgoing relay order; and adding a random delay between each forward. Even= =20 the massively connected monitor can't represent _all_ the connections on ev= ery=20 real node, so it would have no way of knowing whether it got any transactio= n=20 from the originator or because it got a fast path through the first N nodes= to=20 receive it. Andy =2D-=20 Dr Andy Parkins andyparkins@gmail.com --nextPart5973170.lotD1xUgr4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk476voACgkQwQJ9gE9xL220CACeOeJTNlTle1JcoLmZrkDcldKi QwMAnRYlOVD/OXQrZi01fU4pWOiQnJ3C =8M/g -----END PGP SIGNATURE----- --nextPart5973170.lotD1xUgr4-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QpKBu-0007l6-BU for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 13:11:54 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.175 as permitted sender) client-ip=209.85.160.175; envelope-from=witchspace81@gmail.com; helo=mail-gy0-f175.google.com; Received: from mail-gy0-f175.google.com ([209.85.160.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1QpKBt-0007hv-MK for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 13:11:54 +0000 Received: by gyg4 with SMTP id 4so1782253gyg.34 for ; Fri, 05 Aug 2011 06:11:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.8.10 with SMTP id 10mr3060605ybh.60.1312549908233; Fri, 05 Aug 2011 06:11:48 -0700 (PDT) Received: by 10.150.52.5 with HTTP; Fri, 5 Aug 2011 06:11:48 -0700 (PDT) In-Reply-To: References: <201108041038.47396.luke@dashjr.org> <1312545697.19584.56.camel@mei> Date: Fri, 5 Aug 2011 13:11:48 +0000 Message-ID: From: John Smith To: Christian Decker Content-Type: multipart/alternative; boundary=000e0cd2537c07bcd704a9c1d721 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 (witchspace81[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (witchspace81[at]gmail.com) 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: 1QpKBt-0007hv-MK Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 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: Fri, 05 Aug 2011 13:11:54 -0000 --000e0cd2537c07bcd704a9c1d721 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 5, 2011 at 12:58 PM, Christian Decker < decker.christian@gmail.com> wrote: > While I do think that anonymity (or pseudonymity) is a nice feature, I > don't think it deserves the full focus of the developers. The core of the > protocol is about making transactions in a secure and fast way, not allowing > everybody to be anonymous, whether they want to or not. TOR already is a > good options for those that want to stay anonymous, and there is no need to > pull support into the main client, if only a few will use it. I think very > few of the developers actually claimed that Bitcoin is anonymous, and has > never been a big advertising point from the "official" side of Bitcoin, > network analysis has been always known to break anonymity. > Yes. Optionally layering Bitcoin over Tor/I2P is a much better option than trying to replicate an onion network in Bitcoin itself. For one, traffic analysis is much more difficult if your onion routing network contains multiple kinds of traffic. Also it would complicate the core algorithm and waste developer time. Doing anonymity *right* is very hard. So let's leave it to the Tor/I2P people that know what they're doing. > > I see no need for action from the developer side. > Except the part about making the client/network more resistant against DDoS. JS --000e0cd2537c07bcd704a9c1d721 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Aug 5, 2011 at 12:58 PM, Christi= an Decker <decker.christian@gmail.com> wrote:
While I do think that anonymity (or pseudonymity) is a nice feature, I don&= #39;t think it deserves the full focus of the developers. The core of the p= rotocol is about making transactions in a secure and fast way, not allowing= everybody to be anonymous, whether they want to or not. TOR already is a g= ood options for those that want to stay anonymous, and there is no need to = pull support into the main client, if only a few will use it. I think very = few of the developers actually claimed that Bitcoin is anonymous, and has n= ever been a big advertising point from the "official" side of Bit= coin, network analysis has been always known to break anonymity.

Yes. Optionally layering Bitcoin over Tor/I2P is a mu= ch better option than trying to replicate an onion network in Bitcoin itsel= f. For one,=A0 traffic analysis is much more difficult if your onion routin= g network contains multiple kinds of traffic. Also it would complicate the = core algorithm and waste developer time. Doing anonymity *right* is very ha= rd. So let's leave it to the Tor/I2P people that know what they're = doing.
=A0

I see no need for action from the developer side.
=
Except the part about making the client/network more resistant against = DDoS.

JS

--000e0cd2537c07bcd704a9c1d721-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QpKJG-0000jP-1u for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 13:19:30 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.175 as permitted sender) client-ip=209.85.213.175; envelope-from=witchspace81@gmail.com; helo=mail-yx0-f175.google.com; Received: from mail-yx0-f175.google.com ([209.85.213.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1QpKJF-0007bb-Eu for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 13:19:30 +0000 Received: by yxi19 with SMTP id 19so2180827yxi.34 for ; Fri, 05 Aug 2011 06:19:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.8.10 with SMTP id 10mr3068686ybh.60.1312550364053; Fri, 05 Aug 2011 06:19:24 -0700 (PDT) Received: by 10.150.52.5 with HTTP; Fri, 5 Aug 2011 06:19:23 -0700 (PDT) In-Reply-To: <201108051407.06216.andyparkins@gmail.com> References: <201108041038.47396.luke@dashjr.org> <201108051407.06216.andyparkins@gmail.com> Date: Fri, 5 Aug 2011 13:19:23 +0000 Message-ID: From: John Smith To: Andy Parkins Content-Type: multipart/alternative; boundary=000e0cd2537c33017a04a9c1f2fe 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 (witchspace81[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (witchspace81[at]gmail.com) 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: 1QpKJF-0007bb-Eu Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Blitcoin? (Black Hat 2011) 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: Fri, 05 Aug 2011 13:19:30 -0000 --000e0cd2537c33017a04a9c1f2fe Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 5, 2011 at 1:07 PM, Andy Parkins wrote: > On 2011 August 05 Friday, Gavin Andresen wrote: > > Transaction forwarding could be randomised slightly, by randomising the > outgoing relay order; and adding a random delay between each forward. Even > the massively connected monitor can't represent _all_ the connections on > every > real node, so it would have no way of knowing whether it got any > transaction > from the originator or because it got a fast path through the first N nodes > to > receive it. > Right, while it doesn't warrant completely changing the transport protocol to UDP or implementing onion routing, I'm all for simple timing and order randomization changes if they can make attacks like this less effective. JS --000e0cd2537c33017a04a9c1f2fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Aug 5, 2011 at 1:07 PM, Andy Par= kins <andyparkins@gmail.com> wrote:
On 2011 August 05 Friday, Gavin Andresen wrote:

Transaction forwarding could be randomised slightly, by randomising t= he
outgoing relay order; and adding a random delay between each forward. =A0Ev= en
the massively connected monitor can't represent _all_ the connections o= n every
real node, so it would have no way of knowing whether it got any transactio= n
from the originator or because it got a fast path through the first N nodes= to
receive it.

Right, while it doesn't warrant co= mpletely changing the transport protocol to UDP or implementing onion routi= ng,=A0 I'm all for simple timing and order randomization changes if the= y can make attacks like this less effective.

JS

--000e0cd2537c33017a04a9c1f2fe--