diff options
author | Wladimir J. van der Laan <laanwj@gmail.com> | 2017-02-17 17:26:01 +0100 |
---|---|---|
committer | Wladimir J. van der Laan <laanwj@gmail.com> | 2017-02-17 17:27:18 +0100 |
commit | f87e8f53920adfa80a3f4af9435370dc272c3783 (patch) | |
tree | 124de2635a27102d08dad98d0be7b1e6a3e5465c /doc | |
parent | 9828f9a9962c1bee5c343847030b9cfd87a40a5e (diff) |
build: bump version to 0.14.99
Now that 0.14 branch has been split off, master is 0.14.99 (pre-0.15).
Also clean out release notes.
Diffstat (limited to 'doc')
-rw-r--r-- | doc/Doxyfile | 2 | ||||
-rw-r--r-- | doc/README.md | 2 | ||||
-rw-r--r-- | doc/README_windows.txt | 2 | ||||
-rw-r--r-- | doc/release-notes.md | 111 |
4 files changed, 3 insertions, 114 deletions
diff --git a/doc/Doxyfile b/doc/Doxyfile index ef55acdbc3..45436a6b15 100644 --- a/doc/Doxyfile +++ b/doc/Doxyfile @@ -38,7 +38,7 @@ PROJECT_NAME = "Bitcoin Core" # could be handy for archiving the generated documentation or if some version # control system is used. -PROJECT_NUMBER = 0.13.99 +PROJECT_NUMBER = 0.14.99 # Using the PROJECT_BRIEF tag one can provide an optional one line description # for a project that appears at the top of each page and should give viewer a diff --git a/doc/README.md b/doc/README.md index 36684e5401..09f32bc09e 100644 --- a/doc/README.md +++ b/doc/README.md @@ -1,4 +1,4 @@ -Bitcoin Core 0.13.99 +Bitcoin Core 0.14.99 ===================== Setup diff --git a/doc/README_windows.txt b/doc/README_windows.txt index 74a05138a4..0e4c9ce04f 100644 --- a/doc/README_windows.txt +++ b/doc/README_windows.txt @@ -1,4 +1,4 @@ -Bitcoin Core 0.13.99
+Bitcoin Core 0.14.99
=====================
Intro
diff --git a/doc/release-notes.md b/doc/release-notes.md index 0ea9e1949e..eaa0b330eb 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -33,117 +33,6 @@ frequently tested on them. Notable changes =============== -Low-level RPC changes ----------------------- - -- `importprunedfunds` only accepts two required arguments. Some versions accept - 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 - return -1 or 1e24 appropriately. The format for `fee_estimates.dat` has also - changed to no longer save these priority estimates. It will automatically be - converted to the new format which is not readable by prior versions of the - software. - -- 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 --------------------------- - -- Peers manually added through the addnode option or addnode RPC now have their own - limit of eight connections which does not compete with other inbound or outbound - connection usage and is not subject to the maxconnections limitation. - -- 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 -================= - -Detailed release notes follow. This overview includes changes that affect -behavior, not code moves, refactors and string updates. For convenience in locating -the code changes and accompanying discussion, both the pull request and -git merge commit are mentioned. - -### RPC and REST - -UTXO set query (`GET /rest/getutxos/<checkmempool>/<txid>-<n>/<txid>-<n>/.../<txid>-<n>.<bin|hex|json>`) responses -were changed to return status code HTTP_BAD_REQUEST (400) instead of HTTP_INTERNAL_SERVER_ERROR (500) when requests -contain invalid parameters. - -The first boolean argument to `getaddednodeinfo` has been removed. This is an incompatible change. - -Call "getmininginfo" loses the "testnet" field in favor of the more generic "chain" (which has been present for years). - -### Configuration and command-line options - -### Block and transaction handling - -### P2P protocol and network code - -### Validation - -### Build system - -### Wallet - -0.14.0 Fundrawtransaction change address reuse -============================================== - -Before 0.14, `fundrawtransaction` was by default wallet stateless. In almost all cases `fundrawtransaction` does add a change-output to the outputs of the funded transaction. Before 0.14, the used keypool key was never marked as change-address key and directly returned to the keypool (leading to address reuse). -Before 0.14, calling `getnewaddress` directly after `fundrawtransaction` did generate the same address as the change-output address. - -Since 0.14, fundrawtransaction does reserve the change-output-key from the keypool by default (optional by setting `reserveChangeKey`, default = `true`) - -Users should also consider using `getrawchangeaddress()` in conjunction with `fundrawtransaction`'s `changeAddress` option. - -### GUI - -### Tests - -### Miscellaneous - Credits ======= |