I just read in the IRC channel that there is up to one outgoing connection per /16.
https://en.bitcoin.it/wiki/Weaknesses#Cancer_nodes
If that is true, supporting alternate ports won't open Bitcoin up for any more sybil attacks than we have now. You can have 65535 bitcoin instances running on your system, but it will ignore all of them but one.
Topic: Running on a port other than 8333 - page 2. (Read 26218 times)
Well even now with IPv4 there are people with a shitload of IPs (for example botnet owners or ISPs), and that will only get worse. If bitcoin somehow relies on IPs being scarce, this is a pretty big (potential) hole in security.
Yea, the networking code is one of those things that no one has really touched since satoshi...though I don't think either port nor IPs can exploit bitcoin for sybil but I just don't know what kind of numbers would actually be required to pull it off (though it does get much, much easier with IPv6). Yea, pretty much, though for IPv6 if you just take a /64 as a single address and ignore anything else from that /64 as a duplicate it might be ok. Then again, so many of use have /48's from HE so...yea it needs to be thought out.
Well even now with IPv4 there are people with a shitload of IPs (for example botnet owners or ISPs), and that will only get worse. If bitcoin somehow relies on IPs being scarce, this is a pretty big (potential) hole in security.OK. That sounds pretty serious. These issues will have to be addressed for IPv6 as well, then.
Yea, pretty much, though for IPv6 if you just take a /64 as a single address and ignore anything else from that /64 as a duplicate it might be ok. Then again, so many of use have /48's from HE so...yea it needs to be thought out. My concerns are more along the lines of potential for DDoSing the network if you have infinite nodes (well 65000 per IP) and sybil attacks. But those are mostly because I haven't read enough of the networking code to realize all the possibilities (nor do I think anyone really has). If you spend enough time reading up on net.cpp and can convince people that those aren't a problem, then I'm sure it would get merged.
OK. That sounds pretty serious. These issues will have to be addressed for IPv6 as well, then. Can you explain which concerns, and why they cannot be addressed? Why would using another port than 8333 be less secure?
I'd say using a fixed port has security/networking problems of its own.
My concerns are more along the lines of potential for DDoSing the network if you have infinite nodes (well 65000 per IP) and sybil attacks. But those are mostly because I haven't read enough of the networking code to realize all the possibilities (nor do I think anyone really has). If you spend enough time reading up on net.cpp and can convince people that those aren't a problem, then I'm sure it would get merged. I'd say using a fixed port has security/networking problems of its own.
But yea, it will probably never be added due to various security/networking concerns about the results of it. I agree, its a cool idea to add in theory, but there are too many concerns about it and in financial software, thats just unacceptable.
Can you explain which concerns, and why they cannot be addressed? Why would using another port than 8333 be less secure?I'd say using a fixed port has security/networking problems of its own.
The only potential issue I could find in this topic is this one:
Quote
Satoshi pointed out that allowing bitcoin/bitcoind to run on a non-standard port could be dangerous, because if misconfigured two bitcoins might both open and write to the same database.
This could be addressed by storing the port number in a configuration file in the same directory as the database (or even *in* the database). One database will only open on one port, effectively protecting it.Or use some other scheme to make sure only one bitcoin is running on a database at the same time, such as a lock file. This would be even better, as it doesn't depend on TCP rejecting the second bind to the same port
Am I correct that there is currently no way to change from port 8333 and that this will possibly never be a feature ?
Technically, no. You can change the default port now and it would theoretically work, just very, very poorly. But yea, it will probably never be added due to various security/networking concerns about the results of it. I agree, its a cool idea to add in theory, but there are too many concerns about it and in financial software, thats just unacceptable.
Am I correct that there is currently no way to change from port 8333 and that this will possibly never be a feature ?
I don't know but arbitrary port selection should be a feature. imagine if a government outlawed bitcoin usage and forced all their isp's to block port 8333.
Am I correct that there is currently no way to change from port 8333 and that this will possibly never be a feature ?
I am behind a firewall, in which I can open some ports, but not 8333.
Will this function be there in some future versions?
Due to various security/network concerns it will probably never be merged into the mainline Bitcoin version. You can run a patched bitcoin with -port, but you still won't get incoming connections due to the way clients chose peers to connect to. You don't strictly need to be able to accept incoming connections for bitcoin to work, it just helps the network if you do, but even if the portoption branch was merged you would still have to be able to make outgoing connections on port 8333. Will this function be there in some future versions?
I am behind a firewall, in which I can open some ports, but not 8333.
Will this function be there in some future versions?
Will this function be there in some future versions?
You'll need to be running the latest source code from github for the nolisten option.
I'm running the windows binary from bitcoin.org and am not comfortable compiling my own wallet. 
Is there a timeframe when the nolisten option will be included in the windows binary?I tried with the current windows version and it does not work. (Either one of the wallets start, second instance grows to 6mb ram usage and then dies before showing the gui) I think this has to do with the listen port of the second instance conflicting with the first?
Run one instance normally. It'll listen for incoming bitcoin network connections on port 8333, rpc connections on port 8332, and connect to other nodes.
Run the other instance with a different -datadir, and a bitcoin.conf like this:
nolisten=1
rpcport=7332 (or whatever you like)
noirc=1
connect=127.0.0.1:8333
You'll need to be running the latest source code from github for the nolisten option.
The noirc and connect settings aren't strictly necessary; leave them out and the second instance will make 8 outgoing connections to other bitcoin nodes. You'll save a little network bandwidth if the nolisten instance only connects to the other node.
Run the other instance with a different -datadir, and a bitcoin.conf like this:
nolisten=1
rpcport=7332 (or whatever you like)
noirc=1
connect=127.0.0.1:8333
You'll need to be running the latest source code from github for the nolisten option.
The noirc and connect settings aren't strictly necessary; leave them out and the second instance will make 8 outgoing connections to other bitcoin nodes. You'll save a little network bandwidth if the nolisten instance only connects to the other node.
both have a different rcport specified in the config (8332 and 8333)
8333 is the hardcoded P2P port.
So I just need to select a different port then? I am confused here because I configured one instance as:
rpcport=8333
rpcconnect=127.0.0.1:8333
and I configured the other instance as:
rpcport=8332
rpcconnect=127.0.0.1:8332
This solution seems to work fine but not when I run both at the same time. (i.e. either one wallet OR the other wallet) I am obviously doing something wrong here but can't figured out what. I trolled through most of the forum posts to look for an answer.
-=-=-=- DOUBLE TROUBLE =-=-=-=-
http://doubletrouble.bitcoinbet.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
both have a different rcport specified in the config (8332 and 8333)
8333 is the hardcoded P2P port.
I've been working on adding -port= / -rpcport= command line / config file options to bitcoin. The idea is to let you run multiple copies of bitcoind on one machine; I need this because I'm planning on having at least two Bitcoin-related web services (the Bitcoin Faucet and a service to be named later), I want them to have completely separate wallets, but I don't want to rent multiple servers to host them.
Same here. I have managed to create 2 wallets and two instances of a bitcoin.conf.
both have a different rcport specified in the config (8332 and 8333)
I can start either one of them and it works fine, the web sites using the wallet can connect.
However.... If I start the second bitcoin instance (I'm on windows) the second process grows to about 6 Mb and then just dies.... So each of them wallets runs just fine alone but not together.
Is there any way I can debug to see what happened? I tried switching on options in the config (like noirc and the connect only to...) but it does not seem to make a difference.
Kind regards,
MoneyTree
http://doubletrouble.bitcoinbet.com/
Is there a way to open BerkeleyDB exclusive?
What is your intended goal?
If it is to prevent two bitcoin clients from actively using the same database, you'll need to employ application-level protection. Crude methods of this include a lockfile or "lock" database entry.
If the intention is to prevent all other access, I'd suggest giving up on that goal
It is highly useful to permit db4 tools to access db4 databases:Code:
db46_archive db46_deadlock db46_load db46_stat
db46_checkpoint db46_dump db46_printlog db46_upgrade
db46_codegen db46_hotbackup db46_recover db46_verify
db46_checkpoint db46_dump db46_printlog db46_upgrade
db46_codegen db46_hotbackup db46_recover db46_verify
and just as useful to permit read-only accesses by tools such as gavin's bitcointools.
DB_PRIVATE is the worst of both worlds. DB_PRIVATE is not exclusive, but it does make it get screwed up if another process tries to access it at the same time.
I've dropped the DB_PRIVATE flag in rev 153.
Do you have an updated version of this patch for SVN revision 125? Also, does Bitcoin open the BerkeleyDB as exclusive, precluding the need for a file lock?It does not -- did my own tests.
It does open with DB_PRIVATE.
http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/C/envopen.html
Jump to: