From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Qci0P-0004QL-OW for bitcoin-development@lists.sourceforge.net; Fri, 01 Jul 2011 17:59:53 +0000 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; Received: from mail-qy0-f175.google.com ([209.85.216.175]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Qci0O-00043b-LG for bitcoin-development@lists.sourceforge.net; Fri, 01 Jul 2011 17:59:53 +0000 Received: by qyk30 with SMTP id 30so82179qyk.13 for ; Fri, 01 Jul 2011 10:59:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.98.20 with SMTP id o20mr2690512qcn.216.1309543187188; Fri, 01 Jul 2011 10:59:47 -0700 (PDT) Received: by 10.229.2.194 with HTTP; Fri, 1 Jul 2011 10:59:47 -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 13:59:47 -0400 Message-ID: From: Gregory Maxwell To: jan@uos.de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 (gmaxwell[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: 1Qci0O-00043b-LG 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 17:59:53 -0000 On Fri, Jul 1, 2011 at 12:35 PM, 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 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.