Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.175 as permitted sender)
	client-ip=209.85.216.175; envelope-from=gmaxwell@gmail.com;
	helo=mail-qy0-f175.google.com; 
MIME-Version: 1.0
In-Reply-To: <20110701163558.GA7311@dax.lan.local>
References: <1309478838.3689.25.camel@Desktop666>
	<20110701080042.GA657@ulyssis.org>
	<BANLkTim-QWvtfL65mo3uW7ESiehKOmHjtw@mail.gmail.com>
	<BANLkTi=DWUhGmoHcQB5EPZHF71JE71gcTg@mail.gmail.com>
	<1309524016.2541.0.camel@Desktop666>
	<BANLkTimobc7471uBMLBecYT3vz0GO6RLzQ@mail.gmail.com>
	<20110701163558.GA7311@dax.lan.local>
Date: Fri, 1 Jul 2011 13:59:47 -0400
Message-ID: <BANLkTin75ShqqPtv9hQ_ZJOrOQ7iGXrh8w@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: jan@uos.de
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] 0.3.24
Precedence: list

On Fri, Jul 1, 2011 at 12:35 PM,  <jan@uos.de> wrote:
> 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.
[snip]

I also don't like upnp, but I strongly support it being on because
leaving it off is not really an alternative.

IMO a forum poll is the wrong tool to use to decide if bitcoin keeps
working or not. ;) If the alternative were upnp vs some other way to
reasonably increase the number of listeners... e.g. "upnp always vs
upnp only if there has been no inbound connections in X minutes" that
would be another matter.

The bitcoin/bitcoind difference seems confusing to me, since when
someone complains about connectivity I'll have to remember to ask
which they are using... but enabling it for the gui is probably
sufficient in terms of network health.

But it'll probably happen anyways: I imagine most bitcoind users build
locally and don't bother installing the upnp library. I know I don't.

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

Yea, listening at all is more interesting than upnp=E2=80=94 though almost =
any
harm that listening can cause can also be caused by outgoing
connections since the protocol is symmetric.

(e.g. if you have an exploit, you don't need to connect to people, you
can just sibyl attack the network and exploit people who connect to
you=E2=80=94 not quite as effective but I think enough that UPNP isn't a gr=
eat
additional risk)

If you want to talk about worrying people about security:  The IRC
connections seriously set off alarm bells, especially when someone
looks and sees something indistinguishable from a botnet in IRC.  It's
been blocked by major ISP multiple times. So, until we get IRC
disabled nothing else is really all that significant from a security
hebe-geebies perspective.

On Fri, Jul 1, 2011 at 1:50 PM, Matt Corallo <bitcoin-list@bluematt.me> wro=
te:
> Totally agree it really shouldnt be a vote, in the end UPnP is bad for
> an individual (more bandwidth usage, etc), but good for the network.
> That means people will vote against it, but in the end someone has to
> make the tough decision and turn it on.

Well, users who don't like it can still disable listening=E2=80=94 which is
healthier for the network right now than leaving listening on but not
actually working.

We can fix the incentive structure somewhat: We should give preference
in the form of preferred forwarding from/to to nodes that we've
connected to vs connected to us, potentially improved relay rules. Not
only does this given an incentives to listen (faster txn processing,
hearing about blocks earlier) but it also would reduce the
effectiveness of some DOS attacks.   Not something for 0.3.24,
however.