Sparrow does not connect to Bitcoin Core

[bluruin17]

Sparrow says "Could not connect" on Sparrow Wallet's server settings.

I am running my full node locally, although the folder is on an external HDD.

I added "server=1" to the config file.

I'm wondering if the issue has something to do either with having the Bitcoin Core folder on an external HDD, or that I'm using a VPN. I thought that the VPN wouldn't affect the ability of Sparrow to connect to a local instance of Core, but at this point I don't know what else to blame for this failure to connect.

[casey]

Having the same issue here, I don't think there's anything weird about my bitcoin core config or setup. Also, curl seems to work:

$ curl 127.0.0.1:8332
JSONRPC server handles only POST requests%

[bluruin17]

2022-08-15 11:03:41,741 ERROR [JavaFX Application Thread] c.s.s.n.ElectrumServer [null:-1] Failed to start BWT dev.bwt.libbwt.BwtException: JSON-RPC error: transport error: Couldn't connect to host: Broken pipe (os error 32) at com.sparrowwallet.merged.module@1.6.6/dev.bwt.libbwt.daemon.NativeBwtDaemon.start(Native Method) at com.sparrowwallet.sparrow@1.6.6/com.sparrowwallet.sparrow.net.Bwt.start(Unknown Source) at com.sparrowwallet.sparrow@1.6.6/com.sparrowwallet.sparrow.net.Bwt.start(Unknown Source) at com.sparrowwallet.sparrow@1.6.6/com.sparrowwallet.sparrow.net.Bwt$ConnectionService$1.call(Unknown Source) at com.sparrowwallet.sparrow@1.6.6/com.sparrowwallet.sparrow.net.Bwt$ConnectionService$1.call(Unknown Source) at javafx.graphics@18/javafx.concurrent.Task$TaskCallable.call(Unknown Source) at java.base/java.util.concurrent.FutureTask.run(Unknown Source) at javafx.graphics@18/javafx.concurrent.Service.lambda$executeTask$6(Unknown Source) at java.base/java.security.AccessController.doPrivileged(Unknown Source) at javafx.graphics@18/javafx.concurrent.Service.lambda$executeTask$7(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.base/java.lang.Thread.run(Unknown Source)

[craigraw]

This error (OS error 32) is coming from the operating system indicating it can't create or write to the RPC socket for some reason (possibly because it has already been closed by the node). Unfortunately this error is fairly general, so it's difficult to tell more from this alone.

Are any proxies involved? Can you try disabling the VPN?

Another idea is to try user/password based authentication for the RPC, instead of cookie authentication.

[tanx]

Same here. Running a pruned node on the cli with the following config. No VPN or tor running.

server=1
prune=5000

Tested curl command as above (works too)

Bitcoin Core version v23.0.0 (release build) installed via homebrew running on Mac OS 12.4, Apple M1

[tanx]

FWIW sparrow seemed to be successfully connecting and displaying progress during IDB but after it finished connecting was no longer possible.

[craigraw]

There may be several issues being discussed here. For those reading this thread, make sure you are running v1.6.6. Versions v1.6.2 and prior do not support Bitcoin Core v23 or later. If you have been running a previous version, make sure to stop both Core and Sparrow, and delete the 'sparrow' folder in the Core wallets folder. Then start Core again, and once up Sparrow.

[bluruin17]

Are any proxies involved? Can you try disabling the VPN?

I don't want to disable the VPN because I don't want to link my real IP to Bitcoin node activity even for a second. Specter and Core seem to have no issues with my VPN, and I even receive incoming connections.

However, could Sparrow be having an issue because I use a forwarded port for Core? I have specified the port I use in Sparrow, and I have also tried using the default 8332 port, but neither works. Even when I revert Core back to a listen-only node that doesn't use any forwarded port Sparrow won't connect to it.

[tanx]

There may be several issues being discussed here. For those reading this thread, make sure you are running v1.6.6. Versions v1.6.2 and prior do not support Bitcoin Core v23 or later. If you have been running a previous version, make sure to stop both Core and Sparrow, and delete the 'sparrow' folder in the Core wallets folder. Then start Core again, and once up Sparrow.

Confirmed I'm running v1.6.6. I have not run a prior version and synced bitcoind v23 from a clean state.

[craigraw]

However, could Sparrow be having an issue because I use a forwarded port for Core?

I'm not sure TBH. Sparrow is using the BWT library internally, which is using the Rust stack. It may be worth getting BWT from https://github.com/bwt-dev/bwt and running it off the command line to try debug this further. It's fairly straightforward to use. The other alternative is to setup an Electrum server, which is the approach I prefer.

[craigraw]

Confirmed I'm running v1.6.6. I have not run a prior version and synced bitcoind v23 from a clean state.

Are you getting the same error 32 (Broken pipe)? If not please create a separate issue with any relevant logging from Sparrow and Core's debug.log.

[casey]

The other alternative is to setup an Electrum server, which is the approach I prefer.

I haven't had any luck trying to get an Electrum server running so far, it seems very difficult to set up, whereas getting bitcoind running just just bitcoind -txindex=1.

[casey]

Downgrading to 1.6.5 is a temporary workaround.

[craigraw]

@casey Can you take a look your log file (Help menu) from when you couldn't connect to see if there are any relevant errors? They will likely include the text BwtException.

Fwiw the BWT library inside Sparrow hasn't changed for a couple of versions now, so it's strange that downgrading solved this. More information is needed to understand what's going on.

[craigraw]

Also, I should add that Taproot (P2TR) wallets are not supported on Bitcoin Core yet. See bwt-dev/bwt#91 for details on why this has been delayed by a project upstream to BWT.

[casey]

Sorry, I spoke too soon. I thought it was working because it started syncing, but once the sync finished it still didn't work. Here's the log entry from when I click the connect toggle in the lower right hand corner:

2022-08-17 22:47:09,144 ERROR [JavaFX Application Thread] c.s.s.n.ElectrumServer [null:-1] Failed to start BWT
dev.bwt.libbwt.BwtException: JSON-RPC error: RPC error response: RpcError { code: -4, message: "Compiled without bdb support (required for legacy wallets)", data: None }
	at com.sparrowwallet.merged.module@1.6.5/dev.bwt.libbwt.daemon.NativeBwtDaemon.start(Native Method)
	at com.sparrowwallet.sparrow@1.6.5/com.sparrowwallet.sparrow.net.Bwt.start(Unknown Source)
	at com.sparrowwallet.sparrow@1.6.5/com.sparrowwallet.sparrow.net.Bwt.start(Unknown Source)
	at com.sparrowwallet.sparrow@1.6.5/com.sparrowwallet.sparrow.net.Bwt$ConnectionService$1.call(Unknown Source)
	at com.sparrowwallet.sparrow@1.6.5/com.sparrowwallet.sparrow.net.Bwt$ConnectionService$1.call(Unknown Source)
	at javafx.graphics@18/javafx.concurrent.Task$TaskCallable.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at javafx.graphics@18/javafx.concurrent.Service.lambda$executeTask$6(Unknown Source)
	at java.base/java.security.AccessController.doPrivileged(Unknown Source)
	at javafx.graphics@18/javafx.concurrent.Service.lambda$executeTask$7(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)

My bitcoind does in fact not seem to link bdb:

/opt/homebrew/bin/bitcoind:
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
        /opt/homebrew/opt/miniupnpc/lib/libminiupnpc.17.dylib (compatibility version 0.0.0, current version 0.0.0)
        /opt/homebrew/opt/libevent/lib/libevent_pthreads-2.1.7.dylib (compatibility version 8.0.0, current version 8.1.0)
        /opt/homebrew/opt/libevent/lib/libevent-2.1.7.dylib (compatibility version 8.0.0, current version 8.1.0)
        /opt/homebrew/opt/zeromq/lib/libzmq.5.dylib (compatibility version 8.0.0, current version 8.4.0)
        /usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 331.5.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.23.0)

[craigraw]

@casey Yes, that's the issue then. Was bitcoind installed via Homebrew? I see there are multiple Homebrew packages for it, do you know which one you used?

I prefer to compile from source. Note that bdb is included by default when building (bdb itself is installed with brew install berkeley-db@4), so it may be that your binaries were explicitly compiled without wallet support. You might also try the binaries from https://bitcoincore.org/en/download/.

[tanx]

bitcoind was installed via homebrew for me too. I tried installing berkeley-db@4 but that was already installed.

[craigraw]

If Homebrew is installing binaries without wallet support (as opposed to building bitcoind against installed libraries, which I doubt) then you'll need to find another way to install it (see my suggestions above). In any case, you should not need to resync the blockchain. Or, as mentioned previously, use an Electrum server in addition to bitcoind.

[casey]

Homebrew's bitcoind should definitely be fixed! If it doesn't support legacy wallets, then there will be a long tail of support requests to Sparrow and others, since homebrew is far and away the dominant way to install packages on macos.

It looks like this issue was introduced in a recent PR.

I opened a PR to downgrade to bdb v4. Once that's merged, upgrading bitcoin via homebrew will pick up a legacy-wallet-capable bitcoind.

[tanx]

I opened a PR to Homebrew/homebrew-core#108577.

Amazing. Thank you. I tested with bitcoin core build from the bitcoin.org website and confirmed it worked with that one.

[triallax]

That PR was merged, so this issue should be closed.

(I'm the one who introduced the bug, my bad! Sorry for the disruption that this caused.)

[casey]

Just tested with bitcoin from homebrew, and this is working again!

[craigraw]

Thanks @casey and @mhmdanas.

@bluruin17 can we close this issue?

[tanx]

Confirmed it works with the newest homebrew build. Amazing work guys, taking ownership and fixing a bug in third party open source project 👏🏼

[casey]

Hopefully this was @bluruin17's original issue, I just assumed it was 😅

[craigraw]

No response, so assuming the original issue is now resolved. Closing this off.