1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
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 <gmaxwell@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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>
<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
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2011 17:59:53 -0000
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.
|
