Author

Topic: inquiry about a spherical pool in vacuum - how many "bicoin nodes" does it need (Read 1669 times)

member
Activity: 112
Merit: 11
Hillariously voracious
are we seriously more paranoid an environment than torrenter / KAD crowd ?

Some of us, yes.  Bear in mind, we are dealing with real value here; the value of intellectual property is theoretical and not relevant to the torrentors themselves.

It seems to me that what matters  for a security model is not whether the "legitimate" participants ascribe value to their activities (all value being a matter of perception, in my very humble opinion), it's whether their opponents do, and given the existence of (technologically  sophisticated) agents interested disrupting filesharing networks, one would say that the analogy between torrent trackers and pools is not entirely off-base due to apparent existence of (relatively) technologically sophisticated  opponents who would find disrupting the respective services   to be a source of benefit (financial or otherwise)

Anyways, I find the fact that an apparently notable (though sadly unquantified) number of pool-ops are running on outgoing-only is verily interesting and worth keeping in mind.

legendary
Activity: 1708
Merit: 1010
are we seriously more paranoid an environment than torrenter / KAD crowd ?

Some of us, yes.  Bear in mind, we are dealing with real value here; the value of intellectual property is theoretical and not relevant to the torrentors themselves.
member
Activity: 112
Merit: 11
Hillariously voracious
But under that paradigm, pools, as long as they don't mod their software to increase the number of outgoing connections, are limited to 8 connections... Hm...
I don't think that any serious pool runs stock bitcoind anyway Smiley

That I   understand Smiley.

Still, the security paradigm of running on pure outgoing is kinda weird. I mean, I am aware of existence of TCP denial of service shenanigans, but for the love of everything good, are we seriously more paranoid an environment than torrenter / KAD crowd ?
hero member
Activity: 742
Merit: 500
But under that paradigm, pools, as long as they don't mod their software to increase the number of outgoing connections, are limited to 8 connections... Hm...
I don't think that any serious pool runs stock bitcoind anyway :)
member
Activity: 112
Merit: 11
Hillariously voracious
But under that paradigm, pools, as long as they don't mod their software to increase the number of outgoing connections, are limited to 8 connections... Hm...

Interesting stuff.
hero member
Activity: 737
Merit: 500
Also, disallowing incoming connections on a large miner strikes me as counterintuitive ...

My thought is that, given that most large pools have been targets of DoS or DDoS attacks at some point, they would want to minimize attack surface.  Not accepting incoming connections doesn't mean that you can't have connections.  It just means that you have to initiate them all, which is easy enough
member
Activity: 112
Merit: 11
Hillariously voracious

If you can't manually force persistent connections to the top mining pools (which you probably can't),

If you know the pool's ip address and they are accepting inbound connections.

Most of the large pools don't publish their bitcoind node ip addresses and I would expect they also don't accept inbound connections.

Well, I wonder if there is a coherent "pool security model" that demands this course of actions, or that is a case of "better safe than sorry" reasoning.

Also, disallowing incoming connections on a large miner strikes me as counterintuitive ...
hero member
Activity: 737
Merit: 500

If you can't manually force persistent connections to the top mining pools (which you probably can't),

If you know the pool's ip address and they are accepting inbound connections.

Most of the large pools don't publish their bitcoind node ip addresses and I would expect they also don't accept inbound connections.
legendary
Activity: 1708
Merit: 1010

If you can't manually force persistent connections to the top mining pools (which you probably can't),

You can try with the -connect flag.  If you know the pool's ip address and they are accepting inbound connections.
hero member
Activity: 737
Merit: 500
It really only matters how quickly the pool node can send and receive from the other top 6 pool nodes.  If they could connect directly to each other, then you only need 5 (you + the other top 6) to minimize invalid blocks.

If you can't manually force persistent connections to the top mining pools (which you probably can't), then you want many more connections so that you maximize the chances that you accidentally are connected to a node that is "close" to the other pools.  In an effort to increase your odds of being close or directly connected to a pool node, you could possibly patch bitcoind to prefer nodes "near" the IP address space of where you suspect pool nodes probably are.

But I suspect if you have too many connections, I'd imagine the cost of communicating with hundreds or thousands of nodes may hurt you enough to negate the value of being connected to many nodes.
member
Activity: 112
Merit: 11
Hillariously voracious
Hello!

Basically, the question is thus:

How many nodes (that is, connections from perspective of BTC network) does a nicely  sized (that is, member of top 6) BTC pool need, and approximately how does it scale ?

Hard numbers not required, just general range

Thanks.
Jump to: