enable backward compatibility with older versions of Bitcoin Core

[GitGab19]

This PR introduces compatibility with older versions of Bitcoin Core.

The setup flow now asks users to explicitly select their Bitcoin Core version, and the backend uses that selection to choose matching JDC and tProxy Docker image tags.

Closes #116
Blocked by stratum-mining/sv2-apps#439

[pavlenex]

Can we automatically detect the version? Also can you provide steps on how to test.

[GitGab19]

Can we automatically detect the version?

Unfortunately we cannot do that easily (that's the first thing I tried), because when running sv2-ui in Docker (the UX we are suggesting to users) we don't have access to the host system.

IPC doesn't have a method to get the node's version AFAIK (I sent a DM to @Sjors to confirm this), so the only solution would be to ask users to do some changes in their bitcoin.conf (such as setting server=1, rpcuser, rpcpassword, rpcbind=0.0.0.0, and rpcallowip=0.0.0.0/0) and use the RPC method getnetworkinfo to get the node's version.

At this point I thought it would have been way easier to simply select the version from the setup wizard.

Also can you provide steps on how to test.

We need to get stratum-mining/sv2-apps#439 in before testing this unfortunately.

[GitGab19]

In the meantime a "review&test" can be about the UX/UI changes, but I'll make sure to ping you once we get stratum-mining/sv2-apps#439 merged.

[pavlenex]

Gotcha. With what we have atm, we probably should do a dropdown of supported versions and then maintain the list as new versions keep coming out which may end up being tiresome.

Another more important thing I tried is selecting 31 while running 30.2 and ended up in this loop where i just had option of pressing start mining button without any error message on what's going on, so we likely need a proper error handling there.

[GitGab19]

@pavlenex I pushed d1ce7cf to add a banner in that case:

Let me know what you think about it.

[Sjors]

It's useful to have backward compatibility support in general, though I would recommend against supporting anything before v31 at this point (except for just testing this feature).

[pavlenex]

@pavlenex I pushed d1ce7cf to add a banner in that case:

Let me know what you think about it.

Looks good.

[pavlenex]

@GitGab19 something is off, upon testing, I was able to select 31 from the drop-down and even mine, even though I am running v30.2.

What is expected behaviour here, throw an error or do you detect automatically what user is running? I am a bit confused on what's the flow. This is good behaviour because user can mine.

One one hand, this is good, because user is not blocked, and imo ideal outcome, but how come it happened?

[GitGab19]

@pavlenex that's simply because we haven't merged stratum-mining/sv2-apps#439 yet, and so the current main tag docker image is still compatible with v30.2.

This is what's happening under the hood:

• if you select v30.2 during setup, you're gonna use older versions of our apps (specifically v0.3.4) compatible with it
• if you select v31 instead, you are gonna use the latest main tag version of our apps, which are compatible with it
  • on the future sv2-ui v0.2.0 release branch this will change as we did for past releases, so that users will be using stable released versions of our apps (in this case the future v0.4.0 tag images)

Once we merge stratum-mining/sv2-apps#439, what you tried to do is gonna error out, because of incompatibility.

What you can try until then, is to do the opposite, by selecting v30.2 while running a v31 node.

[GitGab19]

stratum-mining/sv2-apps#439 was merged, and the updated Docker images are now published to dockerhub.

This PR is completely unblocked now, and can be tested properly with both Bitcoin Core versions, v30.2 and v31.

[Shourya742]

I tried this PR locally. The setup flows are working fine. I was able to verify that if Bitcoin is selected incorrectly, the setup does not start and prompts the user to reset it. The only caveat is that the user is redirected back to the start of the wizard, perhaps we could allow edits directly from the dashboard settings page instead.

Another stuff: during runtime, I changed the core version from v31 to v30.2. Although mining stopped, it did not redirect me back to the setup as it did during bootstrap, nor did I receive any error. Instead, I was repeatedly prompted to restart mining, even though both JDC and tproxy containers were going down.

[pavlenex]

tACK on my end, just tested:

• Not selecting version - can't proceed ✅
• Select 31 but run 30.2 - starts, but asks to reconfigure ✅
• Select 31 and run 31 - starts normally ✅
• Select 30.2 but run 31 - starts but asks to reconfigure ✅
• Select 30.2 and run 30.2 - starts normally ✅

I didn't check the node switch in between like @Shourya742 but in general this error that user sees "Can't connect to the Pool" can be misleading, I think in most cases we've fixed it, but it can only happen if node is syncing, so user may not always get proper context, I don't think it's a blocker for this particular PR but we should log an issue and see how to have more contextual error handling for this one.

Good work @GitGab19!

[GitGab19]

@Shourya742 can you try again now?

I improved the error handling, so now you should never encounter a situation where there's something wrong, but you don't see the specific error banner. Even if you try to switch nodes' versions during runtime.

In addition to this, if there's a mismatch, and you click the "Reconfigure" button, you're going to be redirected directly to the Bitcoin Core configuration step in the wizard, and not the beginning.

Let me know if it's all good on your end as well!

[Shourya742]

@GitGab19 this works now. Another thing: when we’re asked to change the settings, it takes us to the Bitcoin setup page, but it doesn’t unselect the previous bitcoin-core selection. This makes it difficult to see what needs to be changed. I think we should unselect it so the required changes are immediately visible. Rest looks ok.

[GitGab19]

@GitGab19 this works now. Another thing: when we’re asked to change the settings, it takes us to the Bitcoin setup page, but it doesn’t unselect the previous bitcoin-core selection. This makes it difficult to see what needs to be changed. I think we should unselect it so the required changes are immediately visible. Rest looks ok.

@Shourya742 I introduced a new commit (380dca7) to handle this, let me know if it works on your end.

[lucasbalieiro]

I was able to test several scenarios like setting the wrong and correct versions of bitcoin core and some variants of the same test and the things were working as expected.

About the code, seems good enough

[Shourya742]

ACK. Flows seems ok