dogecoin/doc/release-notes.md

145 lines
5.2 KiB
Markdown
Raw Normal View History

*After branching off for a major version release of Bitcoin Core, use this
template to create the initial release notes draft.*
*The release notes draft is a temporary file that can be added to by anyone. See
[/doc/developer-notes.md#release-notes](/doc/developer-notes.md#release-notes)
for the process.*
*Create the draft, named* "*version* Release Notes Draft"
*(e.g. "0.20.0 Release Notes Draft"), as a collaborative wiki in:*
https://github.com/bitcoin-core/bitcoin-devwiki/wiki/
*Before the final release, move the notes back to this git repository.*
*version* Release Notes Draft
===============================
estimatefee / estimatepriority RPC methods New RPC methods: return an estimate of the fee (or priority) a transaction needs to be likely to confirm in a given number of blocks. Mike Hearn created the first version of this method for estimating fees. It works as follows: For transactions that took 1 to N (I picked N=25) blocks to confirm, keep N buckets with at most 100 entries in each recording the fees-per-kilobyte paid by those transactions. (separate buckets are kept for transactions that confirmed because they are high-priority) The buckets are filled as blocks are found, and are saved/restored in a new fee_estiamtes.dat file in the data directory. A few variations on Mike's initial scheme: To estimate the fee needed for a transaction to confirm in X buckets, all of the samples in all of the buckets are used and a median of all of the data is used to make the estimate. For example, imagine 25 buckets each containing the full 100 entries. Those 2,500 samples are sorted, and the estimate of the fee needed to confirm in the very next block is the 50'th-highest-fee-entry in that sorted list; the estimate of the fee needed to confirm in the next two blocks is the 150'th-highest-fee-entry, etc. That algorithm has the nice property that estimates of how much fee you need to pay to get confirmed in block N will always be greater than or equal to the estimate for block N+1. It would clearly be wrong to say "pay 11 uBTC and you'll get confirmed in 3 blocks, but pay 12 uBTC and it will take LONGER". A single block will not contribute more than 10 entries to any one bucket, so a single miner and a large block cannot overwhelm the estimates.
2014-03-17 13:19:54 +01:00
Bitcoin Core version *version* is now available from:
<https://bitcoincore.org/bin/bitcoin-core-*version*/>
This release includes new features, various bug fixes and performance
improvements, as well as updated translations.
2017-09-12 10:04:27 +02:00
Please report bugs using the issue tracker at GitHub:
<https://github.com/bitcoin/bitcoin/issues>
To receive security and update notifications, please subscribe to:
<https://bitcoincore.org/en/list/announcements/join/>
How to Upgrade
==============
If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
2017-09-12 10:04:27 +02:00
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).
Upgrading directly from a version of Bitcoin Core that has reached its EOL is
possible, but might take some time if the datadir needs to be migrated. Old
wallet versions of Bitcoin Core are generally supported.
Compatibility
==============
Bitcoin Core is supported and extensively tested on operating systems using
the Linux kernel, macOS 10.10+, and Windows 7 and newer. It is not recommended
to use Bitcoin Core on unsupported systems.
Bitcoin Core should also work on most other Unix-like systems but is not
as frequently tested on them.
From 0.17.0 onwards, macOS <10.10 is no longer supported. 0.17.0 is
built using Qt 5.9.x, which doesn't support versions of macOS older than
10.10. Additionally, Bitcoin Core does not yet change appearance when
macOS "dark mode" is activated.
In addition to previously-supported CPU platforms, this release's
pre-compiled distribution also provides binaries for the RISC-V
platform.
2015-05-26 21:32:25 +02:00
Notable changes
===============
New RPCs
--------
- `getbalances` returns an object with all balances (`mine`,
`untrusted_pending` and `immature`). Please refer to the RPC help of
`getbalances` for details. The new RPC is intended to replace
`getunconfirmedbalance` and the balance fields in `getwalletinfo`, as well as
`getbalance`. The old calls may be removed in a future version.
2019-03-20 17:59:18 +01:00
Updated RPCs
------------
2019-03-20 17:59:18 +01:00
Note: some low-level RPC changes mainly useful for testing are described in the
Low-level Changes section below.
- The `sendmany` RPC had an argument `minconf` that was not well specified and
2019-03-20 17:59:18 +01:00
would lead to RPC errors even when the wallet's coin selection would succeed.
The `sendtoaddress` RPC never had this check, so to normalize the behavior,
`minconf` is now ignored in `sendmany`. If the coin selection does not
succeed due to missing coins, it will still throw an RPC error. Be reminded
that coin selection is influenced by the `-spendzeroconfchange`,
`-limitancestorcount`, `-limitdescendantcount` and `-walletrejectlongchains`
command line arguments.
Low-level changes
=================
2019-04-24 23:55:58 +02:00
RPC
---
Tests
-----
- The regression test chain, that can be enabled by the `-regtest` command line
flag, now requires transactions to not violate standard policy by default.
Making the default the same as for mainnet, makes it easier to test mainnet
behavior on regtest. Be reminded that the testnet still allows non-standard
txs by default and that the policy can be locally adjusted with the
`-acceptnonstdtxn` command line flag for both test chains.
2019-03-21 18:38:52 +01:00
Configuration
------------
- An error is issued where previously a warning was issued when a setting in
the config file was specified in the default section, but not overridden for
2019-03-21 18:38:52 +01:00
the selected network. This change takes only effect if the selected network
is not mainnet.
Network
-------
- When fetching a transaction announced by multiple peers, previous versions of
Bitcoin Core would sequentially attempt to download the transaction from each
announcing peer until the transaction is received, in the order that those
peers' announcements were received. In this release, the download logic has
changed to randomize the fetch order across peers and to prefer sending
download requests to outbound peers over inbound peers. This fixes an issue
where inbound peers can prevent a node from getting a transaction.
Wallet
------
- When in pruned mode, a rescan that was triggered by an `importwallet`,
`importpubkey`, `importaddress`, or `importprivkey` RPC will only fail when
blocks have been pruned. Previously it would fail when `-prune` has been set.
This change allows to set `-prune` to a high value (e.g. the disk size) and
the calls to any of the import RPCs would fail when the first block is
pruned.
Credits
=======
Thanks to everyone who directly contributed to this release:
2019-02-14 11:48:53 +01:00
As well as everyone that helped translating on [Transifex](https://www.transifex.com/bitcoin/bitcoin/).