Connection UX is frustrating.

[Transisto]

This seems always off by default when starting the wallet

Turning it on doesn't do anything.

Test connection seems to never work.

Going to edit the server turns off the

Sometime This button say EDIT existing connection some other time it say TEST connection.

Now works after closing and reopening the wallet.

[Transisto]

[Transisto]

Might be an idea to have a Green / Red signal to know if wallet is properly connected.

[craigraw]

Might be an idea to have a Green / Red signal to know if wallet is properly connected.

The toggle in the lower right corner of the wallet acts both as a switch connect to the server, and to indicate the wallet is connected.

I tested the same connection details as above and the test worked immediately. I was then able to connect to this server using the toggle as described above.

The Edit Connection button appears on the Server preferences if the wallet is already connected. Clicking this button indicates that the wallet should terminate this connection in order to receive new connection details. The button then changes to Test Connection in order to allow the user to test these details. After a successful 'Test Connection' (the green tick you posted above), using the toggle should always connect to the server - no restart should be required, since the code execution is exactly the same as used in the test.

It's clear from the above that at some point there was a connection error: 'Retries exhausted'. This means Sparrow has tried repeatedly to get a response from the server, but eventually had to give up. This looks more like the server was overloaded (unable to respond) rather than a connection error though.

That said I have noticed an issue (still unresolved) when switching from between Tor and non-Tor connections, and between some VPN and non-VPN setups. It appears to be IP routing related and quite low level, and is resolved with a restart of the wallet.

[6102bitcoin]

Outstanding Action: More clearly display server has hit max retries in UI.
Proposed Priority: Low

[Giszmo]

As this issue is still open, please allow me to add my drama ...

For some reason, rpcuser did not work with my localhost bitcoin core. I tried to switch to coookie out. I restarted bitcoin core many times, deleted its config and waited until there is no indication of syncing or indexing in the bitcoin core before starting sparrow but sparrow always gave me errors when testing the connection.

In the end I had it set to cookie, it claimed it did not work but minutes later while I was busy doing other stuff, this window suddenly popped up:

I'm not sure what it does but it appears to be by Bitcoin-Qt and not by Sparrow. As my Bitcoin Core has indexing activated, I think it should not take as long as it takes to scan a hand full of addresses but apparently Sparrow now does talk to Bitcoin Core despite a conclusive failed test of the connection.

Something is off here.

[craigraw]

@Giszmo It's possible that the Bitcoin-Qt had not yet started it's RPC interface on the initial test, started it later, and Sparrow then connected (re-attempts at connection are made after a minute). As to the rescan, the scanning is started from the date entered when creating the wallet. The actual time taken is of course dependant on Bitcoin Core, and is independent of any other index in Core (Bitcoin Core's txindex is not an address index, for example).

Given this is an old issue which is somewhat vague in subject, I'm going to close it off here.

[Giszmo]

As I'm probably not the only one who clicks "test connection" and immediately tries changing this and that if it says "error", I think it would be very helpful if Sparrow could tell the user "Bitcoin Core can take up to 5 minutes to accept rpc connections" or it could tell the user how to know if the rpc connection is up. Here it definitely took much more than a minute.