Pages:
Author

Topic: [PULL] UPnP - page 2. (Read 5054 times)

sr. member
Activity: 406
Merit: 257
March 12, 2011, 05:40:29 AM
#9
One more consideration.

Can someone guarantee that there is not a single buffer overflow or some other vulnerability in bitcoin code present and future? And put a 21m BTC bond to make such guarantee worthwhile too? If not than we'd better have this off by default.

Otherwise, consider the risk of a 0 day exploit coming up and someone cleaning up balances of all nodes accepting incoming connections. This would be the end of bitcoin.

Without UPnP by default only supernodes would get robbed and they should know better than keep any decent money anywhere near node accepting connections. This still would be nasty but not fatal.

There is simply no argument against this risk assessment. Case closed.


P.S. vote whatever you want 'upnp on' decision will be vetoed either by Gavin or by Satoshi himsef. So do not rush selling all your BTC's just yet.

In a remote buffer overflow scenario all nodes participating in the normal p2p network are pretty much fucked, no matter if they accept incoming connections or not.

Consider the following scenario:
Attacker exploits bug and disables all public nodes allowing incoming connections.
Nodes *not* allowing incoming connections see their outgoing connections count dropping and try to connect to new peers.
Only nodes left accepting incoming connections are under control of the attacker and exploit same bug in nodes connecting to them.
Whoops.
legendary
Activity: 1652
Merit: 2216
Chief Scientist
March 11, 2011, 11:21:44 PM
#8
It seems reasonable to me to start with UPnP disabled by default.  As long as enabling it in the client is easy enough to do, the network will benefit because some nodes will "opt-in" that wouldn't have before.  We can change the default later, after we gain more confidence about remote vulnerabilities.

Who knows enough about wxWidgets to add a checkbox to the Settings UI for "Enable UpNP" (grayed out #ifndef UPNP...)?  Wanna coordinate with BlueMatt to get that done?
vip
Activity: 447
Merit: 258
March 11, 2011, 10:02:48 PM
#7
It seems reasonable to me to start with UPnP disabled by default.  As long as enabling it in the client is easy enough to do, the network will benefit because some nodes will "opt-in" that wouldn't have before.  We can change the default later, after we gain more confidence about remote vulnerabilities.
legendary
Activity: 2576
Merit: 1186
March 11, 2011, 09:59:10 PM
#6
Learn from FreeBSD and other decent OS. Stuff is off by default. Stuff opening ports to world wild web is definitely off by default.
Erm, no. Services may be disabled by default, certainly, but once you start (for example) Apache, it listens to port 80 by default. You don't have to jump through extra hoops to configure a port. Likewise, distros won't auto-launch bitcoind by default, but when the user does so, they should reasonably expect it to listen.

An unfounded possible vulnerability is no excuse to make things harder for the user than they have to be. There could just as well be a vulnerability in the transaction code, or anywhere else that is going to be exposed to all nodes regardless. If you don't trust the bitcoin wallet you're using to be secure, you shouldn't be using it period.
administrator
Activity: 5166
Merit: 12850
March 11, 2011, 09:26:41 PM
#5
I completely disagree.  The more nodes which are connectible the harder any kind of Sybil attack becomes which just benefits the network.  Any user who has a legitimate reason why they don't want incoming connections will already either have UPnP off on their router or be able to disable it in the client.

Think of all those users in Canada and Australia who will have their limited bandwidth siphoned away without any warning...

After Bitcoin runs in lightweight client mode by default, it would make sense to ask the user about triggering UPnP if they enable "supernode" mode.
hero member
Activity: 755
Merit: 515
March 11, 2011, 09:23:13 PM
#4
It should not be enabled by default. Opening 8333 significantly increases network usage without any benefit to the node.
I completely disagree.  The more nodes which are connectible the harder any kind of Sybil attack becomes which just benefits the network.  Any user who has a legitimate reason why they don't want incoming connections will already either have UPnP off on their router or be able to disable it in the client.
legendary
Activity: 1596
Merit: 1091
March 11, 2011, 09:19:48 PM
#3
It should not be enabled by default. Opening 8333 significantly increases network usage without any benefit to the node.

Well, it benefits the network, which benefits the node.

But I agree:  it should be off by default.

administrator
Activity: 5166
Merit: 12850
March 11, 2011, 09:08:43 PM
#2
It should not be enabled by default. Opening 8333 significantly increases network usage without any benefit to the node.
hero member
Activity: 755
Merit: 515
March 11, 2011, 09:05:49 PM
#1
I wrote a patch for UPnP via miniupnpc.  Currently it is just for UNIX, but shouldn't be too hard to get running on OSX.  Some people have mentioned that Windows has its own native library for UPnP which we should use.  Currently UPnP is on off by default and can be easily turned on with -upnp but that is up for debate (actually poll).  See the pull request here: https://github.com/bitcoin/bitcoin/pull/133.

UPDATE: The patch now works for OSX and Windows and includes a WXUI switch for enabling/disabling UPnP at runtime.  Note that the windows version still uses miniupnpc (not the native windows libraries, does anyone feel very strongly about this?).  
As I couldn't get miniupnpc to compile on Windows, the makefile is designed to use the binary version published on the website (which includes the library against which bitcoin is linked, upnpc-exe-win32-20110215.zip).  To get the relevant headers, however you need to download the original source archive (miniupnpc-1.5.20110215.tar.gz) and copy *.h to C:\upnpc-exe-win32-20110215\miniupnpc.  Note that the UNIX/OSX versions expect version 1.5 (slightly different UPNP_AddPortMapping definition).  
Also, the translations of the copyright notice in the about dialog need changed before this should be pulled.  Currently only dutch has been translated (thanks joepie91).

UPDATE 2: Added translations by community members for French, Spanish and German (plus existing Dutch) and added Russian, Portuguese and Italian translations from Google Translate.  Anyone had time to review the code and have suggestions or think it is ready?

UPDATE 3: Italian translation updated thanks to Joozero.  Anyone have comments on the code?
Pages:
Jump to: