Significance of port 8333?

[Andreas Schildbach]

I have Bitcoin (GUI version) running (and mining) on two machines, but can obviously only forward port 8333 to one of those.

What implications does this have for the machine without incoming connections?

Will it be able to "find" coins while mining?

Will it be able to receive coins by transactions (more precisely: will received coins be displayed without my intervention)?

Both clients are at the top of the block chain and have connections displayed in the status bar.

Will the answers be any different for "bitcoind"?

Best regards,

Andreas

[Gavin Andresen]

I have Bitcoin (GUI version) running (and mining) on two machines, but can obviously only forward port 8333 to one of those.
What implications does this have for the machine without incoming connections?

It will have only 8 (outgoing) connections.

With fewer connections, it will notice new blocks a tiny bit more slowly than the other machine, and blocks it finds will propagate to the rest of the network slightly more slowly than the other machine.  So it will spend a teeny-tiny bit more time working on an out-of-date block chain, and will be a teeny-tiny bit more likely to lose "announce a new block" races.  But I bet the effects are so small you'd never notice them.

Will it be able to "find" coins while mining?
Will it be able to receive coins by transactions (more precisely: will received coins be displayed without my intervention)?
Will the answers be any different for "bitcoind"?

Yes and yes and no.

[SmokeTooMuch]

Will it be able to receive coins by transactions (more precisely: will received coins be displayed without my intervention)?

yes

afaik only when "non-ip"-transactions are made (using bitcoin addresses).
if you send money to a specific ip, the client which the port is forwarded to will receive the coins.
(IP-payments are disabled by default (and will be removed in future versions afaik), so this isn't a big concern)

[bfever]

It will have only 8 (outgoing) connections.

With fewer connections, it will notice new blocks a tiny bit more slowly than the other machine, and blocks it finds will propagate to the rest of the network slightly more slowly than the other machine.  So it will spend a teeny-tiny bit more time working on an out-of-date block chain, and will be a teeny-tiny bit more likely to lose "announce a new block" races.  But I bet the effects are so small you'd never notice them.

Can't you eliminate this effect by starting Bitcoin on the second machine (not getting the port forwarding requests) with the -addnode=<ip of other machine> parameter ?
In that way, this second machine will have 7 connections to the outside world and 1 to the other machine probably being connected to a lot of more nodes.
I think even using the -connect=<ip of other machine> on the second machine is enough as the connection between the two machines is probably 1000x faster and less laggy then the internet connection to other nodes.

[Flow]

I have Bitcoin (GUI version) running (and mining) on two machines, but can obviously only forward port 8333 to one of those.

Is it not possible to forward two ports for bitcoin? E.g. 8333 and 8334 and announce this ports in the distributed database, like bittorrent does?

Flow

[theymos]

Is it not possible to forward two ports for bitcoin? E.g. 8333 and 8334 and announce this ports in the distributed database, like bittorrent does?

No. You could modify the source to use a different port, but "stock" Bitcoin greatly prefers to connect to peers on port 8333, so it wouldn't do any good.

[MoonShadow]

Couldn't you just force the second one to connect to the other via localhost, and benefit from the first one's connections?

[carp]

Is it not possible to forward two ports for bitcoin? E.g. 8333 and 8334 and announce this ports in the distributed database, like bittorrent does?

No. You could modify the source to use a different port, but "stock" Bitcoin greatly prefers to connect to peers on port 8333, so it wouldn't do any good.

of course, I was thinking about why this is a bad thing, all that I can come up with was to draw parallels to how tor is built.... able to specify bridge nodes, and specific IPs that you are allowed to talk on... and SSL options even chosen to try and minimize the detectability of what is going on.

Though, since bitcoin can use a tor proxy, it gets all those features. How well would it work to use a tor location hidden service as your available IP? If the client just forwards everything through the proxy, letting it do DNS lookups, then it would mean that you just wont resolve for any clients not using a tor proxy, but it should be transparent for anyone doing it.

Of course, if nodes are only advertised by IP (havn't looked at that, might have to soon) that wont work.

[theymos]

Though, since bitcoin can use a tor proxy, it gets all those features. How well would it work to use a tor location hidden service as your available IP? If the client just forwards everything through the proxy, letting it do DNS lookups, then it would mean that you just wont resolve for any clients not using a tor proxy, but it should be transparent for anyone doing it.

Bitcoin doesn't handle hostnames. You need to use Tor's MapAddress to use a hidden service (explicitly with -addnode), though this does work.