Is anyone using this for p2sh-multisig (passing the redeemscript into decodescript)?

"addresses" for multisigs don't make sense without "reqSigs"

IMO if we deprecate/remove the latter, we should also be sure to remove the former with it.

("addresses" should remain for actual address outputs)

"addresses" for multisigs don't make sense without "reqSigs"

IMO if we deprecate/remove the latter, we should also be sure to remove the former with it.

("addresses" should remain for actual address outputs)

If we were to remove addresses for multisigs it seems to me we'd be able to get rid of ExtractDestinations entirely, as this is the only thing it's used for currently, and ExtractDestination can be used instead.

It also makes me think {RPCResult::Type::ARR, "addresses", "array of bitcoin addresses"} is a bit misleading, and would ideally be a single {RPCResult::Type::STR, "address", "bitcoin address"}.

We'd be able to get rid of a nice chunk of code (and potentially confusing behavior). But I'm new to this repo, and I need some guidance on what should be done here. And also if I need to deprecate stuff and how I should proceed if so.

Note: there is always the easy option of just fixing the reqSigs behavior instead of removing it. But, I guess it's unused and we can get rid of some cruft by removing it. Please advise!

Concept ACK on removing both "reqSigs" and "addresses", but it'll need to go through the RPC deprecation mechanism.

In other places we have already removed similar fields. Especially "addresses" is a bizarre and misleading leftover from a time when addresses were only ever P2PKH and just "key identifiers". Now (... since P2SH in 2012) addresses are encodings of a specific scriptPubKey it makes no sense whatsoever that multisig is treated as "multiple addresses".

Note: there is always the easy option of just fixing the reqSigs behavior instead of removing it.

If it's broken, we should fix it (for backporting) before removing.

It also makes me think {RPCResult::Type::ARR, "addresses", "array of bitcoin addresses"} is a bit misleading, and would ideally be a single {RPCResult::Type::STR, "address", "bitcoin address"}.

I'm not sure the array format is entirely/hypothetically useless. Might as well leave it alone (or at least propose this change separately).

I've re-worked this PR, and force pushed, based on the convo/feedback in this thread. Broken into two commits:

1. f5d3cf6 "fixes" reqSigs. Instead of defaulting to 1 which is confusing (and possibly incorrect?) reqSigs is not included in rpc outputs unless the transaction is a bare multisig.
2. c0545cc deprecates reqSigs as discussed, where reqSigs is totally removed from rpc outputs, and addresses is no longer returned for bare multsigs. c0545cc#diff-80ada085034954b397668e082d78cd40519aa9b162ec52101651dd48c48a17b3L18-L24 basically becomes a functional test, where we check the default case, and -deprecatedrpc=reqSigs are both correct

Note: This PR turned out to be more involved than I expected. I'll probably need some more feedback and pointers to get this across the finish line.

Also: we'll be able to delete a few chunks of code when we can get rid of -deprecatedrpc=reqSigs. I indicate this in the source with TODO comments.

@mjdietzx I think it's a bit weird to fix "addresses"/"reqSigs", as it's making a semantics change simultaneously with a deprecation.

My suggestion would be to:

• add a new sane "address" field (for outputs that have an identifiable address, which doesn't include bare multisig)
• with -deprecatedrpc: leave "reqSigs" and "addresses" intact (with all weird/wrong behavior they have now)
• without -deprecatedrpc: drop "reqSigs" and "addresses" entirely, always.

That means that anyone who is currently relying on the weird `"reqSigs": `` behavior for unknown address types (for who knows what reason) isn't affected if they set the deprecation option.

I like the approach you've outlined @sipa. Any objections before I go ahead and do this @luke-jr? I know you weren't quite convinced re: addresses => address.

I'd prefer to keep a single-item array (better compatibility, and future-proof), but I don't care enough to object.

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

• rpc: Missing doc updates for bumpfee psbt update #21544 (rpc: Missing doc updates for bumpfee psbt update by MarcoFalke)
• refactor: replace util::Ref with std::any (C++17) #21366 (refactor: replace util::Ref with std::any (C++17) by theStack)
• Implement BIP 370 PSBTv2 #21283 (Implement BIP 370 PSBTv2 by achow101)
• rpc: Add level 3 verbosity to getblock RPC call. #21245 (rpc: Add level 3 verbosity to getblock RPC call. by fyquah)
• test: Run rpc_generateblock.py even with wallet disabled #20808 (test: Run rpc_generateblock.py even with wallet disabled by nginocchio)

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.

I'll need to re-work some of the functional tests (will get this committed soon) now that addresses is removed by default, but 162e7f0 updates this PR to be as @sipa suggested

Piggy backing off of #20211, now that we have:

bool ExtractDestination(const CScript& scriptPubKey, TxoutType& typeRet, CTxDestination& addressRet);

Could we do something like:

TxoutType type;
CTxDestination dest;
ExtractDestination(m_script, type, dest);
switch (type) {
case TxoutType::PUBKEYHASH:
case TxoutType::SCRIPTHASH: return OutputType::LEGACY;
case TxoutType::WITNESS_V0_SCRIPTHASH:
case TxoutType::WITNESS_V0_KEYHASH:
case TxoutType::WITNESS_V1_TAPROOT:
case TxoutType::WITNESS_UNKNOWN: return OutputType::BECH32;
case TxoutType::PUBKEY:
case TxoutType::MULTISIG:
case TxoutType::NONSTANDARD:
case TxoutType::NULL_DATA: return nullopt; // no default case, so the compiler can warn about missing cases
}
assert(false);

Instead of what we have now:

CTxDestination dest;
ExtractDestination(m_script, dest);
switch (dest.which()) {
  case 1 /* PKHash */:
  case 2 /* ScriptHash */: return OutputType::LEGACY;
  case 3 /* WitnessV0ScriptHash */:
  case 4 /* WitnessV0KeyHash */:
  case 5 /* WitnessUnknown */: return OutputType::BECH32;
  case 0 /* CNoDestination */:
  default: return nullopt;
}

Note: I messed around with this, and probably made some mistakes here, but didn't see any unit tests or functional tests fail. So maybe some test coverage is needed here as well?

re-ACK 0d83a7326385bf012c1a34d766b96af11fa88979 only change is rebase 🤸

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

re-ACK 0d83a7326385bf012c1a34d766b96af11fa88979 only change is rebase 🤸
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
pUhYywwAjgK4ihIQ39KVE2lzOU0k1tOoysgSg2R0ecgHzTn7dVymB6zzYYv6EUxX
MSafRTRy9PoTxs7yIijFvI7KeYGMNVfjoz31UvB17ecxPAUetuHR8spLAmmVtdf/
po8kLlJ91r88oUK/of56Mt9jzrIo/UPnjuoznCeRaYgTDo4QQoB/t9l+ZJqA/JCK
Z//4UJDu3cV3fVSa1bnoj+V0aw2GRGt33D7ZFo6+aav3ISbT2E+yMcarBR5Osb3A
nQbXU0DhVb5xv9HOl3tNFQA2i1TllJ63uDSgB+J0ylA9muEmfQJ+6hclkjEzppop
JS3gMNPC1OWU6tj4KCwK/F6tPdSr4sef217IwyQOQpdLU+zn6ojIIPdThPCPBJ0U
pToy32H+zeX4lQJV/3H2st8ylGs4ba2vIHe0Heo6hdOqkUPmk0q/NOBYLK0gRljh
H/y728bGj+aAw4GWh48x0B+3WgRylmjgw+Zk6Zsppg4P6V3nK79lIkgKSKESnzHx
gX/dFts/
=l+z1
-----END PGP SIGNATURE-----

@sipa Mind to re-ACK? Should be close to merge, hopefully.

re-ACK 90ae3d8 📢

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

re-ACK 90ae3d8ca68334ec712d67b21a8d4721c6d79788 📢
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
pUg6IAv+Ol7ckNRTmCxL9Ko6DB0jxK62hxEeAODWHiXIrB9y/1wT7WScw8VIBSRn
3p9VIwDE/+WXoU1OUXJcUfszI/vGoWkZO/uO91fQ3ZmN683+55zkh+5t6qIuSXWU
9aqb4EZEhiJtwa1NZOBohZCSdU1c/ogwUN0jn2WNhZwoGR7fccpay5L8K3cLpu3Y
83pCYZ29WrxGeKgq1iV+mW018oh6+/7OvgBEujnM+4qerRDHps/J8fyNBYGuIY8a
iK32n//OmKxP57lY1kbHlUjL5KXW/EWtQiu7srqJsOoi0+ypmCGvDepF3gpbnOVV
OKchPIDkOPBggEQzAF6AeLPUtr+/K6+sZkpImlmo/xvF0KRuwHrUh8f18N/2vZws
zyC5pkSLP+ChVXfW7HnjjmRC3ax5y3bR42XJm5wIXYk4+QLmXMQPqMe+RzxZVr+4
SNaQ8vWQZSSbl+X01TGgyTatrF7dwYtgpLRSImf6C5SXZXB16VLCLoqx+zr3EI3/
gMbBV9Eo
=TB20
-----END PGP SIGNATURE-----