|
|
@ -280,6 +280,46 @@ P2P connection management |
|
|
|
|
|
|
|
|
|
|
|
- New connections to manually added peers are performed more quickly. |
|
|
|
- New connections to manually added peers are performed more quickly. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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. |
|
|
|
|
|
|
|
|
|
|
|
0.14.0 Change log |
|
|
|
0.14.0 Change log |
|
|
|
================= |
|
|
|
================= |
|
|
|
|
|
|
|
|
|
|
|