rpc: Deprecate the RPC createmultisig #24638

It was discussed on IRC that the utility RPC createmultisig is old and pretty pointless (even more so than when it was introduced) and that the deriveaddresses RPC can do everything createmultisig can do. Hence deprecate the createmultisig RPC.

Useful skills:

Basic understanding of the Bitcoin Core RPC interface and deprecation process. If and when the RPC is deprecated the functional test rpc_createmultisig.py can also be removed.

Want to work on this issue?

For guidance on contributing, please read CONTRIBUTING.md before opening your pull request.

rpc_createmultisig also checks addmultisigaddress, so I don't think it can be removed after removing createmultisig.

Also, on a general (maybe unrelated note). I am not a fan of deprecating features because there is another way to achieve something. This will put frustration and mental burden on our users, so there should be a convincing motivation for the deprecation. If it is expensive for us to maintain the createmultisig logic, then it can go. However, if the code is mostly sitting around idle and working fine, I don't see a great maintenance benefit in removing it. Simply updating the documentation to mention the new RPC should be enough, like I did for getunconfirmedbalance (instead of removing it).

rpc_createmultisig also checks addmultisigaddress, so I don't think it can be removed after removing createmultisig

A smaller test called something like rpc_addmultisigaddress perhaps? @MarcoFalke: This is the argument against deprecating it. Every RPC has a maintenance cost though e.g. regularly running the associated RPC test and debugging of that test (#20183). Taking this perspective to the extreme ends up with a bunch of overlapping RPCs, no one knows why they are there (not a good user experience) and an ever expanding set of useless functional tests (not a good developer experience).

#20183 has nothing to do with the createmultisig RPC. It was a general issue of the user running a lot of functional tests on slow hardware, running into timeouts. The issue would have existed even if the createmultisig RPC was already removed with the test. Even if the issue was related to the RPC, I think having to debug a test issue once a year (or having to do minimal maintenance like bumping the copyright header once a year on the file) is an acceptable cost. And there will (either intentionally or accidentally) always be overlapping RPCs. If this was something to avoid, we could start removing almost all optional features.

I am not against adding documentation to clarify that another RPC exists and that one of them is considered "soft" deprecated. I am against forcing users to either run vulnerable EOL versions of the software or make them potentially rework their whole software stack during an upgrade for no reason (or a weak one).

Never deprecating a RPC and associated test ever again (and only adding to the list of RPCs, RPC tests) doesn't sound great to me but fair enough. I'll close this.

I am not against adding documentation to clarify that another RPC exists and that one of them is considered "soft" deprecated.

Ok thanks, I'll consider doing this.

For now added a StackExchange post on the createmultisig RPC.

For now added a StackExchange post on the createmultisig RPC.

I was expecting an example in the answer. It would help users.

bitcoin-cli createmultisig 2 "["03789ed0bb717d88f7d321a368d905e7430207ebbd82bd342cf11ae157a7ace5fd","03dbc6764b8884a92e871274b87583e6d5c2a58819473e17e107ef3f6aa5a61626"]"

How can users create 2of2 multisig address from 2 public keys using deriveaddresses?

@1440000bytes:

How can users create 2of2 multisig address from 2 public keys using deriveaddresses?

I think it is just:

bitcoin-cli deriveaddresses "sh(multi(2,<pubkey>,<pubkey>))"

Let me check that though before adding to the StackExchange answer.

FWIW, I suggested that it might be reasonable to deprecate this, mostly because I thought it was pretty outdated (P2SH multisig only, intended for the old annoying multisig workflow that predates descriptors/PSBT and you'd need to supply redeemscript arguments to all RPCs). Turns out that it (and addmultisigaddress) actually underwent a number of changes the last few years I had forgotten about (in particular, supports segwit multisig too, and reports a descriptor).

@sipa: Thanks. If deriveaddresses isn't a strict superset of createmultisigaddress I personally find that a much stronger argument against deprecation than the "someone might still be using it" argument. I get that there's subtleties here that I'm most likely misunderstanding too.

I am pretty sure that deriveaddresses is still a strict superset of createmultisigaddress.

I also still think that it helps to mention deriveaddresses in the createmultisigaddress help.

Yes, it's a strict superset.

My point is that I was just wrong about how useful createmultisig still is.