Hub-node patch for bitcoind - windows version?

[rjk]

There is a patch for bitcoind that aggressively accumulates nodes to act as a hub relay. Is there a windows binary version of this available anywhere? There isn't much info on it that I can find. The current bitcoind is somewhat lackluster and gets 30-50 nodes, but it really ought to be able to gather hundreds or thousands.

Side note: The reason I want a windows version is because I have run out of IP addresses in my small range, and will therefore install this on an existing "server". If I had IPs to spare, I would simply run up a *nix VM on my XenServer cluster, but alas, I cannot.

[grue]

Code:

//static const int MAX_OUTBOUND_CONNECTIONS = 8;
static const int MAX_OUTBOUND_CONNECTIONS = 9000;

Code:

//else if (nInbound >= GetArg("-maxconnections", 125) - MAX_OUTBOUND_CONNECTIONS)
else if (nInbound >= GetArg("-maxconnections", 90000) - MAX_OUTBOUND_CONNECTIONS)

[gmaxwell]

There is a patch for bitcoind that aggressively accumulates nodes to act as a hub relay. Is there a windows binary version of this available anywhere? There isn't much info on it that I can find. The current bitcoind is somewhat lackluster and gets 30-50 nodes, but it really ought to be able to gather hundreds or thousands.

There is no particular reason you should need or expect more, really.  We don't currently have a shortage of available ports.

(and just because it wouldn't be clear to everyone: the 'patch' in the other reply here would result in memory corruption, and shouldn't be used)

[rjk]

There is a patch for bitcoind that aggressively accumulates nodes to act as a hub relay. Is there a windows binary version of this available anywhere? There isn't much info on it that I can find. The current bitcoind is somewhat lackluster and gets 30-50 nodes, but it really ought to be able to gather hundreds or thousands.

There is no particular reason you should need or expect more, really.  We don't currently have a shortage of available ports.

(and just because it wouldn't be clear to everyone: the 'patch' in the other reply here would result in memory corruption, and shouldn't be used)

When running a mining node, it is imperative that your blocks be sent out to the network to a large number of nodes in the shortest amount of time. This is needed to reduce the possibility that someone else could solve the same block first.

I was hoping I could make use of my decent internet connection to achieve this.

[btc_artist]

There is a patch for bitcoind that aggressively accumulates nodes to act as a hub relay.

Do you have a link to said patch?

[rjk]

There is a patch for bitcoind that aggressively accumulates nodes to act as a hub relay.

Do you have a link to said patch?

http://davids.webmaster.com/~davids/bitcoin-4diff-beta.txt
Based against 0.4.0.

EDIT: Link to Luke-jr's git repo with the patch committed here: http://luke.dashjr.org/programs/bitcoin/w/bitcoind/luke-jr.git/commitdiff/bf333ad04e4f1b82a9ff80bace5cdaa488654a30

[gmaxwell]

I would like to do the same. If you figure it out, maybe you could update this thread. I haven't had any luck with my occasional random searching.

This is really irrelevant for P2Pool because p2pool forwards blocks among the p2pool miners and has them all forward it in. This works really well because the p2pool forwarding is much faster than the bitcoin forwarding because it has to do less validation work.

Actually having large numbers of connection on the daemon you're mining from is a bad idea because servicing large numbers of mostly useless random windows users will slow down the daemon you need to be responding promptly to process blocks and mine.

In my P2pool operation I run four bitcoin daemons:  Two service p2pool nodes and only connect to my own nodes and a couple of carefully selected large miner daemons. One is a regular listening public node (with simply maxconnections=512, no crazy patches and it now has 489 connections), the other is a hidden unannounced node on secondary connectivity for dos resistance.

This is the sort of setup you want for reliable mining. Not some connection spammy patch.

[rjk]

This is really irrelevant for P2Pool because p2pool forwards blocks among the p2pool miners and has them all forward it in. This works really well because the p2pool forwarding is much faster than the bitcoin forwarding because it has to do less validation work.

OK that's good, I didn't realize that it did this.

Actually having large numbers of connection on the daemon you're mining from is a bad idea because servicing large numbers of mostly useless random windows users will slow down the daemon you need to be responding promptly to process blocks and mine.

But if I wish to run a real mining node (not p2pool), it seems that the best course of action then would be to run 2 bitcoind instances: 1 "hidden" on the mining server, and a (patched?) version somewhere else. Then, I would addnode the mining server instance, so that it maintains a reasonable number of connections, but still can forward blocks to the patched instance which can then spam the blocks out across the network.

[gmaxwell]

But if I wish to run a real mining node (not p2pool), it seems that the best course of action then would be to run 2 bitcoind instances: 1 "hidden" on the mining server, and a (patched?) version somewhere else. Then, I would addnode the mining server instance, so that it maintains a reasonable number of connections, but still can forward blocks to the patched instance which can then spam the blocks out across the network.

That would be my advice, yes.  (Well, my advice is to run p2pool!)

Also, you shouldn't need a patch— as mentioned if you up maxconnections a bit (don't go over 900 or so!)  and wait a while you should get a fairly large number of connections in a while.