diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/release-notes.md | 66 | ||||
| -rw-r--r-- | doc/release-process.md | 5 |
2 files changed, 51 insertions, 20 deletions
diff --git a/doc/release-notes.md b/doc/release-notes.md index 7d0d689684..bbda55854f 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -19,24 +19,16 @@ To receive security and update notifications, please subscribe to: Compatibility ============== -Microsoft ended support for Windows XP on [April 8th, 2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support), -an OS initially released in 2001. This means that not even critical security -updates will be released anymore. Without security updates, using a bitcoin -wallet on a XP machine is irresponsible at least. +Bitcoin Core is extensively tested on multiple operating systems using +the Linux kernel, macOS 10.8+, and Windows Vista and later. -In addition to that, with 0.12.x there have been varied reports of Bitcoin Core -randomly crashing on Windows XP. It is [not clear](https://github.com/bitcoin/bitcoin/issues/7681#issuecomment-217439891) -what the source of these crashes is, but it is likely that upstream -libraries such as Qt are no longer being tested on XP. +Microsoft ended support for Windows XP on [April 8th, 2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support). +No attempt is made to prevent installing or running the software on Windows XP, you +can still do so at your own risk but be aware that there are known instabilities. +Please do not report issues about Windows XP to the issue tracker. -We do not have time nor resources to provide support for an OS that is -end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are -suggested to upgrade to a newer version of Windows, or install an alternative OS -that is supported. - -No attempt is made to prevent installing or running the software on Windows XP, -you can still do so at your own risk, but do not expect it to work: do not -report issues about Windows XP to the issue tracker. +Bitcoin Core should also work on most other Unix-like systems but is not +frequently tested on them. Notable changes =============== @@ -48,8 +40,19 @@ Low-level RPC changes an optional third arg, which was always ignored. Make sure to never pass more than two arguments. +Fee Estimation Changes +---------------------- + +- Since 0.13.2 fee estimation for a confirmation target of 1 block has been + disabled. This is only a minor behavior change as there was often insufficient + data for this target anyway. `estimatefee 1` will now always return -1 and + `estimatesmartfee 1` will start searching at a target of 2. + +- The default target for fee estimation is changed to 6 blocks in both the GUI + (previously 25) and for RPC calls (previously 2). + Removal of Priority Estimation ------------------------------- +------------------------------- - Estimation of "priority" needed for a transaction to be included within a target number of blocks has been removed. The rpc calls are deprecated and will either @@ -58,9 +61,11 @@ Removal of Priority Estimation converted to the new format which is not readable by prior versions of the software. -- The concept of "priority" transactions is planned to be removed in the next - major version. To prepare for this, the default for the rate limit of priority - transactions (`-limitfreerelay`) has been set to `0` kB/minute. +- The concept of "priority" (coin age) transactions is planned to be removed in + the next major version. To prepare for this, the default for the rate limit of + priority transactions (`-limitfreerelay`) has been set to `0` kB/minute. This + is not to be confused with the `prioritisetransaction` RPC which will remain + supported for adding fee deltas to transactions. P2P connection management -------------------------- @@ -71,6 +76,27 @@ P2P connection management - New connections to manually added peers are much faster. +Introduction of assumed-valid blocks +------------------------------------- + +- A significant portion of the initial block download time is spent verifying + scripts/signatures. Although the verification must pass to ensure the security + of the system, no other result from this verification is needed: If the node + knew the history of a given block were valid it could skip checking scripts + for its ancestors. + +- A new configuration option 'assumevalid' is provided to express this knowledge + to the software. Unlike the 'checkpoints' in the past this setting does not + force the use of a particular chain: chains that are consistent with it are + processed quicker, but other chains are still accepted if they'd otherwise + be chosen as best. Also unlike 'checkpoints' the user can configure which + block history is assumed true, this means that even outdated software can + sync more quickly if the setting is updated by the user. + +- Because the validity of a chain history is a simple objective fact it is much + easier to review this setting. As a result the software ships with a default + value adjusted to match the current chain shortly before release. The use + of this default value can be disabled by setting -assumevalid=0 0.14.0 Change log ================= diff --git a/doc/release-process.md b/doc/release-process.md index 61f05b0771..399ed25c91 100644 --- a/doc/release-process.md +++ b/doc/release-process.md @@ -13,6 +13,11 @@ Before every minor and major release: * Update version in sources (see below) * Write release notes (see below) * Update `src/chainparams.cpp` nMinimumChainWork with information from the getblockchaininfo rpc. +* Update `src/chainparams.cpp` defaultAssumeValid with information from the getblockhash rpc. + - The selected value must not be orphaned so it may be useful to set the value two blocks back from the tip. + - Testnet should be set some tens of thousands back from the tip due to reorgs there. + - This update should be reviewed with a reindex-chainstate with assumevalid=0 to catch any defect + that causes rejection of blocks in the past history. Before every major release: |