mirror of
https://github.com/bitcoin/bitcoin.git
synced 2025-01-10 03:47:29 -03:00
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.
This commit is contained in:
Wladimir J. van der Laan
parent
9828f9a996
commit
f87e8f5392
6 changed files with 5 additions and 116 deletions
|
|
@ -1,7 +1,7 @@
|
|||
dnl require autoconf 2.60 (AS_ECHO/AS_ECHO_N)
|
||||
AC_PREREQ([2.60])
|
||||
define(_CLIENT_VERSION_MAJOR, 0)
|
||||
define(_CLIENT_VERSION_MINOR, 13)
|
||||
define(_CLIENT_VERSION_MINOR, 14)
|
||||
define(_CLIENT_VERSION_REVISION, 99)
|
||||
define(_CLIENT_VERSION_BUILD, 0)
|
||||
define(_CLIENT_VERSION_IS_RELEASE, false)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Bitcoin Core 0.13.99
|
||||
Bitcoin Core 0.14.99
|
||||
=====================
|
||||
|
||||
Setup
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Bitcoin Core 0.13.99
|
||||
Bitcoin Core 0.14.99
|
||||
=====================
|
||||
|
||||
Intro
|
||||
|
|
|
|||
|
|
@ -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
|
||||
=======
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@
|
|||
|
||||
//! These need to be macros, as clientversion.cpp's and bitcoin*-res.rc's voodoo requires it
|
||||
#define CLIENT_VERSION_MAJOR 0
|
||||
#define CLIENT_VERSION_MINOR 13
|
||||
#define CLIENT_VERSION_MINOR 14
|
||||
#define CLIENT_VERSION_REVISION 99
|
||||
#define CLIENT_VERSION_BUILD 0
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue