`decodescript` returns wrong reqSigs for complex scripts #20754

This issue may be related to #20102 but I don't think it is, because I get the expected reqSigs for other p2sh / p2wsh scripts.

Create a redeem script that includes both OP_CHECKMULTISIG and some other condition such as OP_CHECKLOCKTIMEVERIFY

Feed the redeem script into the decodescript RPC

Expected behavior

I expect reqSigs to match the number corresponding to the OP_CHECKMULTISIG portion of the redeem script.

Actual behavior

The output has "reqSigs" set to 1.

To reproduce

Example script:

$ ./bitcoin-cli -testnet -named decodescript hexstring=03bcef1cb175532102e47b8a3f7cd012c08369814af843cbb545cf9ba7f8e037d385e6213678a7f272210364c573ac74edd46bfa3e6ae1cd3aad2c6607af0a8d6ff3751147a8d73c6968d52102173becdbff83c43653d0273838a774d6ae42e1ea63ad7b9af53bd7b65bbbb04321033eb39dedc8527c796a9d619ba3ed3e9f611ef3fbb76a33b42806c0d138124a0021037a40c9aaa3c402ac95b0072dfe6e48486e30c0c0138aef7544e325d0b8faaa4e55ae

{
  "asm": "1896380 OP_CHECKLOCKTIMEVERIFY OP_DROP 3 02e47b8a3f7cd012c08369814af843cbb545cf9ba7f8e037d385e6213678a7f272 0364c573ac74edd46bfa3e6ae1cd3aad2c6607af0a8d6ff3751147a8d73c6968d5 02173becdbff83c43653d0273838a774d6ae42e1ea63ad7b9af53bd7b65bbbb043 033eb39dedc8527c796a9d619ba3ed3e9f611ef3fbb76a33b42806c0d138124a00 037a40c9aaa3c402ac95b0072dfe6e48486e30c0c0138aef7544e325d0b8faaa4e 5 OP_CHECKMULTISIG",
  "type": "nonstandard",
  "p2sh": "2MtWVwxQiEeHaUNB6YgAWDo2fiLb5pivGrJ",
  "segwit": {
    "asm": "0 9767ecace7e49ced3cfa047924760497cb4717473b1ef35d3227d6a23360fa4a",
    "hex": "00209767ecace7e49ced3cfa047924760497cb4717473b1ef35d3227d6a23360fa4a",
    "reqSigs": 1,
    "type": "witness_v0_scripthash",
    "addresses": [
      "tb1qjan7et88ujww6086q3ujgasyjl95w9688v00xhfjylt2yvmqlf9qzpqkl5"
    ],
    "p2sh-segwit": "2Mu6nuTgpQ4cC7S557FXidPHa1WbzqEr3uN"
  }
}

System information

Bitcoin Core 0.20.1

Ubuntu 20.04

Using bitcoin-cli against local node.

See #20286

"type": "nonstandard",

Our parser can only calculate reqSigs for type multisig, not for unknown ones. They are called "nonstandard" scripts, which obviously has no meaning for redeem scripts either.

It's still confusing though; it should never have reported a reqSigs field for something it doesn't understand.

We should just get rid of the field, and make it report descriptors for things it understand or so.

This is maybe a duplicate of #20102.

This is maybe a duplicate of #20102.

Seems to be the same as #20102 to me.

because I get the expected reqSigs for other p2sh / p2wsh scripts

I guess it was a multisig wrapped in the other p2sh / p2wsh scripts you tested? So segwit.type was multisig in those responses? Or you got lucky and the hardcoded reqSigs == 1 was what you were expecting?

Anyways, we're getting rid of this confusing behavior in #20286, and I ran this test on that branch:

$ ./src/bitcoin-cli -named decodescript hexstring=03bcef1cb175532102e47b8a3f7cd012c08369814af843cbb545cf9ba7f8e037d385e6213678a7f272210364c573ac74edd46bfa3e6ae1cd3aad2c6607af0a8d6ff3751147a8d73c6968d52102173becdbff83c43653d0273838a774d6ae42e1ea63ad7b9af53bd7b65bbbb04321033eb39dedc8527c796a9d619ba3ed3e9f611ef3fbb76a33b42806c0d138124a0021037a40c9aaa3c402ac95b0072dfe6e48486e30c0c0138aef7544e325d0b8faaa4e55ae

{
  "asm": "1896380 OP_CHECKLOCKTIMEVERIFY OP_DROP 3 02e47b8a3f7cd012c08369814af843cbb545cf9ba7f8e037d385e6213678a7f272 0364c573ac74edd46bfa3e6ae1cd3aad2c6607af0a8d6ff3751147a8d73c6968d5 02173becdbff83c43653d0273838a774d6ae42e1ea63ad7b9af53bd7b65bbbb043 033eb39dedc8527c796a9d619ba3ed3e9f611ef3fbb76a33b42806c0d138124a00 037a40c9aaa3c402ac95b0072dfe6e48486e30c0c0138aef7544e325d0b8faaa4e 5 OP_CHECKMULTISIG",
  "type": "nonstandard",
  "p2sh": "32xHtDUgdBnEGaYYsYYdbr3QVzNuzfyegh",
  "segwit": {
    "asm": "0 9767ecace7e49ced3cfa047924760497cb4717473b1ef35d3227d6a23360fa4a",
    "hex": "00209767ecace7e49ced3cfa047924760497cb4717473b1ef35d3227d6a23360fa4a",
    "address": "bc1qjan7et88ujww6086q3ujgasyjl95w9688v00xhfjylt2yvmqlf9q4fke9m",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "33Yaqiknnc6queSXS7ur1SJJoAPpyX3wM3"
  }
}

Based on sipa and mjdietzx's comments, closing this to push future discussion to #20102 and #20286.