summaryrefslogtreecommitdiff
path: root/99/635679b83a146aa680c20ac0fa15fe1b689c90
blob: 26525dd175f61a2c56249a98a49fe165c64aa7e4 (plain)
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
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
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 <rmckay@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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>
	<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 17:47:19 +0100
X-Google-Sender-Auth: LSz0W37T7P2d9i4aXtJu9PnQsVI
Message-ID: <BANLkTimuNvsk_O2c6V03L9T=dgTVXbkpLg@mail.gmail.com>
From: Robert McKay <robert@mckay.com>
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: <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 16:47:26 -0000

--bcaec5485fca5c256904a704c5d4
Content-Type: text/plain; charset=ISO-8859-1

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

<div class=3D"gmail_quote">On Fri, Jul 1, 2011 at 5:35 PM,  <span dir=3D"lt=
r">&lt;<a href=3D"mailto:jan@uos.de">jan@uos.de</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex;">
<div class=3D"im">On Fri, Jul 01, 2011 at 11:06:56AM -0400, Gavin Andresen =
wrote:<br>
&gt; &gt; Not sure about OS differentiation, seems...wrong? =A0Maybe disabl=
ed by<br>
&gt; &gt; default on bitcoind but on by default on bitcoin?<br>
&gt;<br>
&gt; OK. =A0I mis-remembered the poll:<br>
&gt; =A0 =A0<a href=3D"http://forum.bitcoin.org/index.php?topic=3D4392.0" t=
arget=3D"_blank">http://forum.bitcoin.org/index.php?topic=3D4392.0</a><br>
&gt;<br>
&gt; On by default =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A08 (20%)<b=
r>
&gt; Off by default =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 22 (55%)<br>
&gt; On by default in the GUI, off by default in bitcoind =A0 10 (25%)<br>
<br>
</div>I just voted as well and now - with some extra votes in the meantime =
-<br>
it&#39;s 9 / 22 / 13. So exactly 50/50 between off (22) and some form of on=
<br>
(9 + 13).<br>
<br>
I&#39;m in favor of turning it on by default in the GUI and leaving it off<=
br>
in bitcoind.<br>
<br>
I don&#39;t like UPnP much, I find it exemplifies exactly what is wrong wit=
h<br>
computer security today: Convenience trumps security almost every time.<br>
<br>
BUT: I don&#39;t think this is the moment to fight UPnP. It&#39;s the stand=
ard<br>
mechanism in use today to let a computer behind a NAT accept incoming<br>
connections. The user has already made the decision in regards to<br>
convenience over security. By enabling UPnP (or by buying a product that<br=
>
does this automatically) they are saying: I want it to &quot;just work&quot=
;<br>
instead of having fine-grained but more complicated control.<br>
<br>
Bitcoin is a P2P application and as such should use this<br>
mechanism. I think it&#39;s pretty clear that participating in a P2P networ=
k<br>
requires one to receive messages from other peers. At least no one seems<br=
>
to be concerned that Bitcoin (by default!) listens on port 8333. So I<br>
think it&#39;s only logical to extend that to work behind NATs as well</blo=
ckquote><div><br>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&#39;t that st=
able though (they change frequently) and they might tend to flood the addre=
ss cache with stale addresses.<br>
<br>Rob<br></div></div>

--bcaec5485fca5c256904a704c5d4--