diff options
author | Christian Decker <decker.christian@gmail.com> | 2011-08-05 14:58:53 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2011-08-05 12:59:39 +0000 |
commit | 89323400e1914eb5036c3f644a1c4532ad5b485e (patch) | |
tree | 22e3e401a834906ffee43dd84668c5022d1e4e50 | |
parent | 5f31d391a611b69f346c89c4220dd4c7c08cccab (diff) | |
download | pi-bitcoindev-89323400e1914eb5036c3f644a1c4532ad5b485e.tar.gz pi-bitcoindev-89323400e1914eb5036c3f644a1c4532ad5b485e.zip |
Re: [Bitcoin-development] Blitcoin? (Black Hat 2011)
-rw-r--r-- | 8c/c77922556fc91167ba8f74fd7b3ca8fcfd4a1b | 222 |
1 files changed, 222 insertions, 0 deletions
diff --git a/8c/c77922556fc91167ba8f74fd7b3ca8fcfd4a1b b/8c/c77922556fc91167ba8f74fd7b3ca8fcfd4a1b new file mode 100644 index 000000000..42bd23f8a --- /dev/null +++ b/8c/c77922556fc91167ba8f74fd7b3ca8fcfd4a1b @@ -0,0 +1,222 @@ +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 <decker.christian@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>; + 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: <CAJNQ0svWgFwZrra0gQFpxNLOPXk4RbKygeMUNPEA=k-Wqwa-ZA@mail.gmail.com> + <201108041038.47396.luke@dashjr.org> + <CABsx9T2tAeOp6RAb+Zb5zmzdSePZV90Uu=r4mzFc44d6ndbcnQ@mail.gmail.com> + <CAJNQ0stRrv4Yqf9ENszoXJE8+FpzwXZaGVDP=stZi27x4BRmmg@mail.gmail.com> + <CA+8xBpd0ud0Jn7Xxfw3C-WCH12WuB7k_W5x00Mj2EidemGoYpQ@mail.gmail.com> + <1312545697.19584.56.camel@mei> +From: Christian Decker <decker.christian@gmail.com> +Date: Fri, 5 Aug 2011 14:58:53 +0200 +Message-ID: <CALxbBHXbgDqZc1W+NJDbD78MP45U_oLkFVed5f3xWmJJGm=gCA@mail.gmail.com> +To: Bitcoin Development <bitcoin-development@lists.sourceforge.net> +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: <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: 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 <grin> 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.<br> + +<br>I see no need for action from the developer side.<br><br>-cdecker<br><b= +r><div class=3D"gmail_quote">On Fri, Aug 5, 2011 at 2:01 PM, Joel Joonatan = +Kaartinen <span dir=3D"ltr"><<a href=3D"mailto:joel.kaartinen@gmail.com"= +>joel.kaartinen@gmail.com</a>></span> wrote:<br> + +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex;"><div class=3D"im">On Fri, 2011-08-05 at 01:= +52 -0400, Jeff Garzik wrote:<br> +> Yes, that is correct. =A0Bitcoin resends wallet transactions with zero= +<br> +> confirmations, and both sent and received transactions fall within the= +<br> +> "wallet tx" superset.<br> +><br> +> TBH I had forgotten about the resend on the receiver side, though.<br> +> It, of course, makes plenty of sense in the context of importing<br> +> transactions from foreign sources, e.g. receiving transactions via a<b= +r> +> USB flash drive.<br> +<br> +</div>Could every node do the resends? Alternatively, could we implement a = +TOR<br> +like tunneling system just for the first leg of the transactions<br> +(overkill?). Then again, maybe just a TOR gateway if that's desired.<br= +> +<div class=3D"im"><br> +> > Drawok's suggestion about using UDP packets with spoofed send= +er addresses is<br> +> > interesting, as UDP has another advantage; you can open up an &qu= +ot;inbound" UDP<br> +> > port on almost any NAT router without any UPNP magic: just send o= +ut an UDP<br> +> > packet, the router will wait a certain time for answers (on a map= +ped port<br> +> > number) and relay these back.<br> +<br> +</div>This is a nice idea but sounds rather unreliable.<br> +<div class=3D"im"><br> +> Well, it -is- possible to implement TCP over UDP <grin> =A0The T= +CP<br> +> connection sequence over UDP helps to work against spoofing, while UDP= +<br> +> helps to open an inbound UDP port as you describe.<br> +<br> +</div>There's already an implementation of this, called UTP. If we do d= +ecide<br> +that using UDP is worthwhile, this library is probably better than<br> +implementing something ourselves.<br> +<font color=3D"#888888"><br> +- Joel<br> +</font><div><div></div><div class=3D"h5"><br> +<br> +<br> +---------------------------------------------------------------------------= +---<br> +BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA<br> +The must-attend event for mobile developers. Connect with experts.<br> +Get tools for creating Super Apps. See the latest technologies.<br> +Sessions, hands-on labs, demos & much more. Register early & save!<= +br> +<a href=3D"http://p.sf.net/sfu/rim-blackberry-1" target=3D"_blank">http://p= +.sf.net/sfu/rim-blackberry-1</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> +</div></div></blockquote></div><br> + +--00504502cc3438e69f04a9c1ab69-- + + |