forked from pool/bitcoin
Accepting request 973243 from home:develop7:branches:network:cryptocurrencies
+ disabled tests to fix Tumbleweed build + updated source tarball URL per the upstream recommendation + drop 24104.patch: fixed upstream + Update to version 0.22.0 OBS-URL: https://build.opensuse.org/request/show/973243 OBS-URL: https://build.opensuse.org/package/show/network:cryptocurrencies/bitcoin?expand=0&rev=45
This commit is contained in:
Martin Pluskal
committed by
Git OBS Bridge
Git OBS Bridge
parent
b3b3a3975f
commit
6cfd88aaf9
156
bitcoin.changes
156
bitcoin.changes
@@ -1,3 +1,159 @@
|
||||
-------------------------------------------------------------------
|
||||
Fri Apr 22 13:11:18 UTC 2022 - Andrei Dziahel <develop7@develop7.info>
|
||||
|
||||
+ disabled tests to fix Tumbleweed build
|
||||
|
||||
+ updated source tarball URL per the upstream recommendation
|
||||
|
||||
+ drop 24104.patch: fixed upstream
|
||||
|
||||
+ Update to version 0.22.0
|
||||
* P2P and network changes
|
||||
- Added support for running Bitcoin Core as an
|
||||
[I2P (Invisible Internet Project)](https://en.wikipedia.org/wiki/I2P) service
|
||||
and connect to such services. See [i2p.md](https://github.com/bitcoin/bitcoin/blob/22.x/doc/i2p.md) for details. (#20685)
|
||||
- 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](https://blog.torproject.org/v2-deprecation-timeline) 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`. (#22050)
|
||||
- Added NAT-PMP port mapping support via
|
||||
[`libnatpmp`](https://miniupnp.tuxfamily.org/libnatpmp.html). (#18077)
|
||||
* New and Updated RPCs
|
||||
- Due to [BIP 350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)
|
||||
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](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)).
|
||||
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). (#20861)
|
||||
- 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. (#19776)
|
||||
- `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. (#20755)
|
||||
- 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. (#20286)
|
||||
- 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. (#20286)
|
||||
- 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`. (#21602)
|
||||
- The `setban` RPC can ban onion addresses again. This fixes a regression introduced in version 0.21.0. (#20852)
|
||||
- The `getnodeaddresses` RPC now returns a "network" field indicating the
|
||||
network type (ipv4, ipv6, onion, or i2p) for each address. (#21594)
|
||||
- `getnodeaddresses` now also accepts a "network" argument (ipv4, ipv6, onion,
|
||||
or i2p) to return only addresses of the specified network. (#21843)
|
||||
- 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. (#20833)
|
||||
- `addmultisigaddress` and `createmultisig` now support up to 20 keys for
|
||||
Segwit addresses. (#20867)
|
||||
Changes to Wallet or GUI related RPCs can be found in the GUI or Wallet section below.
|
||||
|
||||
* Build System
|
||||
- Release binaries are now produced using the new `guix`-based build system.
|
||||
The [/doc/release-process.md](/doc/release-process.md) document has been updated accordingly.
|
||||
|
||||
* Files
|
||||
- The list of banned hosts and networks (via `setban` RPC) is now saved on disk
|
||||
in JSON format in `banlist.json` instead of `banlist.dat`. `banlist.dat` is
|
||||
only read on startup if `banlist.json` is not present. Changes are only written to the new
|
||||
`banlist.json`. A future version of Bitcoin Core may completely ignore
|
||||
`banlist.dat`. (#20966)
|
||||
|
||||
* New settings
|
||||
- The `-natpmp` option has been added to use NAT-PMP to map the listening port.
|
||||
If both UPnP and NAT-PMP are enabled, a successful allocation from UPnP
|
||||
prevails over one from NAT-PMP. (#18077)
|
||||
|
||||
* Updated settings
|
||||
Changes to Wallet or GUI related settings can be found in the GUI or Wallet section below.
|
||||
- Passing an invalid `-rpcauth` argument now cause bitcoind to fail to start. (#20461)
|
||||
|
||||
* Tools and Utilities
|
||||
- A new CLI `-addrinfo` command returns the number of addresses known to the
|
||||
node per network type (including Tor v2 versus v3) and total. This can be
|
||||
useful to see if the node knows enough addresses in a network to use options
|
||||
like `-onlynet=<network>` or to upgrade to this release of Bitcoin Core 22.0
|
||||
that supports Tor v3 only. (#21595)
|
||||
|
||||
- A new `-rpcwaittimeout` argument to `bitcoin-cli` sets the timeout
|
||||
in seconds to use with `-rpcwait`. If the timeout expires,
|
||||
`bitcoin-cli` will report a failure. (#21056)
|
||||
|
||||
* Wallet
|
||||
- External signers such as hardware wallets can now be used through the new
|
||||
RPC methods `enumeratesigners` and `displayaddress`. Support is also added
|
||||
to the `send` RPC call. This feature is experimental. See
|
||||
[external-signer.md](https://github.com/bitcoin/bitcoin/blob/22.x/doc/external-signer.md)
|
||||
for details. (#16546)
|
||||
- A new `listdescriptors` RPC is available to inspect the contents of descriptor-enabled wallets.
|
||||
The RPC returns public versions of all imported descriptors, including their timestamp and flags.
|
||||
For ranged descriptors, it also returns the range boundaries and the next index to generate addresses from. (#20226)
|
||||
- The `bumpfee` RPC is not available with wallets that have private keys
|
||||
disabled. `psbtbumpfee` can be used instead. (#20891)
|
||||
- The `fundrawtransaction`, `send` and `walletcreatefundedpsbt` RPCs now support an `include_unsafe` option
|
||||
that when `true` allows using unsafe inputs to fund the transaction.
|
||||
Note that the resulting transaction may become invalid if one of the unsafe inputs disappears.
|
||||
If that happens, the transaction must be funded with different inputs and republished. (#21359)
|
||||
- We now support up to 20 keys in `multi()` and `sortedmulti()` descriptors
|
||||
under `wsh()`. (#20867)
|
||||
- Taproot descriptors can be imported into the wallet only after activation
|
||||
has occurred on the network (e.g. mainnet, testnet, signet) in use. See
|
||||
[descriptors.md](https://github.com/bitcoin/bitcoin/blob/22.x/doc/descriptors.md)
|
||||
for supported descriptors.
|
||||
|
||||
* GUI changes
|
||||
- External signers such as hardware wallets can now be used. These require
|
||||
an external tool such as [HWI](https://github.com/bitcoin-core/HWI) to be
|
||||
installed and configured under Options -> Wallet. When creating a new
|
||||
wallet a new option "External signer" will appear in the dialog. If the
|
||||
device is detected, its name is suggested as the wallet name. The
|
||||
watch-only keys are then automatically imported. Receive addresses can be
|
||||
verified on the device. The send dialog will automatically use the
|
||||
connected device. This feature is experimental and the UI may freeze for
|
||||
a few seconds when performing these actions.
|
||||
|
||||
* RPC
|
||||
- The RPC server can process a limited number of simultaneous RPC requests.
|
||||
Previously, if this limit was exceeded, the RPC server would respond with
|
||||
[status code 500 (`HTTP_INTERNAL_SERVER_ERROR`)](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_server_errors).
|
||||
Now it returns status code 503 (`HTTP_SERVICE_UNAVAILABLE`). (#18335)
|
||||
|
||||
- Error codes have been updated to be more accurate for the following error cases (#18466):
|
||||
- `signmessage` now returns RPC_INVALID_ADDRESS_OR_KEY (-5) if the
|
||||
passed address is invalid. Previously returned RPC_TYPE_ERROR (-3).
|
||||
- `verifymessage` now returns RPC_INVALID_ADDRESS_OR_KEY (-5) if the
|
||||
passed address is invalid. Previously returned RPC_TYPE_ERROR (-3).
|
||||
- `verifymessage` now returns RPC_TYPE_ERROR (-3) if the passed signature
|
||||
is malformed. Previously returned RPC_INVALID_ADDRESS_OR_KEY (-5).
|
||||
* See release-notes-22.0.md for complete changelog
|
||||
|
||||
-------------------------------------------------------------------
|
||||
Mon Jan 24 05:07:54 UTC 2022 - Bernhard Wiedemann <bwiedemann@suse.com>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user