Add address field (rpc client & server)

[lindlof]

Bitcoin Core has added address field and removed addresses and reqSigs rpc response fields. The fields were deprecated on version 22 and they've been removed from version 23. For instance, the following methods are affected:

• https://bitcoincore.org/en/doc/22.0.0/rpc/rawtransactions/getrawtransaction/
• https://bitcoincore.org/en/doc/22.0.0/rpc/rawtransactions/decoderawtransaction/
• https://bitcoincore.org/en/doc/22.0.0/rpc/blockchain/gettxout/

This PR adds the new address and deprecates the removed fields.

Closes #1874

[coveralls]

Pull Request Test Coverage Report for Build 5193275574

• 0 of 15 (0.0%) changed or added relevant lines in 1 file are covered.
• 10 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.02%) to 55.252%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
rpcserver.go	0	15	0.0%

Files with Coverage Reduction	New Missed Lines	%
rpcserver.go	3	0.26%
peer/peer.go	7	73.2%

Totals
Change from base Build 5075515644:	-0.02%
Covered Lines:	26665
Relevant Lines:	48261

---

💛 - Coveralls

[bog-h]

PR looks fine! I wanted to open a similar PR because we now receive the address field from the node and don't have it in the result.

[guggero]

I don't think we want to break backward compatibility with Bitcoin Core 0.21 or earlier. So I think the proper fix would be to accept both fields and then parse the one that's actually being set by the chain backend.

[lindlof]

Okay @guggero I've left the deprecated fields in. The commit to remove them exists in lindlof@faae231

[guggero]

Are we sure the reqSigs is always set to 1 on old versions? Can't we just omit that condition? And I guess a comment above about why we do this (backward compatibility) would be useful too.

[lindlof]

Added the condition because if more than 1 signatures are required then we shouldn't consider the address to be the only address. This could result in terrible bugs, such as the consumer believing they have received the Bitcoin when it's actually in a multisig.

I'll double-check and can add a comment and make it also accept 0 as long as an address is available. The reqSigs should be correct but I agree it makes sense for this to be robust.

[lindlof]

Added a comment and changed the reqSigs check to also accept 0. ExtractPkScriptAddrs simply returns the reqSigs as 1 whenever an address is returned, except for multisig which has more logic for reqSigs and where checking the value of reqSigs is more interesting.

[kcalvinalvin]

Also checked that ExtractPkScriptAddrs returns a single address and reqSigs == 1 for P2PKH, P2WPKH, P2SH, P2WSH, and P2TR.

The change would only be meaningful to non standard multi-sig.

[guggero]

utACK

[ygaberman-px]

@guggero @bog-h is there anything preventing from merging this in? This would be really helpful for me

[guggero]

I guess another review from someone who has more experience with the code base than myself would be great. Any volunteers, @Roasbeef, @kcalvinalvin, @chappjc?

[kcalvinalvin]

ACK fcf291947d51896664e848526482983a5cbb72db26fa1d78649c3d051cf602fc

Also tested by calling getrawtransaction, decoderawtransaction, and gettxout to a Bitcoin Core node. Works well.