mirror of
https://github.com/bitcoin/bitcoin.git
synced 2025-06-27 01:11:59 +02:00
Merge #17007: build: 0.19 release updates on master
434101875c69d523ee34afee540212129be06458 doc: reset release notes after 0.19 split-off (Jon Atack) c0859b7dac5f3504d753f5dcd7ee272fdb43bea6 build: 0.19 release updates on master (Jon Atack) Pull request description: Post split-off. As per https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#before-every-major-release and issue #16996. Note: after split-off, the same changes should be made on the new 0.19.0 release branch, with also these additional changes to both files (configure.ac and build_msvc/bitcoin_config.h): - set `CLIENT_VERSION_REVISION` to `0` - set `CLIENT_VERSION_IS_RELEASE` to `true` The second commit resets the release notes after branch-off and proposes a few improvements. ACKs for top commit: laanwj: ACK 434101875c69d523ee34afee540212129be06458 Tree-SHA512: 5a6afeb9cff6fa827865894cc7d3dc789db1c8b5d875ba49fdcfd9fd48af9d2d2864f49a992988136425744af74053cb57a4a92a1665a09b194eecb1a2972315
This commit is contained in:
commit
ecc0f272a0
@ -14,7 +14,7 @@
|
|||||||
#define CLIENT_VERSION_MAJOR 0
|
#define CLIENT_VERSION_MAJOR 0
|
||||||
|
|
||||||
/* Minor version */
|
/* Minor version */
|
||||||
#define CLIENT_VERSION_MINOR 18
|
#define CLIENT_VERSION_MINOR 19
|
||||||
|
|
||||||
/* Build revision */
|
/* Build revision */
|
||||||
#define CLIENT_VERSION_REVISION 99
|
#define CLIENT_VERSION_REVISION 99
|
||||||
@ -346,7 +346,7 @@
|
|||||||
#define PACKAGE_NAME "Bitcoin Core"
|
#define PACKAGE_NAME "Bitcoin Core"
|
||||||
|
|
||||||
/* Define to the full name and version of this package. */
|
/* Define to the full name and version of this package. */
|
||||||
#define PACKAGE_STRING "Bitcoin Core 0.18.99"
|
#define PACKAGE_STRING "Bitcoin Core 0.19.99"
|
||||||
|
|
||||||
/* Define to the one symbol short name of this package. */
|
/* Define to the one symbol short name of this package. */
|
||||||
#define PACKAGE_TARNAME "bitcoin"
|
#define PACKAGE_TARNAME "bitcoin"
|
||||||
@ -355,7 +355,7 @@
|
|||||||
#define PACKAGE_URL "https://bitcoincore.org/"
|
#define PACKAGE_URL "https://bitcoincore.org/"
|
||||||
|
|
||||||
/* Define to the version of this package. */
|
/* Define to the version of this package. */
|
||||||
#define PACKAGE_VERSION "0.18.99"
|
#define PACKAGE_VERSION "0.19.99"
|
||||||
|
|
||||||
/* Define to necessary symbol if this constant uses a non-standard name on
|
/* Define to necessary symbol if this constant uses a non-standard name on
|
||||||
your system. */
|
your system. */
|
||||||
|
@ -1,7 +1,7 @@
|
|||||||
dnl require autoconf 2.60 (AS_ECHO/AS_ECHO_N)
|
dnl require autoconf 2.60 (AS_ECHO/AS_ECHO_N)
|
||||||
AC_PREREQ([2.60])
|
AC_PREREQ([2.60])
|
||||||
define(_CLIENT_VERSION_MAJOR, 0)
|
define(_CLIENT_VERSION_MAJOR, 0)
|
||||||
define(_CLIENT_VERSION_MINOR, 18)
|
define(_CLIENT_VERSION_MINOR, 19)
|
||||||
define(_CLIENT_VERSION_REVISION, 99)
|
define(_CLIENT_VERSION_REVISION, 99)
|
||||||
define(_CLIENT_VERSION_BUILD, 0)
|
define(_CLIENT_VERSION_BUILD, 0)
|
||||||
define(_CLIENT_VERSION_RC, 0)
|
define(_CLIENT_VERSION_RC, 0)
|
||||||
|
@ -39,7 +39,7 @@ installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
|
|||||||
or `bitcoind`/`bitcoin-qt` (on Linux).
|
or `bitcoind`/`bitcoin-qt` (on Linux).
|
||||||
|
|
||||||
Upgrading directly from a version of Bitcoin Core that has reached its EOL is
|
Upgrading directly from a version of Bitcoin Core that has reached its EOL is
|
||||||
possible, but might take some time if the datadir needs to be migrated. Old
|
possible, but it might take some time if the datadir needs to be migrated. Old
|
||||||
wallet versions of Bitcoin Core are generally supported.
|
wallet versions of Bitcoin Core are generally supported.
|
||||||
|
|
||||||
Compatibility
|
Compatibility
|
||||||
@ -52,345 +52,22 @@ to use Bitcoin Core on unsupported systems.
|
|||||||
Bitcoin Core should also work on most other Unix-like systems but is not
|
Bitcoin Core should also work on most other Unix-like systems but is not
|
||||||
as frequently tested on them.
|
as frequently tested on them.
|
||||||
|
|
||||||
From 0.17.0 onwards, macOS <10.10 is no longer supported. 0.17.0 is
|
From Bitcoin Core 0.17.0 onwards, macOS versions earlier than 10.10 are no
|
||||||
built using Qt 5.9.x, which doesn't support versions of macOS older than
|
longer supported, as Bitcoin Core is now built using Qt 5.9.x which requires
|
||||||
10.10. Additionally, Bitcoin Core does not yet change appearance when
|
macOS 10.10+. Additionally, Bitcoin Core does not yet change appearance when
|
||||||
macOS "dark mode" is activated.
|
macOS "dark mode" is activated.
|
||||||
|
|
||||||
In addition to previously-supported CPU platforms, this release's
|
In addition to previously supported CPU platforms, this release's pre-compiled
|
||||||
pre-compiled distribution also provides binaries for the RISC-V
|
distribution provides binaries for the RISC-V platform.
|
||||||
platform.
|
|
||||||
|
|
||||||
Notable changes
|
Notable changes
|
||||||
===============
|
===============
|
||||||
|
|
||||||
New user documentation
|
|
||||||
----------------------
|
|
||||||
|
|
||||||
- [Reduce memory](https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-memory.md)
|
|
||||||
suggests configuration tweaks for running Bitcoin Core on systems with
|
|
||||||
limited memory. (#16339)
|
|
||||||
|
|
||||||
New RPCs
|
|
||||||
--------
|
|
||||||
|
|
||||||
- `getbalances` returns an object with all balances (`mine`,
|
|
||||||
`untrusted_pending` and `immature`). Please refer to the RPC help of
|
|
||||||
`getbalances` for details. The new RPC is intended to replace
|
|
||||||
`getbalance`, `getunconfirmedbalance`, and the balance fields in
|
|
||||||
`getwalletinfo`. These old calls and fields may be removed in a
|
|
||||||
future version. (#15930, #16239)
|
|
||||||
|
|
||||||
- `setwalletflag` sets and unsets wallet flags that enable or disable
|
|
||||||
features specific to that existing wallet, such as the new
|
|
||||||
`avoid_reuse` feature documented elsewhere in these release notes.
|
|
||||||
(#13756)
|
|
||||||
|
|
||||||
- `getblockfilter` gets the BIP158 filter for the specified block. This
|
|
||||||
RPC is only enabled if block filters have been created using the
|
|
||||||
`-blockfilterindex` configuration option. (#14121)
|
|
||||||
|
|
||||||
New settings
|
|
||||||
------------
|
|
||||||
|
|
||||||
- `-blockfilterindex` enables the creation of BIP158 block filters for
|
|
||||||
the entire blockchain. Filters will be created in the background and
|
|
||||||
currently use about 4 GiB of space. Note: this version of Bitcoin
|
|
||||||
Core does not serve block filters over the P2P network, although the
|
|
||||||
local user may obtain block filters using the `getblockfilter` RPC.
|
|
||||||
(#14121)
|
|
||||||
|
|
||||||
Updated settings
|
|
||||||
----------------
|
|
||||||
|
|
||||||
- `whitebind` and `whitelist` now accept a list of permissions to
|
|
||||||
provide peers connecting using the indicated interfaces or IP
|
|
||||||
addresses. If no permissions are specified with an address or CIDR
|
|
||||||
network, the implicit default permissions are the same as previous
|
|
||||||
releases. See the `bitcoind -help` output for these two options for
|
|
||||||
details about the available permissions. (#16248)
|
|
||||||
|
|
||||||
Updated RPCs
|
|
||||||
------------
|
|
||||||
|
|
||||||
Note: some low-level RPC changes mainly useful for testing are described in the
|
|
||||||
Low-level Changes section below.
|
|
||||||
|
|
||||||
- `sendmany` no longer has a `minconf` argument. This argument was not
|
|
||||||
well specified and would lead to RPC errors even when the wallet's
|
|
||||||
coin selection succeeded. Users who want to influence coin selection
|
|
||||||
can use the existing `-spendzeroconfchange`, `-limitancestorcount`,
|
|
||||||
`-limitdescendantcount` and `-walletrejectlongchains` configuration
|
|
||||||
arguments. (#15596)
|
|
||||||
|
|
||||||
- `getbalance` and `sendtoaddress`, plus the new RPCs `getbalances` and
|
|
||||||
`createwallet`, now accept an "avoid_reuse" parameter that controls
|
|
||||||
whether already used addresses should be included in the operation.
|
|
||||||
Additionally, `sendtoaddress` will avoid partial spends when
|
|
||||||
`avoid_reuse` is enabled even if this feature is not already enabled
|
|
||||||
via the `-avoidpartialspends` command line flag because not doing so
|
|
||||||
would risk using up the "wrong" UTXO for an address reuse case.
|
|
||||||
(#13756)
|
|
||||||
|
|
||||||
- RPCs which have an `include_watchonly` argument or `includeWatching` option now default to `true` for watch-only
|
|
||||||
wallets. Affected RPCs are: `getbalance`, `listreceivedbyaddress`, `listreceivedbylabel`, `listtransactions`,
|
|
||||||
`listsinceblock`, `gettransaction`, `walletcreatefundedpsbt`, and `fundrawtransaction`. (#16383)
|
|
||||||
|
|
||||||
- `listunspent` now returns a "reused" bool for each output if the
|
|
||||||
wallet flag "avoid_reuse" is enabled. (#13756)
|
|
||||||
|
|
||||||
- `getblockstats` now uses BlockUndo data instead of the transaction
|
|
||||||
index, making it much faster, no longer dependent on the `-txindex`
|
|
||||||
configuration option, and functional for all non-pruned blocks.
|
|
||||||
(#14802)
|
|
||||||
|
|
||||||
- `utxoupdatepsbt` now accepts a `descriptors` parameter that will fill
|
|
||||||
out input and output scripts and keys when known. P2SH-witness inputs
|
|
||||||
will be filled in from the UTXO set when a descriptor is provided that
|
|
||||||
shows they're spending segwit outputs. See the RPC help text for full
|
|
||||||
details. (#15427)
|
|
||||||
|
|
||||||
- `sendrawtransaction` and `testmempoolaccept` no longer accept a
|
|
||||||
`allowhighfees` parameter to fail mempool acceptance if the
|
|
||||||
transaction fee exceedes the value of the configuration option
|
|
||||||
`-maxtxfee`. Now there is a hardcoded default maximum feerate that
|
|
||||||
can be changed when calling either RPC using a `maxfeerate` parameter.
|
|
||||||
(#15620)
|
|
||||||
|
|
||||||
- `getmempoolancestors`, `getmempooldescendants`, `getmempoolentry`, and
|
|
||||||
`getrawmempool` no longer return a `size` field unless the
|
|
||||||
configuration option `-deprecatedrpc=size` is used. Instead a new
|
|
||||||
`vsize` field is returned with the transaction's virtual size
|
|
||||||
(consistent with other RPCs such as `getrawtransaction`). (#15637)
|
|
||||||
|
|
||||||
- `getwalletinfo` now includes a `scanning` field that is either `false`
|
|
||||||
(no scanning) or an object with information about the duration and
|
|
||||||
progress of the wallet's scanning historical blocks for transactions
|
|
||||||
affecting its balances. (#15730)
|
|
||||||
|
|
||||||
- `gettransaction` now accepts a third (boolean) argument `verbose`. If
|
|
||||||
set to `true`, a new `decoded` field will be added to the response containing
|
|
||||||
the decoded transaction. This field is equivalent to RPC `decoderawtransaction`,
|
|
||||||
or RPC `getrawtransaction` when `verbose` is passed.
|
|
||||||
|
|
||||||
- `createwallet` accepts a new `passphrase` parameter. If set, this
|
|
||||||
will create the new wallet encrypted with the given passphrase. If
|
|
||||||
unset (the default) or set to an empty string, no encryption will be
|
|
||||||
used. (#16394)
|
|
||||||
|
|
||||||
- `getchaintxstats` RPC now returns the additional key of
|
|
||||||
`window_final_block_height`.
|
|
||||||
|
|
||||||
- `getmempoolentry` now provides a `weight` field containing the
|
|
||||||
transaction weight as defined in BIP141. (#16647)
|
|
||||||
|
|
||||||
- The `getnetworkinfo` and `getpeerinfo` commands now contain a new field with decoded network service flags.
|
|
||||||
|
|
||||||
- `getdescriptorinfo` now returns an additional `checksum` field
|
|
||||||
containing the checksum for the unmodified descriptor provided by the
|
|
||||||
user (that is, before the descriptor is normalized for the
|
|
||||||
`descriptor` field). (#15986)
|
|
||||||
|
|
||||||
- `joinpsbts` will shuffle the order of the inputs and outputs of the resulting joined psbt.
|
|
||||||
Previously inputs and outputs were added in the order that the PSBTs were provided which makes correlating inputs to outputs extremely easy.
|
|
||||||
|
|
||||||
- `walletcreatefundedpsbt` now signals BIP125 Replace-by-Fee if the
|
|
||||||
`-walletrbf` configuration option is set to true. (#15911)
|
|
||||||
|
|
||||||
GUI changes
|
|
||||||
-----------
|
|
||||||
|
|
||||||
- Provides bech32 addresses by default. The user may change the address
|
|
||||||
during invoice generation using a GUI toggle, or the default address
|
|
||||||
type may be changed by the `-addresstype` configuration option.
|
|
||||||
(#15711, #16497)
|
|
||||||
|
|
||||||
- In 0.18.0 a `./configure` flag was introduced to allow disabling BIP70 support in the GUI (support was enabled by default). In 0.19.0 this flag is now __disabled__ by default.
|
|
||||||
- If you want compile Bitcoin Core with BIP70 support in the GUI, you can pass `--enable-bip70` to `./configure`.
|
|
||||||
|
|
||||||
Deprecated or removed configuration options
|
|
||||||
-------------------------------------------
|
|
||||||
|
|
||||||
- `-mempoolreplacement` is removed, although default node behavior
|
|
||||||
remains the same. This option previously allowed the user to prevent
|
|
||||||
the node from accepting or relaying BIP125 transaction replacements.
|
|
||||||
This is different from the remaining configuration option
|
|
||||||
`-walletrbf`. (#16171)
|
|
||||||
|
|
||||||
Deprecated or removed RPCs
|
|
||||||
--------------------------
|
|
||||||
|
|
||||||
- `bumpfee` no longer accepts a `totalFee` option unless the
|
|
||||||
configuration parameter `deprecatedrpc=totalFee` is specified. This
|
|
||||||
parameter will be fully removed in a subsequent release. (#15996)
|
|
||||||
|
|
||||||
- `generate` is now removed after being deprecated in Bitcoin Core 0.18.
|
|
||||||
Use the `generatetoaddress` RPC instead. (#15492)
|
|
||||||
|
|
||||||
P2P changes
|
|
||||||
-----------
|
|
||||||
|
|
||||||
- BIP 61 reject messages were deprecated in v0.18. They are now disabled
|
|
||||||
by default, but can be enabled by setting the `-enablebip61` command
|
|
||||||
line option. BIP 61 reject messages will be removed entirely in a
|
|
||||||
future version of Bitcoin Core. (#14054)
|
|
||||||
|
|
||||||
- To eliminate well-known denial-of-service vectors in Bitcoin Core,
|
|
||||||
especially for nodes with spinning disks, the default value for the
|
|
||||||
`-peerbloomfilters` configuration option has been changed to false.
|
|
||||||
This prevents Bitcoin Core from sending the BIP111 NODE_BLOOM service
|
|
||||||
flag, accepting BIP37 bloom filters, or serving merkle blocks or
|
|
||||||
transactions matching a bloom filter. Users who still want to provide
|
|
||||||
bloom filter support may either set the configuration option to true
|
|
||||||
to re-enable both BIP111 and BIP37 support or enable just BIP37
|
|
||||||
support for specific peers using the updated `-whitelist` and
|
|
||||||
`-whitebind` configuration options described elsewhere in these
|
|
||||||
release notes. For the near future, lightweight clients using public
|
|
||||||
BIP111/BIP37 nodes should still be able to connect to older versions
|
|
||||||
of Bitcoin Core and nodes that have manually enabled BIP37 support,
|
|
||||||
but developers of such software should consider migrating to either
|
|
||||||
using specific BIP37 nodes or an alternative transaction filtering
|
|
||||||
system. (#16152)
|
|
||||||
|
|
||||||
Miscellaneous CLI Changes
|
|
||||||
-------------------------
|
|
||||||
|
|
||||||
- The `testnet` field in `bitcoin-cli -getinfo` has been renamed to
|
|
||||||
`chain` and now returns the current network name as defined in BIP70
|
|
||||||
(main, test, regtest). (#15566)
|
|
||||||
|
|
||||||
Low-level changes
|
|
||||||
=================
|
|
||||||
|
|
||||||
RPC
|
|
||||||
---
|
|
||||||
|
|
||||||
- `getblockchaininfo` no longer returns a `bip9_softforks` object.
|
|
||||||
Instead, information has been moved into the `softforks` object and
|
|
||||||
an additional `type` field describes how Bitcoin Core determines
|
|
||||||
whether that soft fork is active (e.g. BIP9 or BIP90). See the RPC
|
|
||||||
help for details. (#16060)
|
|
||||||
|
|
||||||
- `getblocktemplate` no longer returns a `rules` array containing `CSV`
|
|
||||||
and `segwit` (the BIP9 deployments that are currently in active
|
|
||||||
state). (#16060)
|
|
||||||
|
|
||||||
- `getrpcinfo` now returns a `logpath` field with the path to
|
|
||||||
`debug.log`. (#15483)
|
|
||||||
|
|
||||||
Tests
|
|
||||||
-----
|
|
||||||
|
|
||||||
- The regression test chain enabled by the `-regtest` command line flag
|
|
||||||
now requires transactions to not violate standard policy by default.
|
|
||||||
This is the same default used for mainnet and makes it easier to test
|
|
||||||
mainnet behavior on regtest. Note that the testnet still allows
|
|
||||||
non-standard txs by default and that the policy can be locally
|
|
||||||
adjusted with the `-acceptnonstdtxn` command line flag for both test
|
|
||||||
chains. (#15891)
|
|
||||||
|
|
||||||
Configuration
|
|
||||||
------------
|
|
||||||
|
|
||||||
- A setting specified in the default section but not also specified in a
|
|
||||||
network-specific section (e.g. testnet) will now produce an error
|
|
||||||
preventing startup instead of just a warning unless the network is
|
|
||||||
mainnet. This prevents settings intended for mainnet from being
|
|
||||||
applied to testnet or regtest. (#15629)
|
|
||||||
|
|
||||||
- On platforms supporting `thread_local`, log lines can be prefixed with
|
|
||||||
the name of the thread that caused the log. To enable this behavior,
|
|
||||||
use `-logthreadnames=1`. (#15849)
|
|
||||||
|
|
||||||
Network
|
|
||||||
-------
|
|
||||||
|
|
||||||
- When fetching a transaction announced by multiple peers, previous versions of
|
|
||||||
Bitcoin Core would sequentially attempt to download the transaction from each
|
|
||||||
announcing peer until the transaction is received, in the order that those
|
|
||||||
peers' announcements were received. In this release, the download logic has
|
|
||||||
changed to randomize the fetch order across peers and to prefer sending
|
|
||||||
download requests to outbound peers over inbound peers. This fixes an issue
|
|
||||||
where inbound peers could prevent a node from getting a transaction.
|
|
||||||
(#14897, #15834)
|
|
||||||
|
|
||||||
- If a Tor hidden service is being used, Bitcoin Core will be bound to
|
|
||||||
the standard port 8333 even if a different port is configured for
|
|
||||||
clearnet connections. This prevents leaking node identity through use
|
|
||||||
of identical non-default port numbers. (#15651)
|
|
||||||
|
|
||||||
Mempool and transaction relay
|
|
||||||
-----------------------------
|
|
||||||
|
|
||||||
- Allows one extra single-ancestor transaction per package. Previously,
|
|
||||||
if a transaction in the mempool had 25 descendants, or it and all of
|
|
||||||
its descendants were over 101,000 vbytes, any newly-received
|
|
||||||
transaction that was also a descendant would be ignored. Now, one
|
|
||||||
extra descendant will be allowed provided it is an immediate
|
|
||||||
descendant (child) and the child's size is 10,000 vbytes or less.
|
|
||||||
This makes it possible for two-party contract protocols such as
|
|
||||||
Lightning Network to give each participant an output they can spend
|
|
||||||
immediately for Child-Pays-For-Parent (CPFP) fee bumping without
|
|
||||||
allowing one malicious participant to fill the entire package and thus
|
|
||||||
prevent the other participant from spending their output. (#15681)
|
|
||||||
|
|
||||||
- Transactions with outputs paying v1 to v16 witness versions (future
|
|
||||||
segwit versions) are now accepted into the mempool, relayed, and
|
|
||||||
mined. Attempting to spend those outputs remains forbidden by policy
|
|
||||||
("non-standard"). When this change has been widely deployed, wallets
|
|
||||||
and services can accept any valid bech32 Bitcoin address without
|
|
||||||
concern that transactions paying future segwit versions will become
|
|
||||||
stuck in an unconfirmed state. (#15846)
|
|
||||||
|
|
||||||
- Legacy transactions (transactions with no segwit inputs) must now be
|
|
||||||
sent using the legacy encoding format, enforcing the rule specified in
|
|
||||||
BIP144. (#14039)
|
|
||||||
|
|
||||||
Wallet
|
|
||||||
------
|
|
||||||
|
|
||||||
- When in pruned mode, a rescan that was triggered by an `importwallet`,
|
|
||||||
`importpubkey`, `importaddress`, or `importprivkey` RPC will only fail
|
|
||||||
when blocks have been pruned. Previously it would fail when `-prune`
|
|
||||||
has been set. This change allows setting `-prune` to a high value
|
|
||||||
(e.g. the disk size) without the calls to any of the import RPCs
|
|
||||||
failing until the first block is pruned. (#15870)
|
|
||||||
|
|
||||||
- When creating a transaction with a fee above `-maxtxfee` (default 0.1
|
|
||||||
BTC), the RPC commands `walletcreatefundedpsbt` and
|
|
||||||
`fundrawtransaction` will now fail instead of rounding down the fee.
|
|
||||||
Be aware that the `feeRate` argument is specified in BTC per 1,000
|
|
||||||
vbytes, not satoshi per vbyte. (#16257)
|
|
||||||
|
|
||||||
- A new wallet flag `avoid_reuse` has been added (default off). When
|
|
||||||
enabled, a wallet will distinguish between used and unused addresses,
|
|
||||||
and default to not use the former in coin selection. When setting
|
|
||||||
this flag on an existing wallet, rescanning the blockchain is required
|
|
||||||
to correctly mark previously used destinations. Together with "avoid
|
|
||||||
partial spends" (added in Bitcoin Core v0.17.0), this can eliminate a
|
|
||||||
serious privacy issue where a malicious user can track spends by
|
|
||||||
sending small payments to a previously-paid address that would then
|
|
||||||
be included with unrelated inputs in future payments. (#13756)
|
|
||||||
|
|
||||||
Build system changes
|
|
||||||
--------------------
|
|
||||||
|
|
||||||
- Python >=3.5 is now required by all aspects of the project. This
|
|
||||||
includes the build systems, test framework and linters. The previously
|
|
||||||
supported minimum (3.4), was EOL in March 2019. (#14954)
|
|
||||||
|
|
||||||
- The minimum supported miniUPnPc API version is set to 10. This keeps
|
|
||||||
compatibility with Ubuntu 16.04 LTS and Debian 8 `libminiupnpc-dev`
|
|
||||||
packages. Please note, on Debian this package is still vulnerable to
|
|
||||||
[CVE-2017-8798](https://security-tracker.debian.org/tracker/CVE-2017-8798)
|
|
||||||
(in jessie only) and
|
|
||||||
[CVE-2017-1000494](https://security-tracker.debian.org/tracker/CVE-2017-1000494)
|
|
||||||
(both in jessie and in stretch). (#15993)
|
|
||||||
|
|
||||||
Credits
|
Credits
|
||||||
=======
|
=======
|
||||||
|
|
||||||
Thanks to everyone who directly contributed to this release:
|
Thanks to everyone who directly contributed to this release:
|
||||||
|
|
||||||
|
|
||||||
As well as everyone that helped translating on [Transifex](https://www.transifex.com/bitcoin/bitcoin/).
|
As well as to everyone that helped with translations on
|
||||||
|
[Transifex](https://www.transifex.com/bitcoin/bitcoin/).
|
||||||
|
Loading…
x
Reference in New Issue
Block a user