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 1QcgsI-0001Vp-OL for bitcoin-development@lists.sourceforge.net; Fri, 01 Jul 2011 16:47:26 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.47 as permitted sender) client-ip=209.85.212.47; envelope-from=rmckay@gmail.com; helo=mail-vw0-f47.google.com; Received: from mail-vw0-f47.google.com ([209.85.212.47]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QcgsH-00085G-Er for bitcoin-development@lists.sourceforge.net; Fri, 01 Jul 2011 16:47:26 +0000 Received: by vws2 with SMTP id 2so3761233vws.34 for ; Fri, 01 Jul 2011 09:47:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.109.66 with SMTP id hq2mr4967662vdb.146.1309538839700; Fri, 01 Jul 2011 09:47:19 -0700 (PDT) Sender: rmckay@gmail.com Received: by 10.52.106.202 with HTTP; Fri, 1 Jul 2011 09:47:19 -0700 (PDT) In-Reply-To: <20110701163558.GA7311@dax.lan.local> References: <1309478838.3689.25.camel@Desktop666> <20110701080042.GA657@ulyssis.org> <1309524016.2541.0.camel@Desktop666> <20110701163558.GA7311@dax.lan.local> Date: Fri, 1 Jul 2011 17:47:19 +0100 X-Google-Sender-Auth: LSz0W37T7P2d9i4aXtJu9PnQsVI Message-ID: From: Robert McKay To: jan@uos.de Content-Type: multipart/alternative; boundary=bcaec5485fca5c256904a704c5d4 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 (rmckay[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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 X-Headers-End: 1QcgsH-00085G-Er Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] 0.3.24 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, 01 Jul 2011 16:47:26 -0000 --bcaec5485fca5c256904a704c5d4 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 1, 2011 at 5:35 PM, wrote: > On Fri, Jul 01, 2011 at 11:06:56AM -0400, Gavin Andresen wrote: > > > Not sure about OS differentiation, seems...wrong? Maybe disabled by > > > default on bitcoind but on by default on bitcoin? > > > > OK. I mis-remembered the poll: > > http://forum.bitcoin.org/index.php?topic=4392.0 > > > > On by default 8 (20%) > > Off by default 22 (55%) > > On by default in the GUI, off by default in bitcoind 10 (25%) > > I just voted as well and now - with some extra votes in the meantime - > it's 9 / 22 / 13. So exactly 50/50 between off (22) and some form of on > (9 + 13). > > I'm in favor of turning it on by default in the GUI and leaving it off > in bitcoind. > > I don't like UPnP much, I find it exemplifies exactly what is wrong with > computer security today: Convenience trumps security almost every time. > > BUT: I don't think this is the moment to fight UPnP. It's the standard > mechanism in use today to let a computer behind a NAT accept incoming > connections. The user has already made the decision in regards to > convenience over security. By enabling UPnP (or by buying a product that > does this automatically) they are saying: I want it to "just work" > instead of having fine-grained but more complicated control. > > Bitcoin is a P2P application and as such should use this > mechanism. I think it's pretty clear that participating in a P2P network > requires one to receive messages from other peers. At least no one seems > to be concerned that Bitcoin (by default!) listens on port 8333. So I > think it's only logical to extend that to work behind NATs as well If bitcoin listened on IPv6 that might help for alot of people. Windows 7 users get a teredo IPv6 address (unless they disable it) when behind NAT on IPv4. Take any win7 box and put it on a typical NAT /DSL setup this is what happens. I think this might actually work for more users than have UPNP support on their DSL gateways. teredo IPs aren't that stable though (they change frequently) and they might tend to flood the address cache with stale addresses. Rob --bcaec5485fca5c256904a704c5d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 1, 2011 at 5:35 PM, <jan@uos.de> wrote:
On Fri, Jul 01, 2011 at 11:06:56AM -0400, Gavin Andresen = wrote:
> > Not sure about OS differentiation, seems...wrong? =A0Maybe disabl= ed by
> > default on bitcoind but on by default on bitcoin?
>
> OK. =A0I mis-remembered the poll:
> =A0 =A0http://forum.bitcoin.org/index.php?topic=3D4392.0
>
> On by default =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A08 (20%) > Off by default =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 22 (55%)
> On by default in the GUI, off by default in bitcoind =A0 10 (25%)

I just voted as well and now - with some extra votes in the meantime = -
it's 9 / 22 / 13. So exactly 50/50 between off (22) and some form of on=
(9 + 13).

I'm in favor of turning it on by default in the GUI and leaving it off<= br> in bitcoind.

I don't like UPnP much, I find it exemplifies exactly what is wrong wit= h
computer security today: Convenience trumps security almost every time.

BUT: I don't think this is the moment to fight UPnP. It's the stand= ard
mechanism in use today to let a computer behind a NAT accept incoming
connections. The user has already made the decision in regards to
convenience over security. By enabling UPnP (or by buying a product that does this automatically) they are saying: I want it to "just work"= ;
instead of having fine-grained but more complicated control.

Bitcoin is a P2P application and as such should use this
mechanism. I think it's pretty clear that participating in a P2P networ= k
requires one to receive messages from other peers. At least no one seems to be concerned that Bitcoin (by default!) listens on port 8333. So I
think it's only logical to extend that to work behind NATs as well

If bitcoin listened on IPv6 that might help for alot of pe= ople. Windows 7 users get a teredo IPv6 address (unless they disable it) wh= en behind NAT on IPv4. Take any win7 box and put it on a typical NAT /DSL s= etup this is what happens. I think this might actually work for more users = than have UPNP support on their DSL gateways. teredo IPs aren't that st= able though (they change frequently) and they might tend to flood the addre= ss cache with stale addresses.

Rob
--bcaec5485fca5c256904a704c5d4--