You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/release-notes.md
-111Lines changed: 0 additions & 111 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -33,117 +33,6 @@ frequently tested on them.
33
33
Notable changes
34
34
===============
35
35
36
-
Low-level RPC changes
37
-
----------------------
38
-
39
-
-`importprunedfunds` only accepts two required arguments. Some versions accept
40
-
an optional third arg, which was always ignored. Make sure to never pass more
41
-
than two arguments.
42
-
43
-
Fee Estimation Changes
44
-
----------------------
45
-
46
-
- Since 0.13.2 fee estimation for a confirmation target of 1 block has been
47
-
disabled. This is only a minor behavior change as there was often insufficient
48
-
data for this target anyway. `estimatefee 1` will now always return -1 and
49
-
`estimatesmartfee 1` will start searching at a target of 2.
50
-
51
-
- The default target for fee estimation is changed to 6 blocks in both the GUI
52
-
(previously 25) and for RPC calls (previously 2).
53
-
54
-
Removal of Priority Estimation
55
-
-------------------------------
56
-
57
-
- Estimation of "priority" needed for a transaction to be included within a target
58
-
number of blocks has been removed. The rpc calls are deprecated and will either
59
-
return -1 or 1e24 appropriately. The format for `fee_estimates.dat` has also
60
-
changed to no longer save these priority estimates. It will automatically be
61
-
converted to the new format which is not readable by prior versions of the
62
-
software.
63
-
64
-
- The concept of "priority" (coin age) transactions is planned to be removed in
65
-
the next major version. To prepare for this, the default for the rate limit of
66
-
priority transactions (`-limitfreerelay`) has been set to `0` kB/minute. This
67
-
is not to be confused with the `prioritisetransaction` RPC which will remain
68
-
supported for adding fee deltas to transactions.
69
-
70
-
P2P connection management
71
-
--------------------------
72
-
73
-
- Peers manually added through the addnode option or addnode RPC now have their own
74
-
limit of eight connections which does not compete with other inbound or outbound
75
-
connection usage and is not subject to the maxconnections limitation.
76
-
77
-
- New connections to manually added peers are much faster.
78
-
79
-
Introduction of assumed-valid blocks
80
-
-------------------------------------
81
-
82
-
- A significant portion of the initial block download time is spent verifying
83
-
scripts/signatures. Although the verification must pass to ensure the security
84
-
of the system, no other result from this verification is needed: If the node
85
-
knew the history of a given block were valid it could skip checking scripts
86
-
for its ancestors.
87
-
88
-
- A new configuration option 'assumevalid' is provided to express this knowledge
89
-
to the software. Unlike the 'checkpoints' in the past this setting does not
90
-
force the use of a particular chain: chains that are consistent with it are
91
-
processed quicker, but other chains are still accepted if they'd otherwise
92
-
be chosen as best. Also unlike 'checkpoints' the user can configure which
93
-
block history is assumed true, this means that even outdated software can
94
-
sync more quickly if the setting is updated by the user.
95
-
96
-
- Because the validity of a chain history is a simple objective fact it is much
97
-
easier to review this setting. As a result the software ships with a default
98
-
value adjusted to match the current chain shortly before release. The use
99
-
of this default value can be disabled by setting -assumevalid=0
100
-
101
-
0.14.0 Change log
102
-
=================
103
-
104
-
Detailed release notes follow. This overview includes changes that affect
105
-
behavior, not code moves, refactors and string updates. For convenience in locating
106
-
the code changes and accompanying discussion, both the pull request and
107
-
git merge commit are mentioned.
108
-
109
-
### RPC and REST
110
-
111
-
UTXO set query (`GET /rest/getutxos/<checkmempool>/<txid>-<n>/<txid>-<n>/.../<txid>-<n>.<bin|hex|json>`) responses
112
-
were changed to return status code HTTP_BAD_REQUEST (400) instead of HTTP_INTERNAL_SERVER_ERROR (500) when requests
113
-
contain invalid parameters.
114
-
115
-
The first boolean argument to `getaddednodeinfo` has been removed. This is an incompatible change.
116
-
117
-
Call "getmininginfo" loses the "testnet" field in favor of the more generic "chain" (which has been present for years).
118
-
119
-
### Configuration and command-line options
120
-
121
-
### Block and transaction handling
122
-
123
-
### P2P protocol and network code
124
-
125
-
### Validation
126
-
127
-
### Build system
128
-
129
-
### Wallet
130
-
131
-
0.14.0 Fundrawtransaction change address reuse
132
-
==============================================
133
-
134
-
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).
135
-
Before 0.14, calling `getnewaddress` directly after `fundrawtransaction` did generate the same address as the change-output address.
136
-
137
-
Since 0.14, fundrawtransaction does reserve the change-output-key from the keypool by default (optional by setting `reserveChangeKey`, default = `true`)
138
-
139
-
Users should also consider using `getrawchangeaddress()` in conjunction with `fundrawtransaction`'s `changeAddress` option.
0 commit comments