Log Message:
finance/bitcoin: update to version 22.0

Notable changes:

- P2P and network changes

  * Added support for running Bitcoin Core as an I2P (Invisible Internet
    Project) service and connect to such services. See i2p.md for details.
  * This release removes support for Tor version 2 hidden services in favor of
    Tor v3 only, as the Tor network dropped support for Tor v2 with the release
    of Tor version 0.4.6. Henceforth, Bitcoin Core ignores Tor v2 addresses; it
    neither rumors them over the network to other peers, nor stores them in
    memory or to peers.dat.
  * Added NAT-PMP port mapping support via libnatpmp.

- New and Updated RPCs

  * Due to BIP 350 being implemented, behavior for all RPCs that accept
    addresses is changed when a native witness version 1 (or higher) is passed.
    These now require a Bech32m encoding instead of a Bech32 one, and Bech32m
    encoding will be used for such addresses in RPC output as well. No version 1
    addresses should be created for mainnet until consensus rules are adopted
    that give them meaning (as will happen through BIP 341). Once that happens,
    Bech32m is expected to be used for them, so this shouldn't affect any
    production systems, but may be observed on other networks where such addresses
    already have meaning (like signet).
  * The getpeerinfo RPC returns two new boolean fields, bip152_hb_to and
    bip152_hb_from, that respectively indicate whether we selected a peer to be
    in compact blocks high-bandwidth mode or whether a peer selected us as a
    compact blocks high-bandwidth peer. High-bandwidth peers send new block
    announcements via a cmpctblock message rather than the usual inv/headers
    announcements. See BIP 152 for more details.
  * getpeerinfo no longer returns the following fields: addnode, banscore, and
    whitelisted, which were previously deprecated in 0.21. Instead of addnode,
    the connection_type field returns manual. Instead of whitelisted, the
    permissions field indicates if the peer has special privileges. The
    banscore field has simply been removed.
  * The following RPCs: gettxout, getrawtransaction, decoderawtransaction,
    decodescript, gettransaction, and REST endpoints: /rest/tx, /rest/getutxos,
    /rest/block deprecated the following fields (which are no longer returned in
    the responses by default): addresses, reqSigs. The -deprecatedrpc=addresses
    flag must be passed for these fields to be included in the RPC response.
    This flag/option will be available only for this major release, after which
    the deprecation will be removed entirely. Note that these fields are
    attributes of the scriptPubKey object returned in the RPC response. However,
    in the response of decodescript these fields are top-level attributes, and
    included again as attributes of the scriptPubKey object.
  * When creating a hex-encoded bitcoin transaction using the bitcoin-tx
    utility with the -json option set, the following fields: addresses, reqSigs
    are no longer returned in the tx output of the response.
  * The listbanned RPC now returns two new numeric fields: ban_duration and
    time_remaining. Respectively, these new fields indicate the duration of a
    ban and the time remaining until a ban expires, both in seconds.
    Additionally, the ban_created field is repositioned to come before
    banned_until.
  * The setban RPC can ban onion addresses again. This fixes a regression
    introduced in version 0.21.0.
  * The getnodeaddresses RPC now returns a "network" field indicating the
    network type (ipv4, ipv6, onion, or i2p) for each address.
  * getnodeaddresses now also accepts a "network" argument (ipv4, \ 
ipv6, onion,
    or i2p) to return only addresses of the specified network.
  * The testmempoolaccept RPC now accepts multiple transactions (still
    experimental at the moment, API may be unstable). This is intended for
    testing transaction packages with dependency relationships; it is not
    recommended for batch-validating independent transactions. In addition to
    mempool policy, package policies apply: the list cannot contain more than 25
    transactions or have a total size exceeding 101K virtual bytes, and cannot
    conflict with (spend the same inputs as) each other or the mempool, even if
    it would be a valid BIP125 replace-by-fee. There are some known limitations
    to the accuracy of the test accept: it's possible for testmempoolaccept to
    return "allowed"=True for a group of transactions, but
    "too-long-mempool-chain" if they are actually submitted.
  * addmultisigaddress and createmultisig now support up to 20 keys for Segwit
    addresses.

Then also the build system, files, new settings, updated settings, tools and
utilities, wallet, and GUI changes; the full list is at
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-22.0.md.