[SOLO] Docker-based Bitcoin Full Node Mining Stack (Bitcoind + CKSolo + CKStats)

[MagicDude4Eva]

Just wanted to share a little project I’ve been working on over the past weeks. I’ve put together a full solo-mining stack built around Docker that runs well even on fairly modest hardware (in my case: a Synology DS1019+ with NVMe).

The goal: Run everything locally and hook it up to a NerdQaxe (or similar) for solo mining without relying on external services.

Included components:

• Bitcoin Core (bitcoind) – Full node
• CKPool Solo – with CKStats web UI
• Fulcrum – Electrum-compatible indexer (optional)
• Bitcoin RPC Explorer – simple web interface for Core
• InfluxDB + Grafana – real-time mining dashboard
• Mempool.space frontend – also working, but mostly just for fun

⚠️ Heads up: Fulcrum sync takes a long time, especially the first time. On my Synology DS1019+ with NVMe, it still took over a week. Stopping it midway will probably corrupt the index and you'll have to start over.

It’s all Dockerized, fairly easy to set up, and uses environment variables to wire everything together. The setup.sh script handles the permissions, clones the repo, sets up configs, etc. It’s opinionated, yes, but works pretty well out of the box.

🔗 GitHub: https://github.com/magicdude4eva/btc-fullnode-stack

If you try it out, let me know how it goes or if you run into issues. This is still experimental, but it’s been running stable here for over a week now.

[mikeywith]

without relying on external services.

You do realize that it's safer to rely on a stable external service than to run your own when it comes to mining? And by safer I am talking about your ability to actually win a block.

People often talk about bitcoin mining as if it's a race, which isn't entirely true. in reality, up to the point of when you find a valid hash, you are not racing against anyone, and your chances of hitting a block are independent from other miners hitting a block; however, once you do hit a block, the race starts. You need to make sure you propagate the block in a fraction of a second, mainly to other miners' nodes to let them know that you have already solved a block and that they need to start working on the next one. Other than that, it's possible that your block will be orphaned by another miner that has better connectivity to other nodes.

Add to it all the technical issues that your infrastructure can run into, like a small delay in downloading new blocks and clearning your mempool, and your getblocktemplate creates an invalid block. It takes a few components working together to ensure that your final constructed block is valid and propagated well and fast. everything must have 99.99% uptime, or else you are adding more risk for potentially no reward. You can't meaningfully have well-set-up mining infrastructure at home where your cat or kid may unplug the router power cable.

With that said, I do encourage everyone to test local mining for fun and educational purposes -- it's interesting to say the least, so good work you did there.

[MagicDude4Eva]

You do realize that it's safer to rely on a stable external service than to run your own when it comes to mining? And by safer I am talking about your ability to actually win a block.

Thanks for the feedback, you are absolutely right about the propagation and infrastructure risks. With the very-very-very slim chance of hitting a block in lottery mining, having it orphaned because the cat decided to nap in the warm air behind my rack and unplugging the fibre-link would be a true disaster. 😅

Your points are exactly the kind of things people should consider before going the self-hosted route. For me, it is part hobby, part infrastructure-geeking, and part dream of defying the odds.

That said, I have put some thought into stability: I run everything in a full-sized rack with a UPS, UniFi gear, PV + backup battery, fibre uplinks, and LTE failover. Running everything off NVMe with plenty of RAM has kept speeds and latency in a very comfortable range and I am genuinely happy with how stable it's been so far.

I do think that my Synology DS1019+ deserves an upgrade, but I do notice that the bitcoin-node publishes via ZMQ updates rather quick. I can not speak for the quality of work the miner produces and ckpool handles, but in the 2 days run-time the miner did 507M shares (3M rejection) and has an average hashrate of 4.3TH/s (it is a NerdQaxe++).

[BitcoinSoloMiner]

did you try getting some testnet coins? maybe add that as another thing?

i like the work you have done on the github page. a small section or fork where it runs the testnet would be good, and what about other sha256 coins, have you worked the same implementation but on a different lower difficulty alt-coin? this could be a way to check how 'safe' (as mikey says) this project is.

this is good work, there are lots of bitaxes and similar lower hash devices out there, it would be better if most of them have everything running local. with all exchanges now requiring ID, we need to keep the decentralisation (mining, nodes AND wallets) going.

[MagicDude4Eva]

did you try getting some testnet coins? maybe add that as another thing?

i like the work you have done on the github page. a small section or fork where it runs the testnet would be good, and what about other sha256 coins, have you worked the same implementation but on a different lower difficulty alt-coin? this could be a way to check how 'safe' (as mikey says) this project is.

this is good work, there are lots of bitaxes and similar lower hash devices out there, it would be better if most of them have everything running local. with all exchanges now requiring ID, we need to keep the decentralisation (mining, nodes AND wallets) going.

I have not yet spend any time on testnets or other sha256 coins. I am waiting for another bitaxe to mess around with this on separate containers.

[Nexus9090]

without relying on external services.

You do realize that it's safer to rely on a stable external service than to run your own when it comes to mining? And by safer I am talking about your ability to actually win a block.

People often talk about bitcoin mining as if it's a race, which isn't entirely true. in reality, up to the point of when you find a valid hash, you are not racing against anyone, and your chances of hitting a block are independent from other miners hitting a block; however, once you do hit a block, the race starts. You need to make sure you propagate the block in a fraction of a second, mainly to other miners' nodes to let them know that you have already solved a block and that they need to start working on the next one. Other than that, it's possible that your block will be orphaned by another miner that has better connectivity to other nodes.

Add to it all the technical issues that your infrastructure can run into, like a small delay in downloading new blocks and clearning your mempool, and your getblocktemplate creates an invalid block. It takes a few components working together to ensure that your final constructed block is valid and propagated well and fast. everything must have 99.99% uptime, or else you are adding more risk for potentially no reward. You can't meaningfully have well-set-up mining infrastructure at home where your cat or kid may unplug the router power cable.

With that said, I do encourage everyone to test local mining for fun and educational purposes -- it's interesting to say the least, so good work you did there.

I've heard this argument on a few occasions and technically it really doesn't hold water.

Mining solo to a local solo pool attached to bitcoin core has the same network delays as any other bitcoin node on the network since it is a Peer to Peer network.

Bitcoin is a P2P (peer to peer) network, Bitcoin-core selects the incoming and outgoing peers/nodes that it communicates with (you dont get a choice in that), this is true of every node on the planet, the execption being where Bitcoin-core nodes have been programmed to talk directly to another node without going through the selection process. for example where someone is running multiple bitcoin core nodes on the same network, but that doesn't offer any real advantage in propagation to the rest of the network.

Mining takes place by the miner requesting a block over the Stratum protocol to the local Stratum pool host, which in turn transforms and forwards the request as a GetBlockTemplate request to the local Bitcoin-core node, when a share is found the work is passed from the miner to Bitcoin-core in the same manner over the Stratum protocol, the work done is then propagated to the network over P2P by Bitcoin-core.

It doesn't matter if you have a Bitcoin-core node in a datacenter or in a garden shed, as long as it has a good network connection and I don't mean using WiFi, GSM or some other mobile comms, I'm talking wired ethernet to you local broad-band router/gateway, then the network infrastructure the data has to traverse between P2P peers is the same irrespective of the location.

It still has to go over internet routers, switches and gateways located between nodes.

So I don't agree at all that having a bitcoin-core node in a datacenter is any better than running one on you local home network, provided said network has reasonable bandwidth.

I think its a fallacy cooked up by pool operators.

[MagicDude4Eva]

So I don't agree at all that having a bitcoin-core node in a datacenter is any better than running one on you local home network, provided said network has reasonable bandwidth.

I think its a fallacy cooked up by pool operators.

I do agree with you and once my local setup has mined a BTC I will happily prove pool operators wrong :-)

[mikeywith]

I've heard this argument on a few occasions and technically it really doesn't hold water.

Mining solo to a local solo pool attached to bitcoin core has the same network delays as any other bitcoin node

This is obviously false. A local node running on a $30 router and $50 internet connection has nothing close to the same network delays as a pool node hosted in a specialized data center. Nodes in well-connected data centers have a much better chance of landing in more favorable peer topologies due to their uptime, reliability, and often higher bandwidth capabilities. Your node talks to a few peers, but the speed at which those peers then distribute your block to their peers and how many connections your node has -- creates a propagation tree. Your local node’s block will propagate slower globally compared to other nodes with single-digit millisecond latency to other mining nodes.

Also, pools use dedicated interconnections and relay networks (like FIBRE or Falcon), plus geographically distributed nodes. For example, FIBRE can announce the block header to peers (a few KBs) even before the full block is propagated. This tells other miners to start mining the next block on top of this one, so all major pools are already mining on top of that new block while your node is still mining on top of the previous block. The time it takes for the slow peer-to-peer network to globally propagate that block to your node is huge (5–15 seconds in some cases even more) compared to the sub-1-second UDP-based relay technology those pools use.

By the way, I encourage you to read studies such as "Effects of a Simple Relay Network on the Bitcoin Network," and I will quote a part of the abstract for you:

Results show that the propagation time decreases to approximately 77% of the original value if the utilization rate is set to 3%. This rate is close to the actual utilization rate of relay network "Falcon". We also found that the probability of blocks created by utilizing nodes to become orphan blocks is surprisingly smaller than that of the non-utilizing nodes. Even in the worst case, the value of utilizing nodes is 15% of the value of non-utilizing nodes.

You can also read "Bitcoin Blockchain Dynamics: the Selfish-Mine Strategy in the Presence of Propagation Delay."

There exist many studies that show how well-connected pools beat the average home nodes in orphan races. And even without those studies, it’s first-year IT school knowledge that shows the difference between propagating a few KB of data between high-end servers with gigabit-speed internet vs. a $300 laptop connected to a 100 Mbps line trying to propagate a 2–4 MB block.

[Nexus9090]

I've heard this argument on a few occasions and technically it really doesn't hold water.

Mining solo to a local solo pool attached to bitcoin core has the same network delays as any other bitcoin node

This is obviously false. A local node running on a $30 router and $50 internet connection has nothing close to the same network delays as a pool node hosted in a specialized data center. Nodes in well-connected data centers have a much better chance of landing in more favorable peer topologies due to their uptime, reliability, and often higher bandwidth capabilities. Your node talks to a few peers, but the speed at which those peers then distribute your block to their peers and how many connections your node has -- creates a propagation tree. Your local node’s block will propagate slower globally compared to other nodes with single-digit millisecond latency to other mining nodes.

Also, pools use dedicated interconnections and relay networks (like FIBRE or Falcon), plus geographically distributed nodes. For example, FIBRE can announce the block header to peers (a few KBs) even before the full block is propagated. This tells other miners to start mining the next block on top of this one, so all major pools are already mining on top of that new block while your node is still mining on top of the previous block. The time it takes for the slow peer-to-peer network to globally propagate that block to your node is huge (5–15 seconds in some cases even more) compared to the sub-1-second UDP-based relay technology those pools use.

By the way, I encourage you to read studies such as "Effects of a Simple Relay Network on the Bitcoin Network," and I will quote a part of the abstract for you:

Results show that the propagation time decreases to approximately 77% of the original value if the utilization rate is set to 3%. This rate is close to the actual utilization rate of relay network "Falcon". We also found that the probability of blocks created by utilizing nodes to become orphan blocks is surprisingly smaller than that of the non-utilizing nodes. Even in the worst case, the value of utilizing nodes is 15% of the value of non-utilizing nodes.

You can also read "Bitcoin Blockchain Dynamics: the Selfish-Mine Strategy in the Presence of Propagation Delay."

There exist many studies that show how well-connected pools beat the average home nodes in orphan races. And even without those studies, it’s first-year IT school knowledge that shows the difference between propagating a few KB of data between high-end servers with gigabit-speed internet vs. a $300 laptop connected to a 100 Mbps line trying to propagate a 2–4 MB block.

Sorry but I simply dont believe this to be true.

Can you prove it?!?

[Nexus9090]

OK here's a test.

If you have access to a bitcoin core node run the command line

Code:

bitcoin-cli -rpcport=yourrpcport -rpcuser=youruser-rpcpassword=yourpassword getpeerinfo

The "getpeerinfo" command will return a JSON string of all of the nodes attached to your bitcoincore instance. Within this JSON is the ping for each node connection.

As you will see they're quite variable in ping duration. In my own set-up I have some that are ~10-20mS and some that are 100ms+

If you have access to a node located in a "High-Speed Datacenter" please run the same command and post your results here. I expect to see similar results.

Code:

[
  {
    "id": 0,
    "addr": "[2600:1900:4000:4cc4:0:13::]:8333",
    "addrbind": "[2a00:23c7:6c8a:7b01:992b:d6a:8a3c:ad03]:45568",
    "addrlocal": "[2a00:23c7:6c8a:7b01:992b:d6a:8a3c:ad03]:45568",
    "network": "ipv6",
    "services": "0000000000000c0d",
    "servicesnames": [
      "NETWORK",
      "BLOOM",
      "WITNESS",
      "NETWORK_LIMITED",
      "P2P_V2"
    ],
    "relaytxes": false,
    "lastsend": 1753973430,
    "lastrecv": 1753973430,
    "last_transaction": 0,
    "last_block": 1753970537,
    "bytessent": 1085870,
    "bytesrecv": 30775368,
    "conntime": 1752435101,
    "timeoffset": 0,
    "pingtime": 0.102092,
    "minping": 0.099039,
    "version": 70016,
    "subver": "/Satoshi:29.0.0/",
    "inbound": false,
    "bip152_hb_to": false,
    "bip152_hb_from": false,
    "startingheight": 905413,
    "presynced_headers": -1,
    "synced_headers": 907963,
    "synced_blocks": 907963,
    "inflight": [
    ],
    "addr_relay_enabled": false,
    "addr_processed": 0,
    "addr_rate_limited": 0,
    "permissions": [
    ],
    "minfeefilter": 0.00000000,
    "bytessent_per_msg": {
      "cmpctblock": 15433,
      "getblocktxn": 44807,
      "getdata": 7830,
      "getheaders": 133350,
      "headers": 136578,
      "ping": 371693,
      "pong": 371722,
      "sendaddrv2": 33,
      "sendcmpct": 270,
      "sendheaders": 33,
      "verack": 33,
      "version": 135,
      "wtxidrelay": 33
    },
    "bytesrecv_per_msg": {
      "blocktxn": 24892432,
      "cmpctblock": 4930632,
      "feefilter": 29,
      "getdata": 58,
      "getheaders": 1050,
      "headers": 204204,
      "ping": 371722,
      "pong": 371693,
      "sendaddrv2": 33,
      "sendcmpct": 30,
      "sendheaders": 33,
      "verack": 33,
      "version": 135,
      "wtxidrelay": 33
    },
    "connection_type": "block-relay-only",
    "transport_protocol_type": "v2",
    "session_id": "1b630e2adce4802f0ba873219d5e6cb6f1573694d2612bd771431cd26ecae06d"
  },
  {
    "id": 11,
    "addr": "74.208.157.68:8333",
    "addrbind": "192.168.1.109:45136",
    "addrlocal": "86.174.79.85:45136",
    "network": "ipv4",
    "services": "0000000004000c0d",
    "servicesnames": [
      "NETWORK",
      "BLOOM",
      "WITNESS",
      "NETWORK_LIMITED",
      "P2P_V2",
      "UNKNOWN[2^26]"
    ],
    "relaytxes": true,
    "lastsend": 1753973497,
    "lastrecv": 1753973489,
    "last_transaction": 1753973489,
    "last_block": 1753856468,
    "bytessent": 225210613,
    "bytesrecv": 497139581,
    "conntime": 1752435119,
    "timeoffset": 0,
    "pingtime": 0.102867,
    "minping": 0.101464,
    "version": 70016,
    "subver": "/Satoshi:26.1.0/Knots:20240325/",
    "inbound": false,
    "bip152_hb_to": false,
    "bip152_hb_from": false,
    "startingheight": 905413,
    "presynced_headers": -1,
    "synced_headers": 907960,
    "synced_blocks": 907960,
    "inflight": [
    ],
    "addr_relay_enabled": true,
    "addr_processed": 28972,
    "addr_rate_limited": 0,
    "permissions": [
    ],
    "minfeefilter": 0.00001000,
    "bytessent_per_msg": {
      "addrv2": 997846,
      "blocktxn": 2482467,
      "cmpctblock": 40384,
      "feefilter": 29,
      "getaddr": 33,
      "getblocktxn": 169209,
      "getdata": 23016752,
      "getheaders": 234150,
      "headers": 168405,
      "inv": 188593270,
      "notfound": 32550,
      "ping": 371664,
      "pong": 371722,
      "sendaddrv2": 33,
      "sendcmpct": 630,
      "sendheaders": 33,
      "tx": 8728580,
      "verack": 33,
      "version": 135,
      "wtxidrelay": 33
    },
    "bytesrecv_per_msg": {
      "addrv2": 1028560,
      "blocktxn": 94882758,
      "cmpctblock": 6038986,
      "feefilter": 29,
      "getblocktxn": 3636,
      "getdata": 1025306,
      "getheaders": 1050,
      "headers": 172777,
      "inv": 72819560,
      "notfound": 15756,
      "ping": 371722,
      "pong": 371664,
      "sendaddrv2": 33,
      "sendcmpct": 30,
      "sendheaders": 33,
      "tx": 320407093,
      "verack": 33,
      "version": 150,
      "wtxidrelay": 33
    },
    "connection_type": "outbound-full-relay",
    "transport_protocol_type": "v2",
    "session_id": "65b04d03e05e65d60481103d5a8ba384d71478fc5c94dc1427660f38342190f4"
  },
  {
    "id": 12,
    "addr": "[2a01:e0a:9b4:8510:da9e:f3ff:fe8b:e266]:8333",
    "addrbind": "[2a00:23c7:6c8a:7b01:992b:d6a:8a3c:ad03]:58398",
    "addrlocal": "[2a00:23c7:6c8a:7b01:992b:d6a:8a3c:ad03]:58398",
    "network": "ipv6",
    "services": "0000000000000c09",
    "servicesnames": [
      "NETWORK",
      "WITNESS",
      "NETWORK_LIMITED",
      "P2P_V2"
    ],
    "relaytxes": true,
    "lastsend": 1753973498,
    "lastrecv": 1753973495,
    "last_transaction": 1753973488,
    "last_block": 1753973049,
    "bytessent": 215769978,
    "bytesrecv": 1062867922,
    "conntime": 1752435170,
    "timeoffset": 0,
    "pingtime": 0.016045,
    "minping": 0.014118,
    "version": 70016,
    "subver": "/Satoshi:29.0.0/",
    "inbound": false,
    "bip152_hb_to": true,
    "bip152_hb_from": false,
    "startingheight": 905413,
    "presynced_headers": -1,
    "synced_headers": 907963,
    "synced_blocks": 907963,
    "inflight": [
    ],
    "addr_relay_enabled": true,
    "addr_processed": 27808,
    "addr_rate_limited": 0,
    "permissions": [
    ],
    "minfeefilter": 0.00000000,
    "bytessent_per_msg": {
      "addrv2": 982353,
      "blocktxn": 489667,
      "cmpctblock": 72746,
      "feefilter": 29,
      "getaddr": 33,
      "getblocktxn": 871077,
      "getdata": 41284766,
      "getheaders": 37800,
      "headers": 52427,
      "inv": 166633596,
      "notfound": 56952,
      "ping": 371519,
      "pong": 371548,
      "sendaddrv2": 33,
      "sendcmpct": 900,
      "sendheaders": 33,
      "tx": 4541364,
      "verack": 33,
      "version": 135,
      "wtxidrelay": 33
    },
    "bytesrecv_per_msg": {
      "addrv2": 1003120,
      "blocktxn": 383487717,
      "cmpctblock": 38125756,
      "getblocktxn": 1452,
      "getdata": 606582,
      "getheaders": 1050,
      "headers": 34374,
      "inv": 93809374,
      "notfound": 35948,
      "ping": 371548,
      "pong": 371519,
      "sendaddrv2": 33,
      "sendcmpct": 90,
      "sendheaders": 33,
      "tx": 545017714,
      "verack": 33,
      "version": 135,
      "wtxidrelay": 33
    },
    "connection_type": "outbound-full-relay",
    "transport_protocol_type": "v2",
    "session_id": "0742a6a1b5d68bb199169fea493dbc34f82a56d78d4d7679eb86f3dfa4601049"
  },
  {
    "id": 175,
    "addr": "[2607:9280:b:73b:250:56ff:fe3d:401]:8333",
    "addrbind": "[2a00:23c7:6c8a:7b01:992b:d6a:8a3c:ad03]:41626",
    "addrlocal": "[2a00:23c7:6c8a:7b01:992b:d6a:8a3c:ad03]:41626",
    "network": "ipv6",
    "services": "0000000000000409",
    "servicesnames": [
      "NETWORK",
      "WITNESS",
      "NETWORK_LIMITED"
    ],
    "relaytxes": true,
    "lastsend": 1753973496,
    "lastrecv": 1753973496,
    "last_transaction": 1753973495,
    "last_block": 0,
    "bytessent": 201112067,
    "bytesrecv": 573508906,
    "conntime": 1752473078,
    "timeoffset": 0,
    "pingtime": 0.165473,
    "minping": 0.150982,
    "version": 70016,
    "subver": "/Satoshi:26.0.0/",
    "inbound": false,
    "bip152_hb_to": false,
    "bip152_hb_from": false,
    "startingheight": 905470,
    "presynced_headers": -1,
    "synced_headers": 907962,
    "synced_blocks": 907962,
    "inflight": [
    ],
    "addr_relay_enabled": true,
    "addr_processed": 8878,
    "addr_rate_limited": 0,
    "permissions": [
    ],
    "minfeefilter": 0.00001000,
    "bytessent_per_msg": {
      "addrv2": 1158941,
      "feefilter": 32,
      "getaddr": 24,
      "getblocktxn": 42948,
      "getdata": 36863290,
      "getheaders": 1053,
      "headers": 180306,
      "inv": 161101776,
      "notfound": 6183,
      "ping": 400000,
      "pong": 400096,
      "sendaddrv2": 24,
      "sendcmpct": 33,
      "sendheaders": 24,
      "tx": 957163,
      "verack": 24,
      "version": 126,
      "wtxidrelay": 24
    },
    "bytesrecv_per_msg": {
      "addrv2": 362445,
      "blocktxn": 16063809,
      "cmpctblock": 2176238,
      "feefilter": 32,
      "getdata": 59801,
      "getheaders": 1053,
      "headers": 164936,
      "inv": 96902689,
      "notfound": 57270,
      "ping": 400096,
      "pong": 400000,
      "sendaddrv2": 24,
      "sendcmpct": 33,
      "sendheaders": 24,
      "tx": 456920282,
      "verack": 24,
      "version": 126,
      "wtxidrelay": 24
    },
    "connection_type": "outbound-full-relay",
    "transport_protocol_type": "v1",
    "session_id": ""
  },
  {
    "id": 221,
    "addr": "73.247.62.19:8333",
    "addrbind": "192.168.1.109:50482",
    "addrlocal": "86.174.79.85:50482",
    "network": "ipv4",
    "services": "0000000000000c09",
    "servicesnames": [
      "NETWORK",
      "WITNESS",
      "NETWORK_LIMITED",
      "P2P_V2"
    ],
    "relaytxes": true,
    "lastsend": 1753973496,
    "lastrecv": 1753973491,
    "last_transaction": 1753973474,
    "last_block": 1753135913,
    "bytessent": 196682642,
    "bytesrecv": 596041679,
    "conntime": 1752488914,
    "timeoffset": 0,
    "pingtime": 0.111985,
    "minping": 0.100812,
    "version": 70016,
    "subver": "/Satoshi:28.1.0/",
    "inbound": false,
    "bip152_hb_to": false,
    "bip152_hb_from": false,
    "startingheight": 905501,
    "presynced_headers": -1,
    "synced_headers": 907962,
    "synced_blocks": 907962,
    "inflight": [
    ],
    "addr_relay_enabled": true,
    "addr_processed": 26816,
    "addr_rate_limited": 0,
    "permissions": [
    ],
    "minfeefilter": 0.00001000,
    "bytessent_per_msg": {
      "addrv2": 950317,
      "cmpctblock": 3720,
      "feefilter": 29,
      "getaddr": 33,
      "getblocktxn": 132678,
      "getdata": 33155618,
      "getheaders": 141750,
      "headers": 146363,
      "inv": 158877670,
      "notfound": 27174,
      "ping": 358527,
      "pong": 358556,
      "sendaddrv2": 33,
      "sendcmpct": 270,
      "sendheaders": 33,
      "tx": 2529425,
      "verack": 33,
      "version": 135,
      "wtxidrelay": 33
    },
    "bytesrecv_per_msg": {
      "addrv2": 959802,
      "blocktxn": 53095500,
      "cmpctblock": 6204803,
      "feefilter": 29,
      "getdata": 223056,
      "getheaders": 1050,
      "headers": 194463,
      "inv": 91882248,
      "notfound": 15504,
      "ping": 358556,
      "pong": 358527,
      "sendaddrv2": 33,
      "sendcmpct": 30,
      "sendheaders": 33,
      "tx": 442745565,
      "verack": 33,
      "version": 135,
      "wtxidrelay": 33
    },
    "connection_type": "outbound-full-relay",
    "transport_protocol_type": "v2",
    "session_id": "c44d02ee806c911d41e7d7200b7f819bcfb714c3522c6c94bccf478888b8ab88"
  },
  {
    "id": 1596,
    "addr": "5.9.28.141:8333",
    "addrbind": "192.168.1.109:42346",
    "addrlocal": "86.174.79.85:42346",
    "network": "ipv4",
    "services": "0000000000000409",
    "servicesnames": [
      "NETWORK",
      "WITNESS",
      "NETWORK_LIMITED"
    ],
    "relaytxes": true,
    "lastsend": 1753973497,
    "lastrecv": 1753973489,
    "last_transaction": 1753973489,
    "last_block": 1753971386,
    "bytessent": 145327415,
    "bytesrecv": 358775691,
    "conntime": 1752894216,
    "timeoffset": 620,
    "pingtime": 0.025058,
    "minping": 0.024161,
    "version": 70016,
    "subver": "/Satoshi:23.0.0/",
    "inbound": false,
    "bip152_hb_to": true,
    "bip152_hb_from": false,
    "startingheight": 906178,
    "presynced_headers": -1,
    "synced_headers": 907963,
    "synced_blocks": 907963,
    "inflight": [
    ],
    "addr_relay_enabled": true,
    "addr_processed": 1006,
    "addr_rate_limited": 0,
    "permissions": [
    ],
    "minfeefilter": 0.00001000,
    "bytessent_per_msg": {
      "addrv2": 807827,
      "block": 89895,
      "blocktxn": 117879,
      "cmpctblock": 2467505,
      "feefilter": 32,
      "getaddr": 24,
      "getblocktxn": 111923,
      "getdata": 19727269,
      "getheaders": 1053,
      "headers": 85330,
      "inv": 116697712,
      "notfound": 18371,
      "ping": 287392,
      "pong": 287104,
      "sendaddrv2": 24,
      "sendcmpct": 858,
      "sendheaders": 24,
      "tx": 4627019,
      "verack": 24,
      "version": 126,
      "wtxidrelay": 24
    },
    "bytesrecv_per_msg": {
      "addrv2": 17709,
      "blocktxn": 52910952,
      "cmpctblock": 11751286,
      "feefilter": 32,
      "getblocktxn": 2172,
      "getdata": 392198,
      "getheaders": 1053,
      "headers": 41022,
      "inv": 58898596,
      "notfound": 52558,
      "ping": 287104,
      "pong": 287392,
      "sendaddrv2": 24,
      "sendcmpct": 1848,
      "sendheaders": 24,
      "tx": 234131547,
      "verack": 24,
      "version": 126,
      "wtxidrelay": 24
    },
    "connection_type": "outbound-full-relay",
    "transport_protocol_type": "v1",
    "session_id": ""
  },
  {
    "id": 2877,
    "addr": "[2607:5300:60:476d::]:8333",
    "addrbind": "[2a00:23c7:6c8a:7b01:992b:d6a:8a3c:ad03]:39642",
    "addrlocal": "[2a00:23c7:6c8a:7b01:992b:d6a:8a3c:ad03]:39642",
    "network": "ipv6",
    "services": "0000000000000408",
    "servicesnames": [
      "WITNESS",
      "NETWORK_LIMITED"
    ],
    "relaytxes": true,
    "lastsend": 1753973498,
    "lastrecv": 1753973496,
    "last_transaction": 1753973496,
    "last_block": 1753904550,
    "bytessent": 91183989,
    "bytesrecv": 269953313,
    "conntime": 1753267553,
    "timeoffset": 0,
    "pingtime": 0.08305,
    "minping": 0.081055,
    "version": 70016,
    "subver": "/Satoshi:0.21.1/",
    "inbound": false,
    "bip152_hb_to": false,
    "bip152_hb_from": false,
    "startingheight": 906813,
    "presynced_headers": -1,
    "synced_headers": 907962,
    "synced_blocks": 907962,
    "inflight": [
    ],
    "addr_relay_enabled": true,
    "addr_processed": 5809,
    "addr_rate_limited": 0,
    "permissions": [
    ],
    "minfeefilter": 0.00001000,
    "bytessent_per_msg": {
      "addrv2": 498776,
      "feefilter": 32,
      "getaddr": 24,
      "getblocktxn": 124231,
      "getdata": 12569709,
      "getheaders": 80028,
      "headers": 60208,
      "inv": 75643698,
      "notfound": 2548,
      "ping": 188224,
      "pong": 188256,
      "sendaddrv2": 24,
      "sendcmpct": 429,
      "sendheaders": 24,
      "tx": 1827604,
      "verack": 24,
      "version": 126,
      "wtxidrelay": 24
    },
    "bytesrecv_per_msg": {
      "addrv2": 223454,
      "blocktxn": 46766553,
      "cmpctblock": 7572554,
      "feefilter": 32,
      "getdata": 146783,
      "getheaders": 1053,
      "headers": 62537,
      "inv": 39221290,
      "notfound": 35711,
      "ping": 188256,
      "pong": 188224,
      "sendaddrv2": 24,
      "sendcmpct": 66,
      "sendheaders": 24,
      "tx": 175546578,
      "verack": 24,
      "version": 126,
      "wtxidrelay": 24
    },
    "connection_type": "outbound-full-relay",
    "transport_protocol_type": "v1",
    "session_id": ""
  },
  {
    "id": 3166,
    "addr": "46.166.142.2:8333",
    "addrbind": "192.168.1.109:58546",
    "addrlocal": "86.174.79.85:58546",
    "network": "ipv4",
    "services": "0000000000000c09",
    "servicesnames": [
      "NETWORK",
      "WITNESS",
      "NETWORK_LIMITED",
      "P2P_V2"
    ],
    "relaytxes": true,
    "lastsend": 1753973496,
    "lastrecv": 1753973496,
    "last_transaction": 1753973491,
    "last_block": 1753951294,
    "bytessent": 110962200,
    "bytesrecv": 650615771,
    "conntime": 1753344813,
    "timeoffset": 0,
    "pingtime": 0.016118,
    "minping": 0.013457,
    "version": 70016,
    "subver": "/Satoshi:29.0.0/",
    "inbound": false,
    "bip152_hb_to": false,
    "bip152_hb_from": false,
    "startingheight": 906935,
    "presynced_headers": -1,
    "synced_headers": 907962,
    "synced_blocks": 907962,
    "inflight": [
    ],
    "addr_relay_enabled": true,
    "addr_processed": 8509,
    "addr_rate_limited": 0,
    "permissions": [
    ],
    "minfeefilter": 0.00000100,
    "bytessent_per_msg": {
      "addrv2": 399676,
      "blocktxn": 58468,
      "cmpctblock": 891836,
      "feefilter": 29,
      "getaddr": 33,
      "getblocktxn": 217458,
      "getdata": 45332222,
      "getheaders": 1050,
      "headers": 58195,
      "inv": 62503100,
      "notfound": 27962,
      "ping": 151902,
      "pong": 151931,
      "sendaddrv2": 33,
      "sendcmpct": 390,
      "sendheaders": 33,
      "tx": 1164073,
      "verack": 33,
      "version": 135,
      "wtxidrelay": 33
    },
    "bytesrecv_per_msg": {
      "addrv2": 316267,
      "blocktxn": 88256464,
      "cmpctblock": 3892059,
      "feefilter": 29,
      "getblocktxn": 706,
      "getdata": 118838,
      "getheaders": 1050,
      "headers": 31518,
      "inv": 41242668,
      "notfound": 19170,
      "ping": 151931,
      "pong": 151902,
      "sendaddrv2": 33,
      "sendcmpct": 210,
      "sendheaders": 33,
      "tx": 516429250,
      "verack": 33,
      "version": 135,
      "wtxidrelay": 33
    },
    "connection_type": "outbound-full-relay",
    "transport_protocol_type": "v2",
    "session_id": "e350995134c788ab62b11fb1f36d9596c853c67e2ab57f0852186e82b6abe29c"
  },
  {
    "id": 3503,
    "addr": "147.229.8.31:8333",
    "addrbind": "192.168.1.109:48316",
    "addrlocal": "86.174.79.85:48316",
    "network": "ipv4",
    "services": "0000000000000c09",
    "servicesnames": [
      "NETWORK",
      "WITNESS",
      "NETWORK_LIMITED",
      "P2P_V2"
    ],
    "relaytxes": true,
    "lastsend": 1753973498,
    "lastrecv": 1753973498,
    "last_transaction": 1753973494,
    "last_block": 1753972531,
    "bytessent": 87334222,
    "bytesrecv": 635649178,
    "conntime": 1753465686,
    "timeoffset": 0,
    "pingtime": 0.477468,
    "minping": 0.031004,
    "version": 70016,
    "subver": "/Satoshi:27.0.0/",
    "inbound": false,
    "bip152_hb_to": true,
    "bip152_hb_from": false,
    "startingheight": 907153,
    "presynced_headers": -1,
    "synced_headers": 907963,
    "synced_blocks": 907963,
    "inflight": [
    ],
    "addr_relay_enabled": true,
    "addr_processed": 8984,
    "addr_rate_limited": 0,
    "permissions": [
    ],
    "minfeefilter": 0.00000000,
    "bytessent_per_msg": {
      "addrv2": 314671,
      "blocktxn": 279,
      "cmpctblock": 84545,
      "feefilter": 29,
      "getaddr": 33,
      "getblocktxn": 240478,
      "getdata": 42247292,
      "getheaders": 1050,
      "headers": 47689,
      "inv": 44087104,
      "notfound": 2276,
      "ping": 122699,
      "pong": 122554,
      "sendaddrv2": 33,
      "sendcmpct": 600,
      "sendheaders": 33,
      "tx": 61871,
      "verack": 33,
      "version": 135,
      "wtxidrelay": 33
    },
    "bytesrecv_per_msg": {
      "addrv2": 311602,
      "blocktxn": 91549283,
      "cmpctblock": 6232175,
      "getblocktxn": 57,
      "getdata": 9736,
      "getheaders": 1050,
      "headers": 14214,
      "inv": 38439416,
      "notfound": 41256,
      "ping": 122554,
      "pong": 122699,
      "sendaddrv2": 33,
      "sendcmpct": 30,
      "sendheaders": 33,
      "tx": 498802068,
      "verack": 33,
      "version": 135,
      "wtxidrelay": 33
    },
    "connection_type": "outbound-full-relay",
    "transport_protocol_type": "v2",
    "session_id": "ebf0d5ffbe6af8e05ab3094165114a9f9e598ab0a088451374c8de2c75cfa74f"
  },
  {
    "id": 4776,
    "addr": "93.56.5.69:8333",
    "addrbind": "192.168.1.109:56632",
    "addrlocal": "86.174.79.85:56632",
    "network": "ipv4",
    "services": "0000000000000c49",
    "servicesnames": [
      "NETWORK",
      "WITNESS",
      "COMPACT_FILTERS",
      "NETWORK_LIMITED",
      "P2P_V2"
    ],
    "relaytxes": false,
    "lastsend": 1753973455,
    "lastrecv": 1753973455,
    "last_transaction": 0,
    "last_block": 1753932593,
    "bytessent": 154707,
    "bytesrecv": 23494864,
    "conntime": 1753815623,
    "timeoffset": 0,
    "pingtime": 0.025091,
    "minping": 0.022929,
    "version": 70016,
    "subver": "/Satoshi:29.0.0/",
    "inbound": false,
    "bip152_hb_to": false,
    "bip152_hb_from": false,
    "startingheight": 907714,
    "presynced_headers": -1,
    "synced_headers": 907963,
    "synced_blocks": 907963,
    "inflight": [
    ],
    "addr_relay_enabled": false,
    "addr_processed": 0,
    "addr_rate_limited": 0,
    "permissions": [
    ],
    "minfeefilter": 0.00000000,
    "bytessent_per_msg": {
      "getblocktxn": 55412,
      "getdata": 232,
      "getheaders": 12600,
      "headers": 8652,
      "ping": 38164,
      "pong": 38164,
      "sendaddrv2": 33,
      "sendcmpct": 150,
      "sendheaders": 33,
      "verack": 33,
      "version": 135,
      "wtxidrelay": 33
    },
    "bytesrecv_per_msg": {
      "blocktxn": 21423136,
      "cmpctblock": 1980048,
      "feefilter": 29,
      "getheaders": 1050,
      "headers": 11647,
      "ping": 38164,
      "pong": 38164,
      "sendaddrv2": 33,
      "sendcmpct": 30,
      "sendheaders": 33,
      "verack": 33,
      "version": 135,
      "wtxidrelay": 33
    },
    "connection_type": "block-relay-only",
    "transport_protocol_type": "v2",
    "session_id": "c5eb58800ce9c192330db72d4eecfb8bc3dbf2e72e25811458c4e330a856be62"
  }
]

[mikeywith]

Can you prove it?!?

Prove what exactly? that your local node has an order of magnitude more chances to lose the orphan race compared to a well-set-up pool node? The studies are there for you to read. The burden of proof is on you now; make your own studies that show how you propagate blocks to mining nodes faster than a well-established pool.

I have literally told you that large pools exchange compact block header data that is a few KBs over gigabit connections, while your node needs to propagate an entire block that could be as large as 4 MB. How exactly do the two of you have the same propagation speed?

In fact, even without any relay services, having geographically distributed nodes alone beats any single home node; you need to have nodes that are very close to other mining nodes. Relying on a P2P network alone to send a block from your house in LA to a miner node in Kazakhstan is bizarre; another miner that finds a block in Australia but has well-geographically distributed nodes will likely reach other nodes inside the U.S. faster than you.

There exist many tools and projects on GitHub for this particular topic; thousands of lines of code are written just to test and improve propagation time, and millions in infrastructure and research are spent to achieve the best propagation results. You can deny all of it -- it doesn't mean it's not real.


As for the above test, it's rather useless ; it doesn't matter if your ping results to all peers are 1 ms. Those nodes could very well be just home nodes far away from the nodes that matter (miners' nodes). Block propagation time is what matters, you need to compare the time your node received a block vs. when another well-established node received it. Use UpdateTip on your node to see the timestamp of when you received a block, and compare that to when a large explorer like mempool first saw that block. Run this against a large sample of blocks to get a somewhat accurate result, and mind you, other pools must have seen that block even earlier than mempool.

With that said, it doesn't mean your node will lose every block; it simply means it's at a higher risk, if we were to assume that other pools have a 10-second advantage in propagation time, you can run a simple Poisson process of :

1-exp(-10/600)  ~= 1.6653%  > chance of a block being found in the next 10 seconds or less, if Foundry finds a block within that timestamp and you both start racing, they will still likely beat you

You may think 1% is low, but it does happen. I haven't even touched on the other potential issues, like your PC or router failing you right about that second. Large corps buy 10k routers not because they want to waste money but because they can't afford the slightest delay or packet loss. While you could have a 100% uptime with your $200 laptop and $30 router, it's just not as guaranteed as the other setup. It's not as bad as some people might explain it, but there indeed exists a higher level of risk when you count on your local node to mine blocks.

[Nexus9090]

You know what...

I really don't care. I think there are so many metrics to this that are all bound by the P2P structure of the bitcoin network that the advantage or disadvantage is just a mute point.

I think we need to agree to disagree.

IMHO, it makes no difference.

In your opinion it is the make or break.

Never the twain shall meet.

[mikeywith]

You know what...

I really don't care. I think there are so many metrics to this that are all bound by the P2P structure of the bitcoin network that the advantage or disadvantage is just a mute point.

I think we need to agree to disagree.

IMHO, it makes no difference.

In your opinion it is the make or break.

Never the twain shall meet.

I did not say it's make or break, I even explain the risk %, and most importantly -- it is not really an opinion, you are not in disagreement with an opinion but rather various scientific research papers.

With that said, disagreements are good in general, people can read both views and make up their own minds, imagine you just agreed or ignored my post!! where is the fun in that?

enjoy, hope you hit a block on your local node.

[Nexus9090]

You know what...

I really don't care. I think there are so many metrics to this that are all bound by the P2P structure of the bitcoin network that the advantage or disadvantage is just a mute point.

I think we need to agree to disagree.

IMHO, it makes no difference.

In your opinion it is the make or break.

Never the twain shall meet.

I did not say it's make or break, I even explain the risk %, and most importantly -- it is not really an opinion, you are not in disagreement with an opinion but rather various scientific research papers.

With that said, disagreements are good in general, people can read both views and make up their own minds, imagine you just agreed or ignored my post!! where is the fun in that?

enjoy, hope you hit a block on your local node.

Thanks, hope you have some success too.

As for the research papers, I've seen one too many and to be honest they're mostly not worth the ink or pixels!

Anyway, Good luck and happy mining.

[MagicDude4Eva]

Code:

bitcoin-cli -rpcport=yourrpcport -rpcuser=youruser-rpcpassword=yourpassword getpeerinfo

TBH on my local node I see no difference to your output (perhaps I am looking at the wrong thing):

Code:

root@MuffinStation:~# docker exec -it bitcoin-node bitcoin-cli -conf=/bitcoin/bitcoin.conf -datadir=/bitcoin getpeerinfo | grep -i pingtime
    "pingtime": 0.190681,
    "pingtime": 0.128512,
    "pingtime": 0.19279,
    "pingtime": 0.312987,
    "pingtime": 0.188246,
    "pingtime": 0.031604,
    "pingtime": 4.321106,
    "pingtime": 0.027684,
    "pingtime": 0.138654,
    "pingtime": 0.144322,

[Nexus9090]

Code:

bitcoin-cli -rpcport=yourrpcport -rpcuser=youruser-rpcpassword=yourpassword getpeerinfo

TBH on my local node I see no difference to your output (perhaps I am looking at the wrong thing):

Code:

root@MuffinStation:~# docker exec -it bitcoin-node bitcoin-cli -conf=/bitcoin/bitcoin.conf -datadir=/bitcoin getpeerinfo | grep -i pingtime
    "pingtime": 0.190681,
    "pingtime": 0.128512,
    "pingtime": 0.19279,
    "pingtime": 0.312987,
    "pingtime": 0.188246,
    "pingtime": 0.031604,
    "pingtime": 4.321106,
    "pingtime": 0.027684,
    "pingtime": 0.138654,
    "pingtime": 0.144322,

Thanks, that's exactly what I'd have expected to see. 

[MagicDude4Eva]

Thanks, that's exactly what I'd have expected to see. 

I would think ping below 100ms would be rare in a home-setup. Makes me wonder what pings then pool-websites have.

[Nexus9090]

Thanks, that's exactly what I'd have expected to see.  

I would think ping below 100ms would be rare in a home-setup. Makes me wonder what pings then pool-websites have.

A few of mine are around 100mS with a some in the <20mS region. I'm on a symetric 1GBit FTTP service, I guess it depends a lot on your ISP and what your contention ratios are like and where the nodes are located relative to you.

Code:

    "pingtime": 0.101072,
    "pingtime": 0.103778,
    "pingtime": 0.016225,
    "pingtime": 0.155524,
    "pingtime": 0.112941,
    "pingtime": 0.025236,
    "pingtime": 0.086451,
    "pingtime": 0.015352,
    "pingtime": 0.092559,
    "pingtime": 0.023872,

[MagicDude4Eva]

I am perhaps of the wrong opinion, but I am thinking: what are the chances that with my ping being below 500ms and me finding a block and then loosing the race against some other miner trying to confirm the same block. Not sure what the probability for this would be and if it is something to worry about.

I do agree that self hosting requires resources and monitoring. If I would go and spend €150/month I could also upgrade my 250mbps fibre line to 1gig and possibly improve latency.

[Nexus9090]

I am perhaps of the wrong opinion, but I am thinking: what are the chances that with my ping being below 500ms and me finding a block and then loosing the race against some other miner trying to confirm the same block. Not sure what the probability for this would be and if it is something to worry about.

I do agree that self hosting requires resources and monitoring. If I would go and spend €150/month I could also upgrade my 250mbps fibre line to 1gig and possibly improve latency.

I wouldn't worry about it if I were you.

The likelyhood of finding a block for a home miner is tiny anyway if you're only pushing a few TH/s thats why solo mining is also called lottery mining. Also the odds of another miner finding the block exactly at the same time and propagating its result before you do are beyond astronomical.

I'm pushing 7.2TH/s onto my local pool, according to solochance.com the odds are:-

Chance per block: 1 in 132,770,833
Chance per day: 1 in 922,020
Time estimate: 2,526 years

Still better odds than winning the national lottery.

Unless you're pushing several PH onto your home pool you could be waiting a lifetime to find out or it could happen in the next five minutes, thats the nature of solo mining.

Also, you'll find nodes come and go, so refresh your list and you'll likely find a completely new set of ping data.