3
I'm writing a Bitcoin web app that is to be deployed on an external server over which I have no control. I probably won't have access to standard Bitcoin port (8333). Will this cause a problem when connecting to standard Bitcoin clients, or can they handle communicating with a non-standard port number? Are there any Bitcoin-related applications that also use other ports to communicate (like a pool or the like)?
3
If you make only outbound connections it won't matter what ports you use. Your client will be able to fully participate in the network without any issues.
So, if my app can start a connection with another client stating that my address has port :80, it will receive response on port :80? – ThePiachu – 2011-10-07T22:31:35.690
When you connect to a client, you will receive responses on the connection you just made to that client. The Bitcoin network uses persistent TCP connections that remain active so long as both nodes continue running. – David Schwartz – 2011-10-07T22:33:47.170
Btw, I think you used an unnecessary "and". Can't edit your post, since I would need to change at least 6 characters ;). – ThePiachu – 2011-10-07T22:34:47.260
Thanks. I changed the structure of that sentence after writing it and didn't complete the change. – David Schwartz – 2011-10-07T22:36:12.003
1
Nodes on the network which are not running on the default ports (8333 for the main network, 18333 for testnet) will be avoided by the reference client in order to not cause disruption to other services. Otherwise should somebody advertise a fake node running on another applications port, other nodes in the network could cause a denial of service attack as they attempt to connect to it fruitlessly.
A code snippet from the Bitcoin Core client, showing that nodes will ignore non-standard ports unless they are very desperate to find somebody they can connect to:
// do not allow non-default ports, unless after 50 invalid addresses selected already
if (addr.GetPort() != Params().GetDefaultPort() && nTries < 50)
continue;
If you want to actively support the network with incoming connections you should not be changing the "port" setting of the bitcoin daemon if at all possible.
1Never knew this. But that's quite a limitation. Doesn't that make blocking Bitcoin traffic much easier? (if governments or so would want that) And how do I go about running multiple full nodes within one LAN, behind the same IP? (e.g. at my office building) – Madzi Konjo – 2014-10-28T05:41:24.567
It's trivial to block Bitcoin traffic anyway, so it's not a huge limit in any real sense. Other people can make networking layers that attempt to solve this, rather than being part of the core daemon. If you have multiple nodes behind one external IP, only have one listen and all the others connect to it. – foley – 2014-11-18T12:14:35.023
0
Beware that -addnode ignores -port setting
For example, both node1 and node2 have a -port=14444
node1> bitcoin-cli addnode node2 add
2018-08-11 02:07:04 connect() to node2:18444 failed after select(): Connection refused (111)
The fix is to include the port in the host name node1> bitcoin-cli addnode node2:14444 add
In what way(s) does the web app have to interact with the Bitcoin network? Will the Bitcoin client be running on the machine running the web app? – David Schwartz – 2011-10-07T21:44:19.000
I intend to write my own Bitcoin client for the web app, so I hope to be able to fully interact with the Bitcoin network. Alternatively, I might want to run just a pool in the web app. So, there is no problem with client customization as long as the network can also handle that. – ThePiachu – 2011-10-07T22:23:07.567