Add new bitcoin_rw.conf file that is used for settings modified by this software itself

[luke-jr]

This is part of #7510, without the new GUI settings (ie, just the minimal framework for the RW conf file).

[Sjors]

I'm not a big fan of multiple config files. I would prefer if QT just edited bitcoin.conf and tells the user to do so manually if things gets too complicated. See also #6461.

[Sjors]

I tried just making bitcoin.conf writeable instead of having two files in #12833, but that seems to raise some objections. So in that case: Concept ACK.

Can you rebase this? From my experience with the other PR that should be easy and it worked quite well.

[luke-jr]

Rebased

[Sjors]

tACK aac0501 (tested through #12833)

[Sjors]

Needs another rebase due to #11862. Perhaps not worth the effort without more Concept ACKs.

[ajtowns]

ConceptACK. This approach isn't any worse than QSettings, and seems more consistent, and discoverable when anything weird is happening due to conflicting/unexpected settings.

[ajtowns]

Wouldn't it be better for ReadRWConfigFile not to throw exceptions in any normal case? If there's a weird setting, that's fine it will just get over-written later; if the file is read-only though that error should at least be reported to the user; and if there's some other unexpected sort of error that throws an exception, then that shouldn't be ignored?

[maflcko]

Let me know when I can add this back to project 8, i.e. when it is ready for review.

[luke-jr]

Finally rebased (and ready for high-pri for review I think).

Edit: Forgot #14532 was in high-pri still. This will have to wait I guess.

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• refactor: Implement missing error checking for ArgsManager flags #16545 (refactor: Implement missing error checking for ArgsManager flags by ryanofsky)
• [wip] util: Improve evaluation of includeconf lines in network sections of the config file #14866 ([wip] util: Improve evaluation of includeconf lines in network sections of the config file by AkioNak)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

[Sjors]

Thanks for the rebase! Works like a charm on my freshly rebased #12833.

Does bitcoin-cli really also need to parse this? I have a light preference for disallowing settings in -confrw that change how bitcoin-cli should behave, i.e.:

• datadir: this always need to be in QTSettings anyway
• RPC connection info (if someone really needs a custom host/port/binding and non-cookie authentication, they know how to edit bitcoin.conf)
• mainnet / testnet / regtest (the GUI can just have a toggle for this, bitcoind users know how to edit the config file, and/or can just use -testnet)

Reason for this preference is that it makes the life easier for other tools to parse the settings. E.g. wallet_tool #13926 might in the future want to parse bitcoin.conf, and external projects like c-lightning already do/did this.

[luke-jr]

Rebased

[jnewbery]

I'm not sure this is needed now that we have the settings.json file. @luke-jr, can you explain why we should consider adding another settings file?

[luke-jr]

So we can revert settings.json before 0.21 is released and we're locked in to supporting such a bad idea?

[jnewbery]

NACK. Let's close this and move on.

[Sjors]

I have no objection to swapping the new settings.json out for bitcoin_rw.conf before the release, if this gets enough review. But I probably won't review this, because I don't think the difference is worth it. I don't expect users to manually read or edit this, since they can already access bitcoin.conf. So the choice of file format seems irrelevant.

The (rather large amount of) code in ModifyRWConfigStream presents entirely new file parsing. It would both be more useful, and easier to review, if it was also used to parse bitcoin.conf.

[fanquake]

Now that we've branched off, and are unlikely to be reverting settings.json, I'm going to close this PR.