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.

Bitcoin Core developer [PGP]Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.

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.

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.

Bitcoin Core developer [PGP]Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.

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).

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.

Bitcoin Core developer [PGP]Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.

a) is this information still current, or is there some more up-to-date thread i should be reading instead? (i notice there is an rpcport option in the example bitcoin.conf going around, but no 'port' option).

b) has this functionality made it into the default client, or i still need to find a patched version?

c) do i physically need 2 copies of the bitcoind bin? i'm not much of a linux guy but i tried to nohup the 2nd instance of bitcoind from the same physical program file and it doesn't appear to have launched the 2nd process.

d) i was going to ask how to just stop one instance and not both, but if you need 2 physical copies of bitcoind then a simple stop command would make sense.

Bitcoin Core developer [PGP]Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.

It doesn't matter which post you select, because at some point in time (around adding the addr messages ad removing IRC) the algo in the bitcoin core for selecting peers to connect to has been fucked up. And ever since then the bitcoin core node intentionally discards peers that are listening at non-default port.

I raised this issue once, but the answer was that it wasn't a bug, but a security feature.Great feature, BTW - it makes me feel so much more secured!

Anyway, if you setup you node to use a different port, you only get incoming connections from non bitcoin core nodes.Because the bitcoin code node is fucked up and nobody gives a shit about it.