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