Running tcp service on regtest

[KayBeSee]

Hey Calin,

I am struggling to get the tcp service to run on regtest.

I have fulcrum connected to my bitcoind node and it is processing the regtest data (fulcrum_1 | [2022-04-22 19:40:58.811] <Controller> Processed 132 new blocks with 132 txs (132 inputs, 263 outputs, 132 addresses), verified ok.)

This is the output from fulcrum:

fulcrum git:(master) ✗ docker-compose -f docker-compose.regtest.yml up fulcrum
fulcrum_bitcoind_1 is up-to-date
Recreating fulcrum_fulcrum_1 ... done
Attaching to fulcrum_fulcrum_1
fulcrum_1   | Generating a RSA private key
fulcrum_1   | .........................................+++++
fulcrum_1   | .............................................................................+++++
fulcrum_1   | writing new private key to '/data/fulcrum.key'
fulcrum_1   | -----
fulcrum_1   | [2022-04-22 19:40:56.796] 'datadir' specified both via the CLI and the configuration file. The CLI arg will take precedence.
fulcrum_1   | [2022-04-22 19:40:56.797] Enabled JSON parser: simdjson
fulcrum_1   | [2022-04-22 19:40:56.797] simdjson implementations:
fulcrum_1   | [2022-04-22 19:40:56.797]     fallback: Generic fallback implementation  [supported]
fulcrum_1   | [2022-04-22 19:40:56.797] active implementation: fallback
fulcrum_1   | [2022-04-22 19:40:56.799] jemalloc: version 5.2.1-0-gea6b3e9
fulcrum_1   | [2022-04-22 19:40:56.799] Qt: version 5.15.2
fulcrum_1   | [2022-04-22 19:40:56.799] rocksdb: version 6.14.6-ed43161
fulcrum_1   | [2022-04-22 19:40:56.799] simdjson: version 0.6.0
fulcrum_1   | [2022-04-22 19:40:56.799] ssl: OpenSSL 1.1.1n  15 Mar 2022
fulcrum_1   | [2022-04-22 19:40:56.799] zmq: libzmq version: 4.3.4, cppzmq version: 4.7.1
fulcrum_1   | [2022-04-22 19:40:56.799] Fulcrum 1.6.0 (Release 7468990) - Fri Apr 22, 2022 19:40:56.799 UTC - starting up ...
fulcrum_1   | [2022-04-22 19:40:56.799] Max open files: 1048576
fulcrum_1   | [2022-04-22 19:40:56.799] Loading database ...
fulcrum_1   | [2022-04-22 19:40:57.241] DB memory: 512.00 MiB
fulcrum_1   | [2022-04-22 19:40:57.244] Verifying headers ...
fulcrum_1   | [2022-04-22 19:40:57.247] BitcoinDMgr: starting 3 bitcoin RPC clients ...
fulcrum_1   | [2022-04-22 19:40:57.247] BitcoinDMgr: started ok
fulcrum_1   | [2022-04-22 19:40:57.247] Stats HTTP: starting 1 server ...
fulcrum_1   | [2022-04-22 19:40:57.248] Starting listener service for HttpSrv 127.0.0.1:8080 ...
fulcrum_1   | [2022-04-22 19:40:57.248] Service started, listening for connections on 127.0.0.1:8080
fulcrum_1   | [2022-04-22 19:40:57.253] <BitcoinDMgr> Coin: BTC
fulcrum_1   | [2022-04-22 19:40:57.352] <Controller> Chain: regtest
fulcrum_1   | [2022-04-22 19:40:57.352] <Controller> Block height 131, downloading new blocks ...
fulcrum_1   | [2022-04-22 19:40:57.352] <Controller> fast-sync: Not enabled
fulcrum_1   | [2022-04-22 19:40:58.811] <Controller> Processed 132 new blocks with 132 txs (132 inputs, 263 outputs, 132 addresses), verified ok.
fulcrum_1   | [2022-04-22 19:40:58.813] <Controller> Initializing header merkle cache ...
fulcrum_1   | [2022-04-22 19:40:58.815] <Controller> Block height 131, up-to-date
fulcrum_1   | [2022-04-22 19:40:58.815] SrvMgr: starting PeerMgr ...
fulcrum_1   | [2022-04-22 19:40:58.816] FATAL: PeerMgr cannot be started for the given chain "regtest"
fulcrum_1   | [2022-04-22 19:40:58.816] Stopping Stats HTTP Servers ...
fulcrum_1   | [2022-04-22 19:40:58.816] Stopping Controller ...
fulcrum_1   | [2022-04-22 19:40:58.831] Stopping ZMQ notifier ...
fulcrum_1   | [2022-04-22 19:40:58.832] Stopping SrvMgr ...
fulcrum_1   | [2022-04-22 19:40:58.832] Stopping BitcoinDMgr ...
fulcrum_1   | [2022-04-22 19:40:58.833] Closing storage ...
fulcrum_1   | [2022-04-22 19:40:59.058] Shutdown complete

I also verified that bitcoind had completed it's initial block download and it looks like it has. This is the output from running getblockchaininfo.

{
  "chain": "regtest",
  "blocks": 151,
  "headers": 151,
  "bestblockhash": "74966bfa888c63de43e179f1e425d58a4dc148a0960e35556ccf073a239429c1",
  "difficulty": 4.656542373906925e-10,
  "mediantime": 1650656642,
  "verificationprogress": 1,
  "initialblockdownload": false,
  "chainwork": "0000000000000000000000000000000000000000000000000000000000000130",
  "size_on_disk": 45450,
  "pruned": false,
  "softforks": {
    "bip34": {
      "type": "buried",
      "active": false,
      "height": 500
    },
    "bip66": {
      "type": "buried",
      "active": false,
      "height": 1251
    },
    "bip65": {
      "type": "buried",
      "active": false,
      "height": 1351
    },
    "csv": {
      "type": "buried",
      "active": false,
      "height": 432
    },
    "segwit": {
      "type": "buried",
      "active": true,
      "height": 0
    },
    "testdummy": {
      "type": "bip9",
      "bip9": {
        "status": "started",
        "bit": 28,
        "start_time": 0,
        "timeout": 9223372036854775807,
        "since": 144,
        "statistics": {
          "period": 144,
          "threshold": 108,
          "elapsed": 8,
          "count": 8,
          "possible": true
        },
        "min_activation_height": 0
      },
      "active": false
    },
    "taproot": {
      "type": "bip9",
      "bip9": {
        "status": "active",
        "start_time": -1,
        "timeout": 9223372036854775807,
        "since": 0,
        "min_activation_height": 0
      },
      "height": 0,
      "active": true
    }
  },
  "warnings": ""
}

My fulcrum.conf file looks like this:

datadir = /data/regtest 
bitcoind = bitcoind:18443
tcp = 0.0.0.0:50001

I noticed in #91 that there is an output about the TcpSrv starting but I am not seeing that in my output. Any idea why the tcp server is not starting?

[cculianu]

Oh ha. This is the problem:

fulcrum_1 | [2022-04-22 19:40:58.816] FATAL: PeerMgr cannot be started for the given chain "regtest"

Yeah, so I have the PeerManager die with a fatal error if it is enabled. Peering is enabled by default, but of course this doesn't make sense on regtest, since each chain is local to the machine and peering is almost nonsensical in that case. Maybe I should modify Fulcrum to not do a fatal error there. Hmm. Good catch.

Ok so to fix this add the following to the conf file:

peering = false

[cculianu]

@KayBeSee I just pushed commit b8c670a which should help mitigate this potential trap for users wishing to run regtest. Fulcrum will just proceed anyway even if peering = true but PeerMgr failed to start. You can pull latest master and rebuild your docker composer thing if you like and it should just work now, no conf file modifications needed.

[KayBeSee]

Very nice, that appears to be working. Thanks!

[cculianu]

Nice catch man this actually was a sort of "bug" or at least user-experience incongruity. Thanks for reporting! Do feel free to open up new issues if you have more questions. This helps others too, to have questions in the issue tracker. You never know maybe others encounter the same problem(s) or have similar questions.

[KayBeSee]

No problem, will do! Thanks for building a fantastic service!