bitcoind does not retrieve blocks with conf argument

[timstackblock]

Describe the bug

Launching bitcoind with the command given in the documents:
bitcoind -conf=<path-to-bitcoin.config>/bitcoin.conf

For some reason chainhooks can't read the rpcuser=root rpcpassword=root in the file. This results in no blocks being found, when the predicate is ran the user gets this error message

Aug 08 21:48:23.238 INFO Starting predicate evaluation on Bitcoin blocks
Aug 08 21:48:30.268 WARN unable to retrieve block hash #777534: will retry in a few seconds (attempt #4).

Launching bitcoind with this command allows the predicate to be run as it can find the blocks

Aug 08 21:51:13.577 INFO Starting predicate evaluation on Bitcoin blocks
Aug 08 21:51:15.481 INFO 7 blocks scanned, 0 actions triggered

./bitcoind -rpcuser=root -rpcpassword=root

Has anyone else run into this?

[timstackblock]

Bitcoin.conf file for your review

datadir=/opt/homebrew/Cellar/bitcoin/25.0/bin/
server=1
rpcuser=root
rpcpassword=root
rpcport=8332
rpcallowip=0.0.0.0/0
rpcallowip=::/0
txindex=1
listen=1
discover=0
dns=0
dnsseed=0
listenonion=0
rpcserialversion=1
disablewallet=0
fallbackfee=0.00001
rpcthreads=8
blocksonly=1
dbcache=4096

# Start zeromq
zmqpubhashblock=tcp://0.0.0.0:18543

[MicaiahReid]

@timstackblock and I were able to figure this one out.

It looks like the bitcoin node just hadn't synced yet, so the predicate was trying to check blocks that did not yet exist on the chain. The bitcoin node was returning an RPC error stating that the requested block was out of range, but the user never sees that error. I've opened #375 to fix how we display errors here.

But it looks like everything works fine with a bitcoin node, and our documentation on how to set one up is sufficient.

On a side note, when Tim started bitcoind without a config, only passing in terminal arguments, the scan would work. This was confusing for a while. It turns out that the bitcoin.conf specified a different data directory than the default termnial startup conditions, so while the default location did have all blocks synced, the location specified by the config did not. This resulted in the confusing behavior where one worked and the other didn't.

[timstackblock]

Thanks for the screenshare and help @MicaiahReid