Update knots to v29.3.knots?

[Retropex]

@tehelsper this change will be for the next version of Knots (URL aren't updated yet since there is no official release), since SF should never happen in a auto update I'm not sure how to handle knots_autoupdate, we can either not provide it the auto update or prompt the user something once he install the new version of mynode.
Let me know how you want to proceed!

Description

Add a prompt to inform the user that the new Knots release add consensus rules changes, the user must confirm to install the new version.

Checklist

• tested successfully on local MyNode, if yes, list the device(s) below
• mentioned related open issue, if any

List of test device(s)

VM

[tehelsper]

It looks like we could separate the SF from the upgrade, right? I'd prefer the option to install Knots without the soft fork config and then make the soft fork config an option on the main Bitcoin page (only visible if a supporting knots version is installed). That way users could upgrade and get the option for additional settings.

There's already a concept for writing Bitcoin config to an env file for the bitcoin service to specify args. Additionally, if a RDTS option is set, could it just influence the Bitcoin config file? That could be added in the Bitcoin pre startup script. I'm not sure if rdts can be set via config though or if it's only specifiable as an argument.

See this example. It does get cleared each reboot at the moment.
https://github.com/mynodebtc/mynode/blob/master/rootfs/standard/var/www/mynode/settings.py#L508

I'd prefer a config based approach vs the argument approach if possible.

Edit: Also, the intent is for new Knots versions to be auto-upgradable if a user chooses the Knots Autoupgrade choice. It should always match the latest version of Knots.

[Retropex]

It looks like we could separate the SF from the upgrade, right?

No, the current version of Knots will be the last one without RDTS.

There's already a concept for writing Bitcoin config to an env file for the bitcoin service to specify args.

Yeah, that's what I used for my PR, see this.

Also, the intent is for new Knots versions to be auto-upgradable if a user chooses the Knots Autoupgrade choice. It should always match the latest version of Knots.

Ok so I will update the links too once it comes out but we absolutely need to inform the user that the rules that Knots enforce has changed. Perhaps a one time pop up?

[tehelsper]

So why is the command line argument necessary? Just to be more obvious about the SF? What would happen if you ran an upcoming Knots version without the command line arg?

OK, well, maybe we're lucky then. The Knots autoupdate has not been released yet, so if we just add a warning popup for this explicit knots version as well as the knots autoupdate choice, then no one will be auto-updated into a soft fork.

Ha, your right on the env file. That's what I get for late night reviews. Still, is there not a way to move that to the config file? I don't love the design of having to write that each time since the env file is currently used for temporary flags.

[tehelsper]

OK, I actually did some research this time and found the config file option should work. This would all you to do a check and append the line in the mynode_gen_bitcoin_config.sh script.

Also, it looks like Knots may publish both Knots (vanilla) and Knots (RDTS). Maybe the better option now would be to rearrange this into the BIP 110 auto-update and also update Knots, but use the non-RDTS version. They user-facing choices are already labeled as:

Bitcoin Knots + BIP-110 (latest)
Bitcoin Knots (latest)

That way, the RDTS is already in the name of the choice they are making. A popup to go along with it would still be a good idea.

Ref: https://gist.github.com/luke-jr/5518222e7493b612d8f1595afc99ff7c

[Retropex]

Yeah the next Knots release is still in RC and can be subject to changes, I will coordinate with Luke and get back to this PR.

Thanks for your time!