public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <gmaxwell@gmail.com>
To: jan@uos.de
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] 0.3.24
Date: Fri, 1 Jul 2011 13:59:47 -0400	[thread overview]
Message-ID: <BANLkTin75ShqqPtv9hQ_ZJOrOQ7iGXrh8w@mail.gmail.com> (raw)
In-Reply-To: <20110701163558.GA7311@dax.lan.local>

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— 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— not quite as effective but I think enough that UPNP isn't a great
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> wrote:
> 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— 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.



  parent reply	other threads:[~2011-07-01 17:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-01  0:07 [Bitcoin-development] 0.3.24 Matt Corallo
2011-07-01  2:07 ` Gregory Maxwell
2011-07-01  2:44   ` Douglas Huff
2011-07-01 12:41   ` Douglas Huff
2011-07-01  8:00 ` Pieter Wuille
2011-07-01  8:39   ` Jeff Garzik
2011-07-01 12:31     ` Gavin Andresen
2011-07-01 12:40       ` Matt Corallo
2011-07-01 15:06         ` Gavin Andresen
2011-07-01 16:35           ` jan
2011-07-01 16:47             ` Robert McKay
2011-07-01 17:47             ` Douglas Huff
2011-07-01 17:50               ` Matt Corallo
2011-07-01 17:52                 ` Douglas Huff
2011-07-01 22:03                 ` Matt Corallo
2011-07-01 22:07                   ` Douglas Huff
2011-07-01 17:59             ` Gregory Maxwell [this message]
2011-07-01 23:42           ` Jeff Garzik
2011-07-02  0:37             ` Jeff Garzik
2011-07-02  0:46               ` Matt Corallo
2011-07-02  0:51                 ` Gregory Maxwell
2011-07-02  1:05                 ` Douglas Huff
2011-07-02  1:12                   ` Matt Corallo
2011-07-02  2:05                     ` Gavin Andresen
2011-07-02 21:07                       ` Jeff Garzik
2011-07-03  1:58                         ` Matt Corallo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BANLkTin75ShqqPtv9hQ_ZJOrOQ7iGXrh8w@mail.gmail.com \
    --to=gmaxwell@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=jan@uos.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox